In this article, I’ll show you how you can login to SSH (Secure Shell) more secure, without not using a password, by using SSH-keys.
SSH allows several types of services to connect securely (encrypted and such) to be used, but the most common one is Shell (command line) access.
It is mostly used as a much more secure replacement for Telnet, rlogin, rsh etc.
Quite often, when starting to use SSH, most users will use a username and password to get SSH access, but this not the most secure method.
More secure, and easier to use, is by using so called SSH-keys, and in this article I’ll try to explain as simple as possible how this works and how to get started with this.
What is SSH?
Before explaining how SSH Login without a password works, a quick look at what SSH really is and when you’d be using it.
Personally, I use SSH most often to access the Shell or Terminal on a remote computer, for example my web server, my QNAP NAS, or my Raspberry Pi running LibreElec (KODI).
Often to execute one or the other command line statements, typically modifying something or installing/removing something on the remote machine.
See it as a Shell/Terminal/Command Prompt window, directly running on the remote machine.
On most platforms (macOS, Linux, Windows) it will look like you’re working on the local machine, but instead of running it all local, things are executed on the remote machine.
Note: For macOS and Linux users, the command one executes will typically be very similar to what you’ve been used to in a Shell or in Terminal.
Windows users on the other hand will see that commands are a little different, since most of these remote machines run one or the other Linux variant.
SSH Login Without a Password – How does this work?
Folks starting with SSH, especially first few times, will just use a username and password.
This could be fine for that one time you need access, but it is not the most secure method as passwords are often easy to guess, or relatively easy to break with a brute force attack.
There is an alternative though, the use of SSH-keys, which not only makes the password very difficult to guess, but also significantly longer.
The entire matter behind this is something to discuss I’m sure, but in this article I’ll keep it simple.
Public Key vs Private Key
When looking at encryption, you quite often see mention of “Public Key” and “Private Key” – something we’re about to use for SSH.
So what are those and how do they work?
A Private Key can be used to decrypt a message.
Because of that, you should keep a private key private, and never share it with anyone else.
The Public Key can only be used to encrypt a message, and can be shared with others without a problem.
It can never be used to decrypt a message.
Note: When using such keys, we typically generate them with OpenSSL tools, more about that later.
The basic idea is this:
We create two keys;
one to “encode” and one to “decode” a message;
A “Private Key” to decode (encrypt) a message,
A “Public Key” to encode” (decrypt) a message.
A simplified example:
Let’s say Max asks Bram to send him a secret message, but Max wants to be sure that no one else can read the message.
To keep the message secret he send Bram a request for such a secret message and includes his “Public Key” with that.
The Public key allows Bram to encrypt the secret message.
After encryption, not even Bram can decrypt it. So now Bram sends the encrypted message to Max.
Max has the “Private key”, allowing him, and only him, to decrypt the secret message.
Simple example of Private vs Public Keys
SSH Login using SSH-keys explained
Now how does this work when applied to our SSH connection?
The procedure consists of 2 steps.
Step 1 – Get us some keys
Obviously we first will need to actually have a Public and a Private key. So we need to generate those first.
Note that the same key can be used for several different SSH servers. You could also generate a set of keys per server, but that comes with a few extra challenges.
Step 2 – Give the server our Public Key – We only need to do this once.
The second step is to make sure the server has our Public Key and for the given server this needs to be done only once.
This way the server “knows” which Username and Public Key combinations could potentially be allowed SSH access.
In this step, we need to connect to our SSH server, with our usual username and password login, and give the server our “Public Key”.
As of this point, the server “knows” that this key is OK to use for this particular user.
The key is store in a special file, usually store in the home directory of that user (
Step 3 – For each SSH Login – Give the server our Username and our Public Key
Each time we want to login with SSH, the following steps are done.
As a user you will not have a clue this is happening, as it’s fully automated.
- Send the server we want access to, our username and our public key (usually called “id_rsa.pub“).
- The server will now look and see if it knows this key (stored in “authorized_keys“).
- If found, the server will now create, encrypt, and send a passphrase (each time a unique secret message).
- Our computer will now be able to decode the passphrase and send the decoded message back to the server.
- The server will compare the received passphrase and if it matches the original secret message, we get access.
In a similar diagram as used before, this would look something like this:
SSH Login process with Private and Public Keys
SSH Login Without a Password – In Practice
Now that we know how this works in the background, time to set this all to work.
Here we will use a simplified and straight forward method, since there are plenty of more complex approaches possible.
For example protecting your keys with a passphrase and using other encryption methods (I’m using RSA here).
Step 1 – Generate out Public and Private Key (one time only)
Obviously we will need a key … so let’s generate one.
This works for macOS, Linux and Windows.
After this step we will have 2 files: The Private Key (id_rsa) and the Public Key (id_rsa.pub).
Both files can be found in your user home directory (Linux/macOS:
~/.ssh/ and Windows:
It appears that the
.ssh directory under macOS and Linux already exists or automatically is being created.
If you get an error message, please verify that this directory actually exists.
I have added a few parameters that may or may not be needed, the short version would be:
The extra parameters make sure that we know where the file goes (-f) and that we do not wish to use a passphrase (-P).
ssh-keygen -f ~/.ssh/id_rsa -t rsa -P ""
Please note: Under macOS and Linux, a filename or directory name starting with a period (like .ssh), is invisible under normal circumstances.
Windows users need to create the .ssh directory first …
I have tested this only with Windows 10, and it seemed OpenSSL tools were installed by default.
Unfortunately, you will have to create a directory first, where to store your SSH-keys.
In Command Prompt:
Obviously replace “<username>” with your username (do a
dir C:\Users\ to see what your may be).
ssh-keygen -f C:\Users\<username>\.ssh\id_rsa -t rsa -P ""
Please note: replace “<username>” with your username or user directory name (check with:
The output will look something like this:
Generating public/private rsa key pair.
Your identification has been saved in \Users\Hans\.ssh\id_rsa.
Your public key has been saved in \Users\Hans\.ssh\id_rsa.pub.
The key fingerprint is:
The key's randomart image is:
| .=* .|
| . .+ . . +.|
| . o +o o . + +|
| . . * o + = ..|
| . = .S = + +. |
| + + * o + .|
| . o . . o . .|
|+ E . . . . |
Step 2 – Give the Server you Public Key (one time only)
Warning: if you generate new keys, you will have to give the new Public Key to the server again, as it will be different than a previously generated key!
There are 2 ways to do this, the old school method and the method that uses ssh-copy-id.
Unfortunately, ssh-copy-id does not seem to exist under Windows (I did find one at GitHub though).
Replace “<username>” with the login username you’d use for this server, and replace “<server-ip-address>” with the IP address of your server.
The option “-o StrictHostKeyChecking=No” only prevents that SSH will automatically add the server to it’s list of “known hosts” – so you won’t be bother with that question.
You will have to enter your password though.
macOS and Linux – The easy way with ssh-copy-id
ssh-copy-id -i ~/.ssh/id_rsa.pub <username>@<server-ip-address> -o StrictHostKeyChecking=No
ssh-copy-id -i ~/.ssh/id_rsa.pub email@example.com -o StrictHostKeyChecking=N
macOS and Linux – The harder way by using cat
cat ~/.ssh/id_rsa.pub | ssh <username>@<server-ip-address> 'mkdir -p .ssh; cat >> .ssh/authorized_keys'
cat ~/.ssh/id_rsa.pub | ssh firstname.lastname@example.org 'mkdir -p .ssh; cat >> .ssh/authorized_keys'
Windows – The long way, since ssh-copy-id does not exist
Replace “<userdirectory>” with the proper directory name (check with:
type C:\Users\<userdirectory>\.ssh\id_rsa.pub | ssh <username>@<server-ip-address> -o StrictHostKeyChecking=No "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys || exit 1;"
type C:\Users\Hans\.ssh\id_rsa.pub | ssh email@example.com -o StrictHostKeyChecking=No "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys || exit 1;"
Step 3 – Test if SSH Login without a Password actually works
The easiest way to test this is by simply starting and SSH session like so (works the same way for macOS, Linux and Windows) – this is how you start your SSH connection in the future;