This article is part of a series. Part 2.
Let’s look at a simple scenario, and see how common tools in the Linux and BSD world can help us:
We want to be able to remote control a server from wherever in the world, but we really don’t want others to be able to log on to it.
In the real world, this is common enough. Understandably, though, anyone who even has a slight understanding of the risks involved will be somewhat nervous about creating a potential hole in the barricades protecting their network. With a little knowledge, we can achieve the relevant access while minimizing the risks.
In this first part, we’re configuring the Secure Shell for asymmetric key logon rather than the generally speaking less secure username/password combination we’re used to.
First of all some background: In this series of posts I’m running Ubuntu Server 16.04, the latest long term support version of this operating system at the time of writing. Similar behavior can be achieved with pretty much any Linux or BSD version out there, but the path to this result may look slightly different between operating systems.
Let’s get started:
Anyone remoting into a Unix-style server probably uses SSH since quite a while back. Now, SSH allows two major ways of presenting your credentials to the server: The common way is by typing in a username and password combination. The more secure way, is by way of asymmetric keys. I may write more on those in another post, but for now, suffice to say that they should be way harder to crack than a regular password provided you use them correctly. The main thing to remember: Your public key is truly public. Put it anywhere, it doesn’t matter. But your private key must be guarded at – well – as much cost as you see fit. The private key is what identifies you to any computer which knows your public key.
SSH key infrastructure
Let’s start by setting up a keypair. If you’re in a Unix-like system like macOS, Linux or BSD, just open up your favorite terminal and type away:
$ ssh-keygen -f mykey
You are then asked for a passphrase, which is how you buy yourself some time to change the locks, so to speak, should anyone get a hold of your private key.
This simple command has built a reasonably secure public keypair. Let’s make it work for us:
On your client computer, run the following commands:
$ mkdir .ssh $ cat mykey >> .ssh/id_rsa $ mv mykey.pub .ssh/ $ scp mykey.pub username@myserver.example.org:
On the server, ensure that SSH understands who you are when you come knocking:
$ mkdir .ssh $ cat mykey.pub >> .ssh/authorized_keys
From now on, any SSH-based communications from your client with the correct private key to a server with your public key among the authorized keys will no longer require a password – although you will need to unlock your private key with its passphrase the first time you use it in a while.
Turning off interactive logons
Next we want to disallow the use of interactive logons when connecting from the Internet. Be aware that after this is done, you won’t be able to access the server remotely with a regular username and password. Lose your private key, or forget the passphrase for it, and you’ll have to have physical access to the server to regain access to it.
Find the following lines in /etc/ssh/sshd_config and ensure they both end with a “no”:
PermitRootLogin no [...] PasswordAuthentication no
Then let’s restart sshd – this may cause you to lose your connection with the server in which case you get to try whether the settings worked:
$ sudo service sshd reload
Connecting from a computer which doesn’t have the correct private key available should now simply fail rather than presenting a login prompt.
Summary
We have made it a lot harder to trespass on our server, but we’re not done yet. Find additional parts in this series as they’re written.
Continue to Part 2.