This page looks best with JavaScript enabled

SSH Login Without Password

 ·  ☕ 2 min read

2020-10-29 Update

The security of RSA keys have been called into question and we now recommend using elliptical keys wherever possible (which should be almost everywhere). You can generate an ed25519 elliptical keypair as follows:

1
ssh-keygen -a 100 -t ed25519 -C "your comment goes here"

All other info should still remain current.

Background

I have found several guides to setting up a SSH login without a password (aka passwordless login, PKI login, etc. for ssh) but none seemed to combine all aspects I use. The following steps show how to create a public/private key pair on a local computer and upload the public key to a remote computer to allow SSH passwordless login via PKI.

Details

1
2
ssh-keygen -t rsa -b 4096   #4096 is a good/safe key size.
ssh-copy-id -i ~/.ssh/id_rsa.pub remote_user@remote_server   #change remote_user and remote_server.

An explanation of the above and more detail:

  • Generate a public/private key on your local machine (this will be used to log you in remotely - but still ensure it is secure): $ ssh-keygen -t rsa -b 4096
    • note: select the defaults, when it asks for a passphrase leave it empty unless you want to be challenged to use your key
  • Use ssh-copy-id to securely copy the public key created above to the remote host you want to log into without a password: $ ssh-copy-id -i ~/.ssh/id_rsa.pub remote_user@remote_server
    • note: change remote_user with your specific remote user name and remote_server with your specific remote server name/ip address
    • if you do not have ssh-copy-id you can use the following to deploy the public key: $ cat .ssh/id_rsa.pub | ssh remote_user@remote_server 'cat >> .ssh/authorized_keys'

Upon issuing the above command (ssh-copy-id -i ... or cat .ssh/id_rsa.pub...) you will be prompted (one last time) for remote_user’s password on remote_server, supply it and you should be set!

Notes

  • I recommend using strong encryption hence the 4096 bits for the key, you can obviously use 2048 or 1024 as you see fit. my rule of thumb is if you have a high number of connects to a source you may be able to justify a lower key size; however, I’ve never been able to justify lower security due to a key size length taking too long to process on connect.
Share on

drad
WRITTEN BY
drad
Sr. Consultant