Most developers will interact with resources that use SSH keys instead of passwords. I recently overheard someone say that he uses the same SSH key...
For further actions, you may consider blocking this person and/or reporting abuse
Nice article. I recommend adding a comment and a file name to ssh-keygen.
Examples:
Good post. Another ssh_config trick i sometimes use is ForwardAgent, so i can connect through to a third party service directly from a tunneled server using my local ssh_agent. (Like if you have to connect to github from a remote server)
The private key should never ever leave your computer. If you have single compromised key that means someone's been in your system and you might as well treat them all as compromised
Therefore, by having multiple keys you don't gain any additional security, you only gain additional headache each time you restart the system and have to
ssh-addeach one of themI'd recommend using
ed25519 is much better than RSA - more secure, shorter keys.
E.g. see medium.com/risan/upgrade-your-ssh-...
This is an excellent point. While researching this article, I was surprised to see that Bitbucket documentation uses RSA by default (April 2021). I'll likely change my first step to recommend ed25519 when I have a chance to do some edits.
Thanks Joseph, this really is something I should do more often than I do (to reduce the attack surface of a compromised key)! I tend to separate by activity area (ie: work, home, project) rather than individual targets.
Also worth noting is that password managers frequently integrate via
ssh-agent(eg: techrepublic.com/article/how-to-in...), which can help keep everything tidy and safely enable portability (how many times have I left my offline key store at home.. sheesh!).As a final security comment, ssh private keys are only as safe as their pass-phrases, so when you say "Use a passphrase when prompted.", that's likely the weakest link in this setup - possibly another good reason to delegate to a password manager with a strong pass phrase.
I agree that password managers are a must, and I struggled with how in depth to make this post to keep it beginner friendly. I'll use your suggestion for an optional/advanced section when I have time to do some edits.
One thing to bear in mind is that the ssh config setup (specifying which identities to use for which hosts) is important here. I've seen situations where having too many personal keys (in your ~/.ssh/ directory) caused login failures (when not IdentityFile is passed, the ssh command will offer them one by one to the remote, and the remote will interpret this as a brute force/too many failed logins attempt).
It's possible adding a
host: *section with a preferred default key may be all that's needed to address that.Just add here, I also use simple utility called stormssh. It's a simple command utility for managing ssh config file easily.
Example:
storm add --id_file ~/.ssh/your_key production-server dev@your-domain.comAnd config file in
.sshfolder looks like:Then you can connect to server as
ssh production-server.Nice article. However, I still don't understand the use of multiple key pairs as mitigation of a compromised private key. The private key should exist strictly on a single device, while the public one may exist on many. If a private key is compromised that would mean the same for all the rest existing ones on the same device.
Very useful article: everybody has a use of a reference on how to create and configure private keys. 👍🏻
The only thing I don't understand is: what angle of attack would require the use of different keys for every account? It seems to me that one key by device is enough:
Am I missing something ?
Thanks. I've had my private keys on one or more work computers in addition to my personal laptop. If the machine isn't mine, I want to be able to limit access to the key. I've also shared keys with others for team resources, which also makes multiple key management necessary.
Note I have a personal github and a work github account... and I used something like this instead:
//personal account for github.com, note can also choose to leave this as 'Host github.com' if dont' have other keys and want this to be the default
Host github-my_personal_username
HostName github.com
User git
IdentityFile ~/.ssh/id_rsa-github-my_personal_username
// IdentitiesOnly yes
//work account for github.com
Host github-my_work_username
HostName github.com
User git
IdentityFile ~/.ssh/id_rsa-github-my_work_username
// IdentitiesOnly yes
and just change the clone url slight when needed:
$ git clone git@github-my_work_username:me/repo.git
This already sounds like a trivial question, but I need to ask it anyway:
How need I name the "config" file.
.config?config?config_file?ssh_configIs there a difference?
Adam, on a Mac, the file is just named "config" without any punctuation. The file should be located in ~/.ssh/config, so you could create it by typing.
Second question I have: you said to create the
known_host_keynamefile.What exactly should I put in there?
My privet and public keys? 🤷♂️
This is not clear to me.
You only need to create the file. You don't need to put any text inside.
Didn't know about pbcopy, useful command
Excellent article. In step five is there a reason not to use ssh-copy-id instead of the copy and paste method?
I think the reasoning for copy/paste is that the goal was to add keys to services like github and bitbucket (where there's no obvious way to use ssh-copy-id).
Is it bitbucket.com or bitbucket.org?