4 ms·
Ask HN: GitHub and Bitbucket end support for password auth for CLI - Now what?
When username/password based authentifiction ends for command line interaction (git push, git pull,...), I want to switch to SSH key based authentication. Since I have not much experience here I want to explore best practices.
My scope:
I have tons of repos on Bitbucket and Github owned by about 10 Bitbucket / Github accounts. They are spread over multiple organizations and cannot be tied together.
Some accounts I just need every few months. I need to access these repos from about 30 different git client machines.
Up to now I used usernames and passwords stored in a excel file. That worked well although I know about this pretty insecure way of handling credentials. But I had a perfect overview over all logins.
When switching to SSH key based authentication, things get more secure but also more complicated. Websites still use usernames/password but command line interfaces require SSH keys. So we have more credentials to manage.
My questions are:
* What are best practices to manage private and public keys as well as all these usernames/password for the web ui's?
* How keep a good overview over all git credentials?
* Can I store SSH keys in my Excel-File?
* How many SSH keys would you recommended for my scenario?
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.
- fivelessminutes 5y agoYou 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.
- 0xdeadb00f 5y agoThis 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.
- krageon 5y agoAlternately 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).
- gitgud 5y agoJust 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...
- cr3ative 5y agoI 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?"
- weezee 5y ago> 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!
- pqb 5y ago> 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/ https://www.passwordstore.org/ [1]: https://github.com/gopasspw/gopass https://github.com/gopasspw/gopass [2]: https://github.com/android-password-store/Android-Password-Store https://github.com/android-password-store/Android-Password-S...
- frumiousirc 5y ago> * 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.
- rgoulter 5y ago> 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?
- Kon-Peki 5y ago> 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).
- Kon-Peki 5y agoOn 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.
- iamwpj 5y agoI'll just add some things I think are missing: * Here's GitHub's guide: https://docs.github.com/en/authentication/connecting-to-github-with-ssh 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?
- weezee 5y ago> 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.
- trilinearnz 5y agoFor 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/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token https://docs.github.com/en/enterprise-server@3.3/authenticat...
- trilinearnz 5y agoIn 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.