SSH with authentication key instead of password
Posted by neofpo on Thu 7 Jun 2007 at 09:42
SSH is a must use tool for system administrators. However, residing access security on a human entered password is not very wise. Script kiddies may break into your system due to a lazy user with a weak password. And it is beyond the system administrator power to make users choose good passwords.
The good news is that there is a way to leave remote access open and have not to worry about passwords. The method consists on authentication via asymmetric cryptography. The user’s private key is the one that grants the authentication. You can even lock user’s account to disallow completely password authentication.
Another advantage of this method, is that one does not need different passwords to log on different servers. One can authenticate via the personal private key on all servers, needing not to remember several passwords.
It is also possible to make logins with no password asked with this method.
How to do it
Generate the authentication key
On the client machine, the user must generate a public / private keys pair that will identify himself on the servers. One can choose to protect it with password or not.
Letting it with no password, means that anyone with access to the key files (eg. root on the client’s machine) will have the same level of access of the user and no password will be asked when the client tries to connect to the servers.
Protecting the keys with password means that every time the user tries to connect to a server using those keys , the password for decrypting it will be asked. This is surely more secure, since anyone who can read the key files, will only see an encrypted version.
To generate the key pair do:
fabio@morpheus:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/fabio/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/fabio/.ssh/id_rsa.
Your public key has been saved in /home/fabio/.ssh/id_rsa.pub.
The key fingerprint is:
44:3e:ef:58:94:15:52:c2:88:ca:ab:21:43:53:3d:42 fabio@morpheus
fabio@morpheus:~$
Just let the default file (~/.ssh/id_rsa).
Enter the password at choice, as explained before. If you need to
change the password or add one, do:
fabio@morpheus:~$ ssh-keygen -p
Enter file in which the key is (/home/fabio/.ssh/id_rsa):
Key has comment '/home/fabio/.ssh/id_rsa'
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.
fabio@morpheus:~$
In this case, a new password was added. Note that this operation does not change the public / private key pair. It only changes its encryption.
Install the public key on the servers
Once the public key is installed on the server, access will
be granted with no password question. SSH
usually comes with an utility called ssh-copy-id
that simply adds the contents of client’s ~/.ssh/id_rsa.pub
to the server’s ~/.ssh/authorized_keys:
fabio@morpheus:~$ ssh-copy-id -i .ssh/id_rsa.pub ornellas@apanela.com
15
ornellas@apanela.com's password:
Now try logging into the machine, with "ssh 'ornellas@apanela.com'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
fabio@morpheus:~$
Note that at this point password access is needed. This procedure can be done by any other way you wish. For example, the server’s administrator himself can add the public key to allow a user access, instead of giving him a password.
Access
At this point, user’s account on the server can be locked for password authentication. On Linux systems, one can make:
root@apanela.com:~# passwd -l ornellas
to lock ornellas account. Key
authentication will still be possible.
Now, try to access the server:
fabio@morpheus:~$ ssh ornellas@apanela.com
Enter passphrase for key '/home/fabio/.ssh/id_rsa':
ornellas@pound:~$
On this case, the client’s key was encrypted and its password was asked. If it had no password, nothing would have been asked, and access would be direct:
fabio@morpheus:~$ ssh ornellas@apanela.com
ornellas@pound:~$
Conclusion
This method enhances security a lot and also helps to manage
access
to many servers without many passwords. There are other cryptography
algorithms and options to use other than the default RSA.
Please reffer to ssh-keygen(1) to more
information.
The latest version of this article can be found at:
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
For what it's worth, I've written a script which automates the process of allowing new terminal sessions to get the authentication information from an existing ssh-agent, or start up the ssh-agent automatically.
Check it out at http://manicdee.livejournal.com/18466.html
[ Parent | Reply to this comment ]
This is however a good article, although I think most people already know all that.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
the temptation among users who decide to use public key authentication will be to create keypairs without passwords or with the weak passwords that you are trying to prevent them from using on your server. what happens when their personal system is owned? the attacker then has access to the user's private key and can access your system without having to bother to take the time to install a keystroke logger or replace the ssh executable.
yes, the risk of this sort of attack can be mitigated by storing the keys on removable media that is only attached to the system when in use, but now you are starting to create additional steps which will be seen as an inconvenience to the average user and they will quickly begin to get lazy.
my point here isn't to disavow the utility of ssh public key authentication, but to highlight the fact that it isn't a security silver bullet. personally, i would only allow ssh public key authentication in controlled environments (i.e. corporate network), or on public servers to which only experienced administrators with a high level of security awareness would connect.
on a public server which has a mixed userbase of people with different skillsets, i would much prefer to set a strong passphrase policy, require regular passphrase changes and enforce this through the mechanisms that i mentioned at the beginning of my comments.
of course, security must be recognized as being a process rather than a technical solution, so an administrator needs to take the time to analyze the risks associated by their server and use technical solutions to mitigate these risks or enforce policies.
of course, ymmv.
taylor
[ Parent | Reply to this comment ]
I don't think the original article made it sufficiently clear that you should use a good strong pass-phrase to lock your key, and you should tie the permissions down properly on the file and not leave it lying around...
--
"It's Not Magic, It's Work"
Adam
[ Parent | Reply to this comment ]
Security is made of 3 points: people, process and tools. I tried to give one more tool. How and when to use it securely is up to the administrator. There is no general rule, each case is a case.
I'd appreciate an article about PAM security, I have never found myself time to learn about PAM (although I know it is very powerful).
Thanks for the comments guys.
[ Parent | Reply to this comment ]
http://www.debian.org/doc/manuals/securing-debian-howto/
This is a VERY good Debian centric manual teaching all sorts of things to secure your system. Many random tips that even experienced administrators may forget.
[ Parent | Reply to this comment ]
I used to use the sftp -b option with a password but now it looks like sftp batchmode disables the password authentication at the prompt automatically. I don't want to automate the transfers completely with a key and cron. I just dont want to have to enter the same commands everytime and still want to authenticate via a password entered at the prompt by manually running sftp and entering a password. Is there any way I can still do this with the updated sftp using a command file? I have searched the web and found no solution, any help is appreciated thanks!
Chris
[ Parent | Reply to this comment ]
what next?
I don't think I did anything wrong your directions were pretty straight forward.
[ Parent | Reply to this comment ]
[ Send Message | View Utumno's Scratchpad | View Weblogs ]
Nowhere in the article had author uttered the word 'authorized_keys2'. Obviously you're not following the article.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
http://penguin.fr/sshproxy/
It acts as a proxy for all your outgoing SSH connections. Too bad development has stalled..
---
stoffell
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Don't follow the "passwd -l username" instruction!
[ Parent | Reply to this comment ]
I had a similar problem! I tried to run the copy-id command on the server (which in fact was a Synology NAS) and that didn't work (since it doesn't have that utility), but even if the NAS would have had the copy_id command it wouldn't have worked since it's the wrong place to run that command...
The copy-id command is supposed to be run on the machine where the secret key is located... And the passwd -l command is supposed to be run on the SERVER where the public key is located...
So, I'd like a little better highlighting on where certain types of code is supposed to be run. (I know you have the prompt with the server name, but I still think you could add the instruction on where to run the command in the text above it as well...)
However, once I figured out I only had to stay on the client machine to run most of the code (and fortunately did not try the passwd -l command on the client) it worked like a charm.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]