Generate a ssh key and disable password authentication on Ubuntu server

Update:There is now an updated version of this guide for Ubuntu 12.04: Generate a ssh key and disable password authentication on the Ubuntu 12.04 (Precise Pangolin) server

1. Generate the ssh key pair on the desktop computer:
ssh-keygen

2. Copy the public key to the server:
scp ~/.ssh/id_rsa.pub user@10.10.10.1:

3. Connect to the server:
ssh user@10.10.10.1

4. Append the public key to authorized_keys and remove the uploaded copy:
cat id_rsa.pub >> ~/.ssh/authorized_keys
rm id_rsa.pub

5. Edit the ssh server configuration to make sure that public key authentication is enabled (it should be enabled by default):
sudo nano /etc/ssh/sshd_config

5.1 These entries must be set to yes:
RSAAuthentication yes
PubkeyAuthentication yes

6. Reload the configuration:
sudo /etc/init.d/ssh reload

7. Disconnect from the server:
exit

8. Try connecting without the need to give the password to the ssh-client:
ssh user@10.10.10.1

You might need to give a password now to access your private key file, but you should not need to give the password to the ssh program.

9. Disable password authentication:
sudo nano /etc/ssh/sshd_config

9.1 The following settings should be set to no:
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

9.2. Reload the configuration:
sudo /etc/init.d/ssh reload

10. Test that password authentication really is disabled:
10.1 Disconnect from the server:
exit

10.2 Rename your private key file:
mv ~/.ssh/id_rsa ~/.ssh/id_rsa.backup

10.3 Try to reconnect to the server:
ssh user@10.10.10.1

This should produce a permission denied message: “Permission denied (publickey).”

10.4 Restore your private key file:
mv ~/.ssh/id_rsa.backup ~/.ssh/id_rsa

Done 🙂


Referens

Debuntu

