How to Enable Passwordless SSH Logins on Linux

SSH Passwordless Login Linux

It’s an excellent idea to sign in to your secure server without a password. Seriously, get rid of it. There’s no need to use a password on one of the most attacked services on web servers, right?

Okay, enough joking. It’s true, though. Standard password-based authentication on SSH is a bad idea. Passwords can be broken fairly easily, and when they’re the only thing standing between an attacker and unfettered access to your server, you should definitely be nervous.

That’s why RSA key-based authentication is much better. You can configure your Linux server to only allow access from computers that hold the RSA keys that it has already accepted. Anyone else will be rejected immediately. As an added benefit, you can create those keys with or without a password, which is entirely up to you. A strong key without a password is fine in most cases, though.

If you use Linux devices at home too, you have the added benefit of convenience. Say you want to SSH in to your Linux workstation from your laptop. Do you really want to enter your password every time? Set up SSH keys, and you won’t need to.

There are a couple of packages that you need. You probably already have some of them, but it’s a good idea to check. The packages are different on the server and the client, but there’s also a good chance that both machines are servers and clients to each other (home situation), so you may want to install both sets of packages.

On the Server

The server just needs the OpenSSH service installed and running. It isn’t by default on Debian and Ubuntu systems. If you don’t already have it installed, do so.

On the Client

The client needs the OpenSSH client package. OpenSSH has a built-in utility for generating keys.

Generate SSH Key

It’s really easy to generate your key. Just tell OpenSSH that you need to generate the key. It’s also a good idea to specify the amount of bits with the -b flag and the type with -t. A 4096 bit key is best. It provides stronger encryption.

First, the utility will ask where you want to store the key. Just hit Enter for the default directory. Then it’ll ask for a password. Leave it blank for a passwordless key and passwordless authentication. If you do want to use a password for your key, enter it.

Your computer will take a couple of seconds to generate your key. When it’s done, it’ll tell you that it finished and print out an ASCII art image.

To use your key you’ll need to send it to your server. OpenSSH has another built-in utility for that, too. Tell it where your key is and which user on the server to associate it with.

Enter the IP address of the server. It’s just like you’re accessing the server over SSH (you are), but it’s just sending over the key.

After that, try accessing the server over SSH again. This time it should just let you in without a password.

For the best security, you need to disable SSH password logins on the server. The SSH server configuration can be found at “/etc/ssh/sshd_config.” Open that file on the server with sudo and your favorite text editor.

Disable Password Login SSH

Find the lines below and edit them to look like the example. Uncomment both entries and change the values to no.

Disable PAM SSH

That won’t do anything if you leave PAM authentication enabled. Find the line below and set it to no.

Once the entries are modified, save and exit the file, and then restart the SSH server for them to take effect.

If you are still determined to retain the password authentication method, don’t forget to set up two factor authentication as an additional layer of protection.

That’s it! Your server is much more secure now without passwords. You also also have the added benefit of not needing to type them in. You can also exchange your single key with as many servers as you’d like.


    • One should have passphrase on ones ssh keys. But as you wrote, with ssh-agent, one only need to add that password once.

      One should also avoid have the ssh logins to form a ring. Because then if any machine is cracked, then there is possible to use ssh (with no password) and get into all the machines, just following the login trace around the machines. And yes, just type history and you will see what machines you can reach.
      Instead one should probably use a star or tree formation, where the most important machine are in the middle. Then if one get one of they machines cracked, they can’t get back to the most protected machine in the middle. Just out to less important ones.

  1. As I have learned the hard way, a mistake in the config file can lock you out of your machine without any way to remotely undo your changes. Here’s a simple way to make sure that doesn’t happen (again).
    First, make a backup of sshd_config before making any changes to the file.
    $ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
    Then, before restarting the sshd daemon, use the ‘at’ command to automatically roll-back your changes at a specified time (in case you are unable to log back in).
    $ echo “cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config” | sudo at now + 10 minutes
    In this case, I’ve created an ‘at’ job that will run as root and will execute the specified ‘cp’ command at 10 minutes now.
    If you can log in successfully before the roll-back is executed, use ‘sudo at -l’ to get the job id and ‘sudo at -r ‘ to remove the scheduled job so that it does not execute.

Leave a Comment

Yeah! You've decided to leave a comment. That's fantastic! Check out our comment policy here. Let's have a personal and meaningful conversation.

Sponsored Stories