ssh-keygen, copy the public key to the remote server's ~/.ssh/authorized_keys file, and ensure strict permissions on both client and server directories. This configuration allows secure authentication without manual password entry for every session.
Generating the RSA Key Pair
The foundation of passwordless authentication lies in generating a robust cryptographic key pair on your local machine. Open a terminal or command prompt and execute the ssh-keygen utility. By default, this tool creates a 3072-bit RSA key, which provides sufficient security for most use cases. You can explicitly specify the algorithm and bit length if you require stronger encryption by adding the -t rsa -b 4096 flags.
When prompted for a file location, pressing Enter accepts the default path (~/.ssh/id_rsa). It is crucial to leave the passphrase field empty if you intend for the connection to be completely automated without any user interaction. If you set a passphrase, you will still need to enter it, defeating the purpose of immediate automation. However, for high-security environments, keeping a passphrase with a key agent is recommended.
Deploying the Public Key
Once the keys are generated, the public key must be transferred to the remote server. The most efficient method is using the ssh-copy-id command. Run ssh-copy-id username@remote_host. This script automatically appends your public key to the ~/.ssh/authorized_keys file on the destination server. If this utility is unavailable, manually append the content of ~/.ssh/id_rsa.pub to the remote authorized keys file.
Ensure that the remote directory structure exists and has correct permissions. The ~/.ssh directory should typically have permissions set to 700, and the authorized_keys file should be 600. Incorrect permissions are the most common cause of SSH rejecting key-based authentication silently.
Configuring the SSH Client
After deploying the key, configure your local SSH client to use it automatically. Edit the SSH Configuration: A Generic vs. Specific Approach file located at ~/.ssh/config on Linux or macOS, or %USERPROFILE%\.ssh\config on Windows. Add a host block specifying the remote hostname, the username, and the path to your private key.
Host my-server
HostName 192.168.1.100
User sftpuser
IdentityFile ~/.ssh/id_rsa
IdentitiesOnly yes
The IdentitiesOnly yes directive forces SSH to use only the specified key, preventing delays caused by trying multiple available keys. This step ensures that your SFTP client references the correct credentials immediately upon connection.
Verifying Passwordless Access
Test the configuration by initiating an SFTP session. Use the command sftp my-server. If configured correctly, the session opens immediately without prompting for a password. You can also test via SCP or general SSH to confirm broader compatibility. If authentication fails, check the server logs at /var/log/auth.log for detailed error messages regarding key rejection.
Frequently Asked Questions
Why does SSH still ask for a password after key setup?
This usually occurs due to incorrect file permissions on the server's ~/.ssh directory or authorized_keys file. Ensure the directory is 700 and the file is 600. Additionally, verify that the SSH daemon on the server has PubkeyAuthentication enabled in its configuration.
Can I use Ed25519 keys instead of RSA?
Yes, Ed25519 keys are generally preferred over RSA for their speed and smaller size. Generate them using ssh-keygen -t ed25519 and follow the same deployment steps. Most modern SSH servers support this algorithm by default.
How do I handle multiple keys for different servers?
Use the IdentityFile directive in your ~/.ssh/config file to map specific keys to specific hosts. This prevents conflicts when you have numerous keys for various projects or clients, ensuring the correct credential is used for each connection.
What if I lose access to the key without a password?
If you cannot authenticate because the key is lost or corrupted, you will need physical or console access to the server to reset permissions or add a new public key manually. Always maintain a backup of your private keys in a secure, offline location.