![[protofusion]](http://protofusion.org/wordpress/wp-content/uploads/2013/02/protofusion-text2.png)
Need passwordless auth with ssh? Need it really really fast? 3 steps and you’re done.
- ssh-keygen -t rsa (don’t enter a passphrase)
- ssh-copy-id -i ~/.ssh/id_rsa user@remotehost
- ssh user@remotehost
Wasn’t that easy?
Ethan is a computer engineer and open source hardware/software developer from Michigan. He enjoys AVR and linux development, photography, mountain biking, and drinking significant amounts of home-roasted coffee. Find out more at ethanzonca.com.
Note that creating passwordless SSH keys leaves the keys more vulnerable to anyone woh can physically access your computer or who manages to get the contents of your .ssh/id_rsa file. Thus, this approach is especially not suitable for devices like laptops or even the casual desktop installation. I would recommend only using it if you can ensure some conditions.
First, the server’s data should be effectively physically inaccessible (use disk encryption, have the server in a secure facility (for more casual use, you can probably assume a hosted VPS or collocation solution is physically secure), never do this on your laptop which can easily fall into another’s hands).
Secondly, the accounts whose .ssh/authorized_keys you paste the key’s contents into should be restricted and *never* privileged or have access to other accounts on the target computer. You can secure an account or particular key by limiting the key’s usage by how you install it into other machines’ .ssh/authorized_keys (e.g., command=”echo”, no-pyt, other options—check the docs or Google how to restrict access in authorized_keys).
The first condition is to reduce the chance that someone else gets their hands on your raw key. The second condition is basically that you should limit the the SSH access of this key so that if/when it is compromised, the attacker can only do limited damage. You can always generate a new key and delete the old key’s .ssh/authorized_keys entries later. And if the key only has permissions to, say, forward one port to another service and that service has at least *some* security around it, you have started mitigating the security concerns that come with an unprotected key.
And even if you can encrypt your key with a password, you should strive for both of the conditions as much as possible. Password-based key encrypt will not stop someone with enough brute-force power—and it’ll even be less useful if your password is a dictionary word.