21 thoughts on “Generate a ssh key and disable password authentication on Ubuntu server

  1. jb

    Thank you VERY MUCH for this useful guide. May I point out that you left out one step beetween 9 and 10:Reload the configuration:
    sudo /etc/init.d/ssh reload

    Reply
  2. yuvilio

    I had to take two extra permission steps on the machine i was sshing into to make it work due to this error: “SSH Error: Permission denied (publickey,gssapi-with-mic)” . Not sure if they’re relevant but here are the steps that did the trick.

    chmod 600 .ssh/authorized_keys
    chmod 700 .ssh

    After that, my sshing without password worked great.

    Thanks for the great tutorial!

    Reply
  3. David E. Miller

    The following two lines worked also worked on my Ubuntu 9.10 server also when added to the installed /etc/ssh/sshd_config file:

    UsePAM yes
    PasswordAuthentication no
    ChallengeResponseAuthentication no

    Note: The installed default is UsePAM yes and ChallengeResponseAuthentication no. Webmin added UsePAM yes to my file automatically because it was commented out.

    Hence, only adding

    PasswordAuthentication no

    to sshd_config works on my server with RSA public-key authentication.

    This is off topic, but since Webmin was mentioned it also added:

    IgnoreUserKnownHosts No

    to the sshd_config file as the installed default of yes was also commented out and the default for Webmin is no. I changed it back explictly to yes after I realized that this was causing logins to fail. The lesson is to always save a copy of the original config file and be careful when using tools like Webmin, etc. Editing config files directly is probably your best bet as well as uncommenting defaults first. This way you are certain of the config being actually used. Some Webmin modules save backups to config files and some do not. The ssh server module does not.

    Reply
  4. hayes

    effective tutorial! Well done.

    if you put the key on a USB drive and point to it with the -i modifier like this:

    ssh -i /USBDRIVE/id_rsa USERNAME@SERVER

    you dont have to rename the file. I have accidentally renamed the key.backup with cp and ended up with 2 copies of the key. or deleted them all with rm!!
    The less possible copies of the key the better i feel. You can also take it with you like a real key. Of course just remove the -i pointer to test no-key no-login. or pull the USB…
    ssh USERNAME@SERVER

    Reply
  5. Jawahar

    In my case, even after removing all the files in ‘.ssh’ folder in both client and server, the ssh works perfectly. Can someone explain about this?

    Reply
    1. lani78 Post author

      Maybe a late reply, but I have now experienced the same thing. Now on Linux Mint 12. For me it seems that the key is cached automatically by ssh-agent when unlocked by the key ring (at least this is my suspicion). I tried to kill the ssh-agent process, but it had been defuncted on my session. Maybe it is because it is a child process of gnome-session. So I restarted my gnome session (Ctrl+Alt+Backspace) and now I got the expected permission denied error.

      I have however found out that a much better way to test connecting with password authentication instead of the using the key file is to pass the parameter “-o PubkeyAuthentication=no” to ssh. Then there is no need to move the key file. You can see how I use this in my updated guide for Ubuntu 12.04: https://lani78.wordpress.com/2012/07/21/generate-a-ssh-key-and-disable-password-authentication-on-ubuntu-server-12-0/

      Reply
  6. Morgan

    @Jawahar ssh has builtin defaults that take affect unless you explicitly overwrite them with files under .ssh.

    Reply
  7. Pingback: Delicious Bookmarks for April 11th through April 12th « Lâmôlabs

  8. Pingback: basic Ubuntu Server setup with basic security | @tiredpixel

  9. zeptco

    Attempting to generate RSA for SCP I had to go through about 3 guides before I finally made it work. Most guides are not clear about what exactly SSH looks for when authenticating.. which is the /.ssh/authorized_keys FILE (not folder). I guess I like it more when tutorials explain how something works, not just show me how to do it. But this tutorial was the most helpful one so far.

    Reply
  10. cweks

    Hi,

    What does one have to do to get this to work from another machine where:

    a) that machine is running Linux and uses ssh
    b) that machine is running Unix and uses ssh
    c) that machine is running Windows and uses Putty.exe
    d) that machine is running MacOSX and uses
    e) that tablet is running Android
    d) that tablet is running Apple’s iOS

    Thank you

    Reply
  11. Richard G.

    I have an account that uses sftp to copy files from a Windows server to a Linux server on a daily basis. The client uses RSA keys to authenticate. Then one day, the password for the linux account expired. Suddenly the sftp sessions failed. I could see the keys were accepted and authenticated, but the sftp session refused to start. I was surprised to see that behavior in sshd.

    If I set either ChallengeResponseAuthentication and/or PasswordAuthentication to no in the sshd_config file, would that resolve this problem? It’s easy for me to extend the password expire time to something in the future, but at some point that future will become present and I’d be in this same situation again. And who knows if I’d remember the solution.

    I have to keep ‘UsePAM yes’ in our sshd_config file, because we use PAM for other stuff in our system. Would just like confirmation that:

    UsePAM yes
    ChallengeResponseAuthentication no
    PasswordAuthentication no

    would eliminate the situation I described above? Thanks.

    Reply
    1. lani78 Post author

      Hi Richard,

      Thank you for your comment. I’m affraid that I do not know the answer to your question. I have however never had this problem, and I have always had password authentication set to no. If you get luck another reader knows the answer.

      Regards,
      Lani

      Reply
  12. Pingback: Accessing the Raspberry Pi from the (Public) Internet » Andrew Cox

  13. kurt (@xurt)

    Nice!
    It just works.
    I like the
    ssh -o PubkeyAuthentication=no user@server
    to test restriction, as mentioned above.
    Also mentioned above, the chmod on key files/directories is a good idea if not required. I’ve run into ssh not working until I did this (in the past), so I just do it out of habit.
    I’m combining this with VNC to remote control Mac -> Mint 13.
    Thanks!

    BTW, unlike above, if I have to choose, I prefer just “how to” vs. lengthy, intervening explanation of what and why–though what and why at the end is welcome. This article was short, sweet, great!

    Reply
  14. Pingback: A good guide to creating SSH keys and disabling the password for an SSH login. | Securitron Linux blog.

Leave a reply to lani78 Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.