Configuration of SSH key-based authentication
SSH (secure shell) is an encrypted protocol used to communicate with servers. When working with a Linux server, we often spend a lot of time in a terminal session connected to the server via SSH. SSH keys provide a secure and convenient way to log into a server.
The SSH server can authenticate the client using various methods. The most popular is password authentication, which is easy to use but not the most secure. While passwords are sent to the server in a secure way, they are usually not complex or long enough to resist repeated, persistent attacks. Present-day computing powers combined with automated scripts allow a brute force method to gain access to a password-protected account. SSH keys are a secure alternative to passwords.
SSH key pair is two cryptographically protected keys that can be used to authenticate a client on the SSH server. It contains a public key and a private key. The private key is stored on the client site and should be kept fully confidential, as its disclosure allows an attacker to log into servers that are configured with the associated public key – without additional authentication. An additional, highly recommended protection for the private key is to encrypt it on the local disk with a password. The public key assigned to the private key can be shared freely without any consequences. The public key is used to encrypt messages that only the private key is able to decrypt – exactly this feature is used as a method of authentication using the key pair.
The public key is sent to the server through SSH and is added to a special file in the user account to which the user will log in (file name: ~/.ssh/authorized_keys). Next time the client computer tries to authenticate using SSH keys, the server will check whether the client is in possession of the private key. If the client proves that it is the owner of the private key, a shell session will be invoked or the requested command will be executed.
How to create a key pair?
The keys can be generated using the ssh-keygen tool, which is part of the standard OpenSSH toolkit. By default, it creates an RSA key pair with a length of 3072 bits. On your local machine, generate the SSH key pair by typing the command:
The system will ask you to select a location for the keys. By default, the keys will be stored in the ~/.ssh directory in your home directory. The private key will be named id_rsa and the associated public key will be id_rsa.pub. If you wish to select a custom path for the keys, specify it at this step of configuration. If not, press ENTER to accept the default. You will then be prompted to enter a password for the private key. This is an optional, recommended password for encrypting the key file on the local drive.
You now have a public key and a private key that you can use for authentication. The next step is to place the public key on the target server.
Copying the public key to the server
There are many ways to upload a public key to a remote SSH server. The simplest is to copy the key using the ssh-copy-id command. Type in the terminal:
where: remote_host is the remote server you want to connect to, and username is the user account you want to access via SSH. This is the account to which your public SSH key will be copied.
If you see the exemplary prompt after executing the command and entering your password:
this means that the local computer does not recognize the remote server. This will occur the first time you try to connect. Select "yes" and press ENTER. The tool will scan your local account in search for the id_rsa.pub key you created earlier. When it finds it, it will ask for the password for the remote user account - you should enter it. Message:
indicates that the public key has been uploaded to the server.
If you do not have the ssh-copy-id tool at your disposal, but can log into your server account with your password, you can also upload your public key using a normal SSH connection, for example through sftp. The content of the key should then be added to the file ~/.ssh/authorized_keys.
In any case, ensure that the .ssh/authorized_keys file on the server has the access rights set properly: