SSH has evolved to be the standard protocol for managing servers (and in fact lots of other machines) remotely. While ssh allows password based login, relying on passwords for authentication on servers is generally considered a security risk. If you ever opened the syslog on a machine with an ssh server running and exposed to the internet you may have noticed lots of (hopefully) failed logins, typically between one per second and one every 20 seconds. (The value is generally much higher on systems that allow password based login), this is because of a huge amount of bad actors and hacked servers scanning the internet for vulnerable systems they can log into and add to their botnet. In fact guessing weak ssh (and telnet) passwords was the major way how Mirai, the worlds strongest botnet was created. Even though you can (and should) set strong passwords on all accounts you use only completly disabling password based authentication can give you the peace of mind that there is no forgotten user account with a weak passwords that a bot guessed and took over your server. This might even happen because lots of server software (i.E. webservers) creates user accounts to limit its own rights on the system. And there is absolutely no need to use password based authentication as there is login method that is way more secure and even more comfortable than having to rember a password for every server you manage.
That is the reason why all our VPS offers come with ssh password based authentication disabled. This article will guide you through the process of getting started with keybased authentication.
In difference to password based login, where you have a password that is known both to you and your server, ssh keys always come as a pair of two: A privatekey, think of it as you would of a regular, physical key. Who ever has it can open every door (or login to every machine in our case) you were granted access to so you should keep it secret and a publickey. Despite also being called a key it is easier to think of it as the lock your key fits. As the name suggests it is considered public so having your publickey (often referred to as “pubkey”) gives somebody no power to log in somehwere in your name. It only allows other people to install your lock in their door, meaning to grant you access to machines they manage.
This is also where key based authentication beats passwords in terms of comfort. While using the same password on multiple locations is a terrible idea because one location getting breached is enough to reveal your password and grant the power to log in to other locations in your name, using the same ssh key to authenticate on multiple machines is considered safe to do as somebody who breaches one server can only get your pubkey from it and that is, as discussed before, considered public anyway.
So let’s get started setting up key based authentication for you:
Generating your key
This step needs to be done only once your workstation, when you have the key you can reuse it on every server you manage.
The process is nearly identical on all major operating systems. When different OSes require different steps, they are explained here.
The first step is to open a terminal. On MacOS and Linux your regular terminal is fine but on windows you need to open powershell, not CMD (just launch the program called powershell and you are good)
Then you can generate your actual keypair by typing
ssh-keygen -t ed25519
We are creating a modern ed25519, if you need to log in to very old and/or minimalist devices (i.E. embedded devices like Routers and Access Points) you may want to create an RSA key instead by running
ssh-keygen -b 4096
You will get asked where your key should be stored, choosing the default given location (by hitting enter without typing a location) is generally a good choice as ssh will look there for a key when connecting to a server.
After that you will be prompted for a password. While you can leave the field empty to create the key without a password it is highly recommended to use a strong and unique password. This prevents somebody who manages to steal your key file from your machine to log into your servers as long as they don’t know the password. This is especially important on devices that are not encrypted or get used by multiple people.
After your key is generated, your will be returned to the command prompt. Get your pubkey by typing
cat .ssh/id_ed25519.pub on Linux and MacOS or
cat .\.ssh\id_ed25519.pub on Windows. The line printed back to you on the terminal is your pubkey (or your lock). If you chose a custom storage location while generating, you need to specify that instead of the given part and append .pub to it. If you chose RSA over ed25519 you need to replace ed25519 with rsa an the above command.
If you want to get one of our VPS offers this is what you need to paste into the textbox asking for your publickey to be able to log in via ssh right from the start.
Congratulations, you have successfully set up secure authentication for ssh. Let’s see how to use it.
Logging in with you key
As soon as your key is installed on the remote server you can connect to the server just as you would have done without a key by running
If you get asked for a password that is the password you set while generating your key, not the user password you have on the server. If it still asks for a password for the remote user on the server that means that keybased authentication failed. This can either be because you tried to log into the wrong username/host or because ssh failed to find your private key. This will happen if you stored your key somewhere else. In that case you need to append
-i path/to/your/key/you/chose to the ssh command.
If everything goes the way it should, you will be dropped into the shell of the remote server. Congratulations to your first very secure ssh connection.
If that read was not long enough for you, here are some ideas how you can enhance your new ssh key setup even further:
You can use an ssh-agent. This Software conveniently keeps your key unlocked and ready to use regardeless where it is stored, some password managers such as KeePassXC allow you to store the key inside the encrypted password vault of the software and automatically add it to the agent as soon as you unlock your password file.
If you have really high security needs you might consider investing money into an USB security device. This is a pendrive-like devices your key can be written onto (or even generated on) but not extracted from. The cryptographic process involved in ssh gets shifted to that device so even if a very sophisticated attacker manages to freeze and extract your RAMs content while you use ssh they can’t get hold of the key.