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/
The key fingerprint is:
44:3e:ef:58:94:15:52:c2:88:ca:ab:21:43:53:3d:42 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.

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/ to the server’s ~/.ssh/authorized_keys:

fabio@morpheus:~$ ssh-copy-id -i .ssh/
15's password:
Now try logging into the machine, with "ssh ''", and check in:


to make sure we haven't added extra keys that you weren't expecting.


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.


At this point, user’s account on the server can be locked for password authentication. On Linux systems, one can make: passwd -l ornellas

to lock ornellas account. Key authentication will still be possible.

Now, try to access the server:

fabio@morpheus:~$ ssh
Enter passphrase for key '/home/fabio/.ssh/id_rsa':

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


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:



Posted by Anonymous (213.200.xx.xx) on Thu 7 Jun 2007 at 12:15
Also to note is that you should use keychain. To simplify things so you dont need to enter your passphrase all the time when you are using your ssh-key.

[ Parent | Reply to this comment ]

Posted by Anonymous (134.76.xx.xx) on Thu 7 Jun 2007 at 21:19
You can also use ssh-add for that purpose

[ Parent | Reply to this comment ]

Posted by Anonymous (150.203.xx.xx) on Fri 8 Jun 2007 at 01:59
... and ssh-agent.

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

[ Parent | Reply to this comment ]

Posted by Anonymous (212.235.xx.xx) on Fri 8 Jun 2007 at 07:54
What would be really great is seeing an article on how to set up Kerberos across debian machines. That would be more secure, and much more interesting to read.

This is however a good article, although I think most people already know all that.

[ Parent | Reply to this comment ]

Posted by taylor (206.107.xx.xx) on Fri 8 Jun 2007 at 15:24
i think that the problem with this solution is the false sense of security that it will give to the average administrator. while it may reduce the risk associated with weak passwords, there are numerous ways in which to enforce a strong password/passphrase policy (i.e. pam_passwdqc and pam_cracklib), and mechanisms to prevent brute force attacks against user passwords (i.e. pam_tally and denyhosts).

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.


[ Parent | Reply to this comment ]

Posted by ajt (85.211.xx.xx) on Fri 8 Jun 2007 at 16:40
[ View Weblogs ]
I agree that SSH keys are not a cure-all. Good pass-phrases are something that most people can't create, and while keys and tools like ssh-agent and ssh-keychain make life easy for the skilled operator they don't magically stop people from making easy to guess or pass-phraseless ssh private keys.

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"

[ Parent | Reply to this comment ]

Posted by neofpo (200.185.xx.xx) on Sat 9 Jun 2007 at 16:31
[ View Weblogs ]
All points made by taylor are correct. I agree with all of them.

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 ]

Posted by neofpo (200.185.xx.xx) on Fri 15 Jun 2007 at 04:30
[ View Weblogs ]
I remembered just now:
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 ]

Posted by chrisrend (65.89.xx.xx) on Wed 13 Jun 2007 at 17:20
[ View Weblogs ]
Hello all, I have an SSH/SFTP question in regards to the new version in Etch.

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!


[ Parent | Reply to this comment ]

Posted by Anonymous (68.15.xx.xx) on Thu 14 Jun 2007 at 06:28
What do you do when it doesn't work? I still get prompted for a password. The keys are there though. Could it be that I am doing it from a ubuntu client and a centos server? It all says rsa but the pub file on the server says authorized_keys and not authorized_keys2. I am confused and frustrated. Why can't something just work?

what next?

I don't think I did anything wrong your directions were pretty straight forward.

[ Parent | Reply to this comment ]

Posted by Utumno (61.223.xx.xx) on Fri 22 Jun 2007 at 13:25
[ 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 ]

Posted by Anonymous (83.238.xx.xx) on Tue 26 Jun 2007 at 12:19
Warning! You need to disable PAM in /etc/ssh/sshd_config to disable passwords. Setting "no" to PasswordAuthentication is not enough. You might think you disabled passwords, use keys all the time and still have passwords working if you don't check that.

[ Parent | Reply to this comment ]

Posted by Anonymous (200.185.xx.xx) on Fri 29 Jun 2007 at 00:00
Or lock user's account with passwd -l.

[ Parent | Reply to this comment ]

Posted by stoffell (81.164.xx.xx) on Thu 6 Sep 2007 at 20:25
Maybe not really in the scope of the article but I found this to be very useful:

It acts as a proxy for all your outgoing SSH connections. Too bad development has stalled..


[ Parent | Reply to this comment ]

Posted by Anonymous (193.252.xx.xx) on Tue 11 Dec 2007 at 17:12
It looks like it has started again, version 0.6.0-beta0 is out since a few days...

[ Parent | Reply to this comment ]

Posted by pedrosk (108.98.xx.xx) on Thu 25 Nov 2010 at 01:22
Followed instructions and locked myself out of my laptop. Reinstall! Gotta love when it does not work right!

[ Parent | Reply to this comment ]

Posted by Anonymous (87.162.xx.xx) on Wed 3 Aug 2011 at 03:45
Yeah me too.
Don't follow the "passwd -l username" instruction!

[ Parent | Reply to this comment ]

Posted by Anonymous (213.114.xx.xx) on Fri 19 Aug 2011 at 06:17

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 ]

Posted by Anonymous (184.147.xx.xx) on Thu 27 Sep 2012 at 13:36
Can we generate the key on the server? Android has SSH clients but seems to be missing ssh-keygen. (Some clients have key generators built in, but not all.) In that case which file goes to which machine?

[ Parent | Reply to this comment ]

Posted by Anonymous (212.110.xx.xx) on Thu 8 May 2014 at 09:20
You can, but that does not mean you should.

Generating the private key on the server means that anyone who is controlling the server can access it. Root can access it. If the server has been compromised, it is possible that someone modified the ssh-keygen program and retrieves automatically all the private keys generated.

It is better to generate the keys on a machine of yours, then copy the private key on the Android (assuming the SSH clients can use public key schemes yet can't generate them), and the public key on the server.

[ Parent | Reply to this comment ]

Sign In







Current Poll

Will you stick to systemd as the default in Debian?

( 895 votes ~ 35 comments )