6 ms·
SSH key and passwordless login basics for developers
- mattdeboard 14y agoSaved this and passed to my programmer co-workers. It seems to be a very rare commodity to understand this topic where I live.
- miohtama 14y agoNice that you find this useful :)
- h2s 14y agoThe output of "man ssh_config" is popular here lately isn't it? It was on the front page in a different guise only four days ago. http://news.ycombinator.com/item?id=4677049 http://news.ycombinator.com/item?id=4677049
- Millennium 14y agoIt's useful stuff. What I'd really like to see, though, is a tutorial for using SSH keys from a thumbdrive in a way that doesn't depend on Gnome or KDE.
- chuppo 14y agossh 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.
- thaumaturgy 14y agoYour tone is not acceptable here.
- Millennium 14y agoThe 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.
- thaumaturgy 14y agoPlug 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. Does that help?
- thaumaturgy 14y ago"ssh -i /path/to/key" seems like it would do what you want, which makes me think I don't understand the problem you're trying to solve.
- ta12121 14y agoIt might be useful, but it's trivially obtainable by anyone who needs it by googling, and irrelevant to anyone who isn't looking for it at the time.
- viraptor 14y agoIf 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...
- chuppo 14y agoSeems the "secure your ssh" articles which contain snippets from "man ssh_config" is returning every week now on HN. Jesus Christ people, if you need an article to use a simple tool like dont even bother.
- VBprogrammer 14y agoAre 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.
- mturmon 14y agossh 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.
- thaumaturgy 14y agoUnless 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.
- h2s 14y ago> Better still is to use, 'passwd -d -l [user]', > which will delete the password and then lock it. Better yet, set PasswordAuthentication to "no"
- thaumaturgy 14y agoHow is that better?
- ericcholis 14y agoI know there are a thousand tutorials on each of these topics, but it's nice to have them all in one place.
- jackalope 14y agoAgent 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.
- viraptor 14y agoYou don't need it. github works just fine without forwarding.
- klj613-- 14y agoyou need agent forwarding to ssh into a server to do a git pull from _that_ server. e.g. a dev vm.
- munificence 14y agoFrom the ssh man page: 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.
- jackalope 14y agoSorry, 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).
- deleted 14y ago[deleted]
- djhworld 14y agoI'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
- apawloski 14y agoThis 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.
- jackalope 14y agoUnless you're forwarding your agent, in which case a separate key might be a good idea.
- spindritf 14y ago> 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.
- apawloski 14y ago>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.
- bcl 14y agopasswordless sudo access to root? Not a great idea. If you don't like typing your sudo password so often just change the timeout. I'd also suggest using ssh-add -t <timeout> to limit the lifetime of your ssh keys in the agent.
- dredmorbius 14y agoThere's also a PAM module that will forward sudo authentication requests over your SSH authentication socket.
- miohtama 14y agoHave you more details? I tried to find this kind of module but no dice.
- joshstrange 14y agoFor setting up a remote computer for SSH key login I use this little snippet that I think I found on HN not too long ago cat ~/.ssh/id_rsa.pub | ssh USER@HOST "cat >> .ssh/authorized_keys" 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.
- viraptor 14y agoNew openssh already has this covered in a more standardised way: ssh-copy-id USER@HOST
- danielwozniak 14y agoInstead of password-less sudo you can use `sudo -s` to get a root shell. `sudo -sE` for a root shell but preserve your user's environment variable.