2

I have a remote server into which I login via ssh. On this server I have setup a Wireguard VPN to which my host connects. The ssh server (ssh daemon) listens on a private IP interface (the server's Wireguard interface). It seems to me that the only way to get into my remote server (even try to) would be to have my Wireguard connection file (including the shared password and the private password) + have my private SSH key + (I think that's the easy part if the attacker were to get this far) know the private interface's IP.

Oh, and another detail, I only let the private VPN IP addresses through the firewall to the SSH port.

So I was wondering - is this method foolproof or might I be missing something? Seems to me like even if I were to allow empty passwords, without my Wireguard connection to the server the attacker still couldn't get into my remote server.

P.S. Foolproof, as in, if my host's Wireguard conf and SSH private key doesn't get compromised (at which point only a password on the SSH key would stall the attacker, I think)

Thanks!

Glorfindel
  • 2,235
  • 6
  • 18
  • 30
Kibartas
  • 123
  • 1
  • 5

1 Answers1

5

It is foolproof in the sense that someone can only gain access if they have your credentials, or if there is a vulnerability in Wireguard. But in the same sense, exposing an SSH server is foolproof. The most attractive aspect of this setup is probably that Wireguard exposes a smaller attack surface than SSH.

Whether this is a good architecture depends on your exact goals and on your threat model. Whereas having to log in into through two separate systems (Wireguard and SSH) and reducing the attack surface can increase security, it could also decrease security aspects such as availability: there are now two critical systems instead of one, and misconfiguring any would deny you access. For the threat that credentials on your client system might be compromised, you've correctly analysed that adding Wireguard does not add security.

That an attacker would need to know a particular IP address should not be assumed to add any security (see: security by obscurity, Kerckhoffs's principle).

amon
  • 1,068
  • 7
  • 9