christoph ender's

blog

sunday the 17th of november, 2024

wireguard-before-ssh

It's time. After several incidents – terrapin, openssh/xz and the signalhandler/race-condition – all within the timespan of a single year, I've started rolling out servers which have their ssh port bound to a wireguard interface. Which means that without authenticating and connecting via wireguard first, the ssh port is not accessible from the public internet.

The goal is two have two separate security systems that ensure that even if one fails completely and unexpectedly, there's still no need to act at once or to immediately close down any of these services. Which also means that the ssh service is still subject to the same security measures as before (no passwords, only keys, etc).

In practice, there are some inconveniences: When a machine has some kind of automatic setup procedures – like ansible scripts – available which also use ssh, one has to work around that fact that the server's IP “changes” during setup once the system has the ssh port being moved behind wireguard. I've been tackling this using two separate host entries in the ssh config and the ansible inventory: For one, there's an alias my-node-setup pointing to the machine's public ip, for the other, a my-node alias poiting to the server's wireguard peer address, where the remote ssh port is bound.

As an additional benefit, all the ssh auth spam from the myriad number of ssh bot bruteforce attempts vanishes. That also means it now makes sense to actually filter/trigger for failed ssh attempts in the logs.