Remote connections to a server via Secure Shell (SSH) can be authenticated in two ways. The traditional and default method is to use password authentication. The second approach is key-based authentication, which is based on a private-public key pair.
Key-based authentication provides two primary benefits:
- Helps mitigate brute-force password attacks against SSH
- Prevents administrators from being required to manually type passwords in automated processes such as scripts or Ansible
Passwordless key-based authentication is often the assumed configuration on modern Linux systems.
The key pair
For key-based authentication, a matched pair of cryptographic key files is generated. The pair consists of a private key and a public key that uniquely identify the user. The private key usually has a permission of 600 and is kept on the local server. The public key is copied to the remote system where the user intends to log in. This public key is stored in the ~/.ssh/authorized_keys or ~/.ssh/authorized_keys2 file of the authenticating user. For example, if you log into a remote server with the user sadmin, the public key is added to the /home/sadmin/.ssh/authorized_keys file.
Create the key pair
The ssh-keygen command generates the private and public key pair. By default, the command saves these keys to the user's ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub files. The id_rsa is the private key, and id_rsa.pub is the public key. The OpenSSH suite also contains an ssh-copy-id command, which you can use to distribute the public keys to other systems.
To generate the keys, enter the following command:
[server]$ sudo ssh-keygen
Note: Press Enter for all questions because this is an interactive command.
By default, all files are stored in the /home/sysadmin/.ssh/ directory. You can enter a new file name when running the ssh-keygen command. The command also offers the option to add a passphrase to unlock the key file.
[ Get this free download: Advanced Linux commands cheat sheet. ]
Share the public key
To share the public key with other systems the sadmin user will access, use:
[server]$ sudo ssh-copy-id remoteuser@remoteserver
Enter the user's password. The public key is shared with the remote server, and the user can log in without a password. There is also the ssh-agent command, which you can use to store private keys used for public key authentication. This is normally useful when a passphrase protects keys.
To add a private key stored in /home/sadmin/sshkeys/id_rsa to ssh-agent, use these commands:
[server]$ sudo eval $(ssh-agent)
[server]$ sudo ssh-add
Enter the passphrase, which is then stored in memory until the agent is stopped. In this case, you don't need to enter a passphrase when using SSH to access a remote server.
Wrap up
Passwordless connection is very useful, especially in automated transfers and scripting. It's a fairly standard configuration on many Linux systems because it reduces the burden on manual SSH authentication and allows for more simplified automation solutions.
About the author
I work as Unix/Linux Administrator with a passion for high availability systems and clusters. I am a student of performance and optimization of systems and DevOps. I have passion for anything IT related and most importantly automation, high availability, and security.
More like this
File encryption and decryption made easy with GPG
Deploy Confidential Computing on AWS Nitro Enclaves with Red Hat Enterprise Linux
What Is Product Security? | Compiler
Technically Speaking | Security for the AI supply chain
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Virtualization
The future of enterprise virtualization for your workloads on-premise or across clouds