This was mentioned before, but if this post gains traction it's worth talking about again:
It is almost totally unnecessary to maintain multiple key pairs for multiple purposes if they're going to be stored on the same machine (eg separate key for github). If one of these services is compromised, an adversary will only get your public key, which is useless. This is very different than the security practices of symmetric passwords.
- Use a key specific to a given client system from which you connect. E.g.: separate keys for your work and personal machines. If one or the other is compromised, delete entries for the compromised key in your authorized_key files.
- Use shared keys, where necessary, for group infrastructure in a work setting. Examples might be an AWS login or other systems for which a single key is permitted (really, such cases should be rare).
- Use separate keys to make use of forced commands. These keys are single purpose, and are used to run a single command on a remote host (or set of hosts). They aren't general-purpose login keys.
It is good practice e.g. if you are a contractor and work with multiple organizations.
When your project is done you simply wipe the related SSH key. This way you can be sure that they cannot ask you to do some more work without proper legal framework (no more access, sorry) and you can prove that if there are compromises they were not done using your credentials.
> If one of these services is compromised, an adversary will only get your public key, which is useless.
True, but what if you connect to that system while it's compromised and under attacker's control? What if you want to separate your identities? What if you want to limit your responsibility and be able to just permanently delete the key after you finish working with some system thereby completely revoking your access to it? What if you want to store passwords to some keys in your system keyring but enter the pass every time for others?
Yeah, yeah, those are not exactly common but maintaining more than one key costs you nothing and adds a little flexibility.
>True, but what if you connect to that system while it's compromised and under attacker's control?
I don't follow you on this one. Could you expand a little bit?
>What if you want to separate your identities?
Sure, you can do this to preserve some privacy if you think the services might collude. But my point is that multiple keys don't make you more secure. (It's not like symmetric encryption where you should be using different passwords for everything.)
>What if you want to limit your responsibility and be able to just permanently delete the key after you finish working with some system thereby completely revoking your access to it?
This is a fair point, although having continued access is only a problem if an adversary gains control of the machine containing your private key (and in that case it's usually game over anyway). It's the job of the sysadmin of the other server to revoke authorized_keys as needed.
>What if you want to store passwords to some keys in your system keyring but enter the pass every time for others?
Again, a fair point, but this is only a risk if a bad guy has control of your machine. In general I'm referring to the misconception many people have that using multiple keys protects them if an external service is compromised. While this is true for passwords, for asymmetric crypto, revealing a public key is not really a problem.
If you're already running ssh-agent for your session, just do `ssh-add /path/to/the/key` - now it will be picked up automatically. If you want to do this automatically, it would require something waiting with inotify on the mount point, or some udev magic...
ssh doesnt depend on Gnome or KDE, what are you talking about?
These articles are spam. They are collections of snippets from various man pages and other older resources on the internets. If you think theyre useful, go back to the study room, youll not advance your skills by expecting "tutorials" on how to use ssh without kde(!?). Your asking the wrong questions, and will be led down a fruitless path.
The problem isn't SSH itself, but the tutorials out there tend to assume that you're using GNOME or KDE (or, more to the point, their automount systems). If you're not running either one, you're left trying to figure out how to deal with that problem.
Plug in the flash drive, then "tail -n 20 /var/log/syslog" (on most systems, and assumes the system isn't very busy), and look for the notification of the plug-in event with the device node, e.g. /dev/sdb1.
Then, "mount /dev/sdb1 /media/flashdrive", replacing the device node with whatever you see in syslog, and the mount point with the appropriate folder on your filesystem (really, whatever you want it to be -- you can mount something to your home folder if you like). 'mount' should be able to auto-detect the filesystem on the device unless you're running a really old Linux or BSD.
Are you honestly saying you have never discovered something new about a simple tool by reading a tutorial or watching a colleague? If you are fully able to understand the usage and implications of every simple Unix tool based solely on the man page then you are far smarter than not only me but every person I've ever worked with.
ssh is not a simple tool, it just started out as a simple tool. And, it occupies a key role, for better or for worse, as the base layer for secure communications in a unix environment (and beyond).
Combine those two facts, and it's not surprising how many articles there are explaining the ins and outs of ssh.
I've been poring over unix man pages for about 25 years, and we all know their terseness is a delight and a frustration. ("Sharp and newline surround comments." -- takes a minute to parse.) These articles are trying to add words to address the frustration part.
Unless I missed something while skimming this, they're suggesting that you set your password to "something random" and then go on to use ssh keys. This means that a brute force attack is still feasible (if super incredibly unimaginably unlikely). Better still is to use, 'passwd -d -l [user]', which will delete the password (it creates a nonsense hash value, "" I think) and then lock it.
While you're messing about with config files, make sure that "PermitRootLogin" in /etc/ssh/sshd_config is set to "no" (this is now default in most distributions I think), and also add an "AllowUsers [user] [other user] [...]" line thereabouts, which will help to protect you from misbehaving packages or someone attempting to add remote users to your system without your permission.
It should go without saying that if you do all this, and you somehow lose your private key, and you don't have a good backup as the article suggests (for whatever reason), and you don't have some kind of local console access, then you're pooched. Private key management is easy to screw up, so don't scoff. Make sure you have some other way of accessing your machine if you can't get to your private key.
If they can get to your console, you've already lost. And I know it might be OT to put it in this subthread, but just to bin up some of my responses:
- Yes, this is a repost, and yes, I had a similar reaction to many of "people still don't know about this?!", but if someone comes away using SSH with keys after reading this article, then it's worth it. It'd be nice if every programmer out there had some sys admin experience, but it's not going to happen.
- SSH keys depends on KDE or GNOME? That ought to surprise the Windows and Mac users (not to mention all those BSD/Linux/UNIX users who don't use KDE or GNOME) who use SSH keys. Last I checked (last time I logged into a freshly booted system), you ran ssh-add on first login, and if that doesn't work (or you have to do it for each shell/session), check the man page for keychain[1].
passwd -d destroys the ability to a) log in from a console and b) to use sudo, which might well be a dealbreaker for most people. Disallowing password auth in your sshd_config is typically a better option.
Of course the receiving server mush have a ".ssh" folder in the user folder and "authorized_keys" must exist "touch ~/.ssh/authorized_keys" but it is a super easy way to add your key to the remote server. Just thought I would share, I hope someone else finds it useful.
Agent forwarding is tremendously useful, but you should not forward your agent to systems you don't control or can't trust. If you do, you risk having your agent hijacked and used to connect to any system where you have public key authentication enabled.
The author implies that you need to enable agent forwarding to do a git pull from GitHub, but that would be incredibly dangerous. This can't possibly be true, can it? If so, you might as well hand them your private key and passphrase.
Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent’s UNIX-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.
Sorry, I didn't mean to suggest that they could obtain the key, just that hijacking the agent was equally dangerous (provided they know where to use it).
I'm a java developer and most of my colleagues have no idea how this stuff works, or even use it themselves. I've had to explain these concepts to my peers many times
It is almost totally unnecessary to maintain multiple key pairs for multiple purposes if they're going to be stored on the same machine (eg separate key for github). If one of these services is compromised, an adversary will only get your public key, which is useless. This is very different than the security practices of symmetric passwords.