Since SSH access is the most important entry point for administrating your server, it has become a widely used attack vector.
Basic steps to secure SSH include: disabling root access, turning password authentication off altogether (and using keys instead), and changing ports (little to do with security except minimizing common port scanners and log spam).
The next step would be a PF firewall solution with connection tracking. This solution would manage connection states, and block any IP that has too many connections. This works great, and is very easy to do with PF, but the SSH daemon is still exposed to Internet.
How about making SSH completely inaccessible from the outside? This is where spiped comes in. From the homepage:
Spiped (pronounced “ess-pipe-dee”) is a utility for creating symmetrically encrypted and authenticated pipes between socket addresses, so that one may connect to one address (e.g., a UNIX socket on localhost) and transparently have a connection established to another address (e.g., a UNIX socket on a different system). This is similar to ‘ssh -L’ functionality, but does not use SSH and requires a pre-shared symmetric key.
Great! Luckily for us, it has a high quality OpenBSD package which does all the prep work for us, so we can start by installing it:
sudo pkg_add spiped
This also installs a nice init script for us, so we can go ahead and enable it:
sudo rcctl enable spiped
And finally start it:
sudo rcctl start spiped
The init script makes sure that the key is created for us (which we will need on a local machine in a bit).
What we need to do now, is to disable
sshd from listening on public address, block port 22 and allow port 8022 (which is by default used in spiped init script).
/etc/ssh/sshd_config file and change (and uncomment) the
ListenAddress line to read
If you’re using PF rules for port blocking, make sure to pass port 8022 (and you can leave port 22 blocked), e.g:
pass in on egress proto tcp from any to any port 8022
Be sure to reload the rules to make it active:
sudo pfctl -f /etc/pf.conf
Now all we need is to copy the generated spiped key (
/etc/spiped/spiped.key) from the server to a local machine and adjust our SSH configuration, something along the following lines:
Host HOSTNAME ProxyCommand spipe -t %h:8022 -k ~/.ssh/spiped.key
You need to have
spipe/spiped installed on a local machine too, obviously. If you’ve copied the key and adjusted the names/paths, then you should be able to connect with that
ProxyCommand line in your
After you have confirmed that it’s working, we can restart
sshd on a server:
sudo rcctl restart sshd
And that’s it! Now you have completely eliminated one large attack vector, and you have one less service listening on a public interface. Your SSH connections should now appear to have come from localhost, for example:
username ttyp0 localhost Thu Nov 06 07:58 still logged in
A benefit to using Vultr is that each Vultr VPS offers a nice online VNC-type client available which we can use in-case we accidentally lock ourselves out. Experiment away!
Want to contribute?
You could earn up to $300 by adding new articles
Suggest an update
Request an article