SSH (Secure Shell) is a cryptographic network protocol which is used for establishing secure connections between a remote client and a server, using the TCP protocol for security and reliability.
SSH based connections support various authentication methods, some of them being :
- Password based authentication
- Key based authentication
By default, creating a new SSH connection between two machines will use the password based authentication. But if you are logging onto a server on a frequent basis from the same client, it may be cumbersome and irritating to type the password each time you login to the server.
This tutorial presents the other alternative authentication for logging onto the remote server, using public keys.
Let’s look at how we can set this on our particular client and server machines that we use frequently, so that we can automatically login from this machine securely!
Table of Contents
Check for existing SSH Keys on the Client Machine
The first part deals with generating a private-public key pair in the client machine. The public key is later on copied to the server and is used for authentication.
Before setting any SSH Key, let’s ensure that there aren’t any existing keys already present for this client-server combination.
Let’s run this bash script to check if the file exists(you can alternatively type this directly on the terminal)
if test -f ~/.ssh/id_*.pub; then echo "Found" else echo "Not Found" fi
If you get “Not Found”, this means that no such file exists, and we are ready to create a new key for this connection.
Otherwise, you can directly use the existing keys and skip the next step. But if you don’t want to use the old keys, you can remove the old keys and generate new ones by following the next step.
Generate a new SSH key pair for the client-server machines
The below command will generate a new 4096 bits SSH key pair with your id (can be anything identifiable!) as a comment:
ssh-keygen -t rsa -b 4096 -C "firstname.lastname@example.org"
After configuring the key location and passphrases by running this command, we will now have the new key generated for us, along with the key fingerprint.
Now, let’s check if the private-public key is actually there, using
You should get the below output:
This means that
id_rsa is your private key, and
id_rsa.pub is your public key.
NOTE: Never share your private key across machines. This is why you have a public key. So we can copy the same public key to multiple servers to
ssh to, while maintaining the added security using the private key on your local machine.
Copy the public key to the Server
Since we have our SSH key pair on our client, to be able to login to the remote server, we need to copy the public key there.
We can use
scp to copy files to our server, but there is a better alternative for
ssh keys, using
You can install
ssh-copy-id using your package manager if it is not available.
After entering the server username password, we will now be authenticated to login to the server using the public keys.
The output will be similar to this:
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/client_user/.ssh/id_rsa.pub" /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys SERVER_USER@SERVER_IP's password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'SERVER_USER@SERVER_IP'" and check to make sure that only the key(s) you wanted were added.
This means that we can use
ssh to this particular machine from our client with the extra key-based authentication!
To test it, try
sshing to the server now!
Debugging Potential Problems
But some of you may still get the password prompt to show up, along with the key-based passphrase! What is going on?
A potential reason is detailed here. It seems we may not have proper permissions on our
~/.ssh directory on the remote server. The contents of the HOME directory
~/.ssh directory, and the
~/.ssh/authorized_keys file must be writable only by us. Otherwise, it senses that other users can gain access, and that is why the password is also requested.
Let’s check the permissions of our home directory first.
Since we can only write, we don’t need to change permissions for this directory. Similarly, look at the modes and change the mode using
Let’s change permissions to these files and directories using
chmod -R ~/.ssh 700 recursively.
Now, test it to see if this works.
Debugging Potential Problems – Part 2
If you still aren’t able to get it working, this thread mentions that some of the options in the ssh config file may be disabled.
/etc/ssh/sshd_config in the server to ensure that
UsePAM options aren’t disabled.
Also, make sure that you explicitly set
PasswordAuthentication no in the config, to disable Password-based Authentication for our user.
As you can see, this was indeed the case for me! The
PubKeyAuthentication was also disabled, and hence it prompted me for the password, as the session didn’t use this as the primary mode of authentication!
I un-commented this line, and restarted
ssh to apply changes.
sudo systemctl restart ssh
Now, this made the passwordless authentication finally work for me! Hopefully, you’ve also found a solution by this time.
We’ve finally configured ssh to work without a password!
In this tutorial, we showed you how you could setup
ssh public key based authentication method, and login to a server without a password!