13 ms·
If you're gonna go through all of this work -- including creating and maintaining private keys -- why not just restrict the SSH server to only permit key-based
by jlgaddis 6y ago
If you're gonna go through all of this work -- including creating and maintaining private keys -- why not just restrict the SSH server to only permit key-based authentication (optionally, signed by your CA)?
If having 22/TCP open to the world is an issue, then set up Wireguard on the host and only allow SSH connections that are coming in over the Wireguard interface.
Got a bunch of machines to deal with? Set up a jumpbox or two running OpenBSD, lock it down, give your users access to it via SSH (optionally, over a Wireguard connection) and then only allow SSH access to all of those other hosts from the jumpbox(es).
Then there's the fact that I have a whole lot more trust in the security of OpenSSH than I do some random web application!
To me, this just seems kinda pointless -- there's a bunch of other, better (IMO) ways to deal with this -- but I guess if it fits your needs ...
- MrStonedOne 6y agoStep 1: assume every service listening on your network has an auth exploit that has not been found. Step 2: deploy this. Step 3: ... Step 4: profit! The line between something like this and a locking the service behind a VPN is very narrow. They both achieve the same thing, protect high risk/value targets by not even allowing unauthorized people to talk to them at the network level.