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.
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.
* 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 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.
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 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...
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?
More information: https://docs.github.com/en/enterprise-server@3.3/authenticat...
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.
You can edit that:
git remote set-url origin In your ssh config file, create the 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.