SSH Authorized Keys: A Complete Usage Guide

ByLinux Code

SSH authorized keys allow you to establish passwordless logins to remote servers using asymmetric cryptography. This enhances security and makes accessing servers more convenient. In this comprehensive guide, we‘ll cover everything you need to know about leveraging SSH authorized keys.

How Key-Based Authentication Works

SSH authorized keys rely on public-key cryptography to verify identity. This involves a public and private key pair:

  • The private key is kept secret on the client machine. It is used to digitally sign messages.

  • The public key is copied to remote servers. It is used to validate the signature made by the private key.

This allows the SSH server to authenticate a client without needing a password. As long as the client can prove ownership of the paired private key, access is granted.

The Authentication Process

Here is what happens when a client connects to an SSH server using key-based authentication:

  1. The client initiates a connection request to the SSH server.

  2. The server responds by sending a random number to the client. This is known as a challenge.

  3. The client uses its private key to sign the challenge, proving it owns the paired public key.

  4. The server checks that the challenge was signed by the associated public key stored for that user. If verification succeeds, the login is approved.

This allows convenient single-sign-on access for authorized users, without compromising security. Private keys have entropy making them impossible to guess. And they are not transmitted in the authentication process.

Generating Key Pairs

To utilize key-based authentication, you need to generate public and private SSH key files.

The ssh-keygen command handles creation and management of key pairs. Run it without arguments to start the key generation process:

ssh-keygen

You will be prompted to specify a key location and passphrase:

> Enter file in which to save the key (~/.ssh/id_rsa):
> Enter passphrase (empty for no passphrase): 
> Enter same passphrase again:

The default save location is fine for most purposes. But you may want to name keys explicitly by providing a filename, to manage multiple key pairs.

Adding a passphrase encrypts the private key when at rest. This adds another layer of security, requiring both the key file and passphrase to authenticate. But for fully passwordless logins, leave the passphrase blank.

Once complete, ssh-keygen will output the fingerprints and randomart image for the key pair:

Your identification has been saved in /home/demo/.ssh/id_rsa
Your public key has been saved in /home/demo/.ssh/id_rsa.pub
...

The public key will be stored alongside the private key file, with a .pub extension.

Inspecting Key Files

You can verify creation of the keys using ls:

ls ~/.ssh
id_rsa id_rsa.pub

And print their contents using cat:

cat ~/.ssh/id_rsa
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
NhAAAAAwEAAQAAAYEA9jPy...
-----END OPENSSH PRIVATE KEY-----

cat ~/.ssh/id_rsa.pub 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDUbBie... demo@workstation

As shown above, private keys are fully encrypted. Public keys are plain text in an SSH standard format.

Now that key files have been created, they can be used to enable passwordless SSH logins.

Configuring SSH Servers

To use key-based authentication, the SSH server needs to have the public key copied over and enabled in its configuration.

authorized_keys File

Public keys are stored in a special authorized_keys file on SSH servers. This contains one public key per line for all users permitted passwordless logins.

The location depends on the user account:

/home/demo/.ssh/authorized_keys

Keys in this file are automatically checked by the SSH daemon during authentication attempts.

Copying Over Public Keys

The ssh-copy-id utility automates transfers of public key contents to SSH servers.

Run it with the remote host identity to install your default public key:

ssh-copy-id demo@192.0.2.10

You may be prompted for the password to permit writing to the server‘s authorized_keys file.

Alternatively, keys can be installed manually by appending them to authorized_keys. But ssh-copy-id sets correct permissions which is important for security.

After adding a key, disable password authentication by setting PasswordAuthentication no in the server‘s SSH daemon configuration (usually /etc/ssh/sshd_config): 

PasswordAuthentication no

Restart the sshd service to apply this change:

sudo systemctl restart sshd

Now passwordless SSH logins should succeed using the copied private key!

Restricting Access

Granting blanket access via public keys may be undesirable in some cases though.

SSH authorized keys support restricting logins to specific commands or IP addresses by prefixing the key entry:

from="198.51.100.4" ssh-rsa ...
permitopen="192.0.2.1:80" ssh-rsa ... 
command="ls" ssh-rsa ...

This allows fine-grained control over permissions.

Using SSH Agent for Access

Having to specify the private key path each login can be tiresome. Fortunately SSH agent manages keys for you.

The ssh-agent process stores unlocked private keys in memory and provides them to SSH client processes when requested. Keys added to ssh-agent are automatically used for authentication without directly handling files.

Here is how to utilize ssh-agent:

  1. Start the ssh-agent process in the background:

    eval "$(ssh-agent -s)"

  2. Add your private key to ssh-agent:

    ssh-add ~/.ssh/id_rsa

  3. Verify the key has been added:

    ssh-add -l
2048 SHA256:GiAid... /home/demo/.ssh/id_rsa (RSA)

Now when you SSH to servers, the private key will be supplied by ssh-agent for authentication!

The -A option can also be passed to ssh to automatically add all accessible keys to the agent.

SSH Agent Forwarding

Agent forwarding permits propagating ssh-agent credentials to remote hosts.

For example, this allows you to SSH into an intermediary jump host, then connect to further machines without re-authenticating – as the jump host‘s agent credentials are forwarded.

Enable forwarding in ssh_config or pass the -A flag at client invocation:

# ~/.ssh/config
Host jumphost
  ForwardAgent yes 

ssh -A jumphost

Now agent-managed keys will be usable on any hosts accessed from the jumphost system.

Rotating Keys for Routine Security

Private SSH keys should be rotated every few months. This limits damage if a key becomes compromised somehow.

Replacing a key pair involves:

  1. Generating new key files on your system.
  2. Copying updated public keys to remote servers.
  3. Removing old public keys from authorized_keys files.

Maintenance of multiple key pairs can be eased using custom filenames during creation instead of default id_rsa values.

Version control systems also help track changes to keys and server configs over time.

Troubleshooting SSH Keys

Here are some common issues faced when utilizing SSH keys:

"Permission denied (publickey)" error: Usually means the server is rejecting your public key. Verify it was correctly installed in authorized_keys and that SSH password authentication is disabled.

"Bad owner or permissions" error: The authorized_keys file must be owned by the user account with permissions of 600 (read and write for owner only). Fix with chmod 600 authorized_keys.

"Agent admitted failure to sign" error: Indicates ssh-agent is not providing the right key for authentication. Ensure you‘ve added the correct private key path to ssh-agent and its parent process hasn‘t exited.

Login hangs after authentication: This normally means shell access has been restricted for that public key. Double check any command= or permitopen= prefixes defined in authorized_keys.

Key works for ssh but not scp/sftp: These SSH protocols have separate config files which may need to be adjusted. Disable password authentication globally by changing ChallengeResponseAuthentication no in sshd_config.

Conclusion

SSH authorized keys allow simple and secure passwordless authentication flows between clients and remote servers.

Keys provide vastly improved logins over basic passwords – but some care is needed to set them up correctly. This guide covers all the key concepts and practices.

With robust SSH key hygiene, you can conveniently access your machines without compromising safety. Restricting keys and routine rotations also limit damage from potential compromises.

Let me know if you have any other questions!

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *