Hacker News Reader

> * What are best practices to manage private and public keys as well as all these usernames/password for the web ui's?

Keys: you should encrypt your private key with a passphrase. Following one key pair per device account (see other comments) there is not much other management needed. If you get tired of supplying the key passphrase look at using an "SSH agent".

Passwords: use a password manager. If your Excel file is encrypted it is perhaps a passable ersatz.

* How keep a good overview over all git credentials?

GitHub account settings page lists what you have uploaded. On each device, the key pair is in two files under .ssh/ in your home directory for OpenSSH.

* Can I store SSH keys in my Excel-File?

Yes, just be wary of Excel corrupting the string. However, rarely do you as a human interact with either key information so I do not see the point, other than perhaps as some kind of backup mechanism. I simply leave the SSH key files in place where they were generated by ssh-keygen and used by ssh and/or ssh-agent.

* How many SSH keys would you recommended for my scenario?

As said in the other comments, I also recommend one key pair per device account with each device account's public key added to each of the relevant GitHub (etc) account. If a particular device account will not access a given remote account, no reason to upload that public key.

If SSH is used for other types of access the keys can be shared or there can be reasons to have service-specific keys.

I'll just add some things I think are missing:

* Here's GitHub's guide: https://docs.github.com/en/authentication/connecting-to-gith...

> Before I get killed here for using Excel files for credential storage please note that I have about thirty+ years of excellent experience going that way, have tons of managed credentials and think that millions of users have similar practices.

That's not true and even if it was, it's not a justification to do anything. You know it's wrong, but to be honest it's not my job to convince you that you should be using the right tool for the right job.

What steps did you take to research a good solution on your own? How do the responses here compare? Do you think that asking questions here will have an effect on how you see your current workflow?

> You know it's wrong

not quite wrong. Maybe not the most secure way. It worked and saved my life when password need to be changed, needed to get a more secure pattern, got lost and so on.

> Do you think that asking questions here will have an effect on how you see your current workflow?

Hmmm. Good feedback. My workflow gets disturbed by Github and Bitbucket, so I have to change it. I just try to learn from the community how to handle this requirements. Every developer has to find a way to handle secrets and it is not universally solved yet what is the best way. And additionally it changes from time to time.

You seem to have put off cleaning this up for way too long.

You should be able to register the same ssh pubkey with all the accounts.

Then just back up that pub and privkey on a usb stick somewhere and accesss everything from the same keypair.

This is a quick+dirty fix (which is probably what OP wants in this situation). You probably want per-device ssh identities. There's a few advantages to this.

One is, if an identify is ever compromised you can revoke it without loosing as much downtime (one device is compromised - just revoke that key - you now still have access on other devices) if you don't do this, you'd have to revoke the one key you use, which means you have to repeat the pain of copying identities between devices again.

Alternately you can devise a good way of sharing the things you use (keys, maybe a pass db, etc) over all your machines automatically (e.g. via SyncThing or something along those lines).

I personally use one public key which I securely synchronise between machines, which can then be added to, and hence access, all the systems I need. In this case, you just have one keypair (two text files) to store. You can put the contents of those files in Excel if you really want to.

By the way - regarding doing this for thirty years, be careful with that as a plea to authority - I read a tweet recently along the lines of "Do you have 30 years experience, or have you just done the same year 30 times?"

> I read a tweet recently along the lines of > "Do you have 30 years experience, or have you > just done the same year 30 times?"

Good point. I mean, this crude offline Excel solution has simply survived many system migrations, different operating systems (including Win95->...->Win11), employer directives, password restrictions, and so on.

Your "use one public key which I securely synchronize between machines" approach seems feasible, thank you for this idea!

> Can I store SSH keys in my Excel-File? > Before I get killed here for using Excel files for credential storage...

I don't want to be that one who points it out, but - how about switching to the password-store [0] (or gopass [1] - way easier), which works under all operating systems and keeps secrets versioned (via git).

With pass(1) you name your credentials accordingly to their purpose. For example, you could use following naming pattern: [client-name]/[website/subject]/[secret-name]. e.g. acme-corp/github.com/ssh/public-key, other-client/github.com/account, personal/gmail.com/password etc. That way, removal of old/unused secrets is just simple as doing "gopass rm -r [client-name]". There are also many more commands to list or print a tree of stored credentials.

Generally speaking, pass(1)/gopass(1) is a very simple way to manage credentials. I can't say how much I recommend that flow instead of using KeePass or plain-text files. Additionally, if you need those secrets on mobile phone there is an Android app [2] that might be very handy in some situations. This Android app and also gopass(1), have OTP code calculator (similar as in Google Authenticator), so you might be more happier with adapting yourself to use 2FA.

[0]: https://www.passwordstore.org/

[1]: https://github.com/gopasspw/gopass

[2]: https://github.com/android-password-store/Android-Password-S...

> What are best practices to manage private and public keys as well as all these usernames/password for the web ui's?

Use a password database to store credentials for username + password. For 2FA, ideally some U2F device like a Yubikey, I think.

Keys shouldn't be stored in a DB. The public half of a key is fine to share around. The private half should never be copied anywhere. The SSH key should have a password, though; that password should be in your password database, too.

> How many SSH keys

BitBucket (and I'd guess GitHub) don't support using the same SSH key for multiple users. (IIUC, the key is used to determine which user is accessing the repo). So you'll need at least one per user.

>> I need to access these repos from about 30 different git client machines.

Weird. Why? In what way? For deploying code to these machines, or as 30 different workstations?

> BitBucket (and I'd guess GitHub) don't support using the same SSH key for multiple users

Yes, exactly. The SSH client on your dev machine supports using multiple SSH keys for BitBucket/GitHub. That's the way it should be used (I posted above).

For Github (can't speak for Bitbucket) you can consider the alternative authentication mechanism of Personal Access Tokens (PAT). This is simpler to use than an SSH keypair, and can be pasted in much like a traditional password. I used this approach when migrating off the old username/password structure, and it is actually what Github seem to be recommending users migrate to in this situation.

More information: https://docs.github.com/en/enterprise-server@3.3/authenticat...

In terms of storing your credentials, is your current Excel file password-protected? If not, I would do this at a minimum if you are committed to the Excel approach, and it's very quick to apply.

Alternatively you might be interested in other client-side options such as KeePass, which are more secure and provide a simple GUI (although arguably not as immediately-navigable as a spreadsheet). This could provide a more comfortable stepping stone if you're not wanting to commit to one of the more mainstream cloud-based password managers. Full disclosure: There was a security vulnerability in KeePass a few years back, so it's worth keeping this in mind.

On your git CLI, type 'git remote -v' and you'll see something along the lines of origin git@github.com:<Account Name>/<Repo Name>.git (fetch) and (push)

You can edit that: git remote set-url origin <ssh-config-name>:<Account Name>/<Repo Name>.git

In your ssh config file, create the <ssh-config-name> entry with the hostname 'GitHub.com', user 'git', and IdentityFile the location of your ssh key.

You can create an unlimited number of configurations, each with a distinct ssh key. Set the origin url to use that configuration, and every repository can use a different account/key.

Just use a single SSH key per device, any more than that is redundant. If someone hacks your machine and a key is compromised, then all keys are compromised anyway... it does mean if one of your github accounts is hacked, then all your keys are compromised, it's a tradeoff on security...

Ask HN: GitHub and Bitbucket end support for password auth for CLI - Now what?