Hacker News Reader

Comment by dhj | Hacker News Reader

Author here. Just wanted to get some feedback on this. It's a simple proof of concept, not meant for production code. I found several similar techniques, but none exactly the same.

Short version:

Client and server share a key.

Each can generate a TOTP based hash.

Client sends hash to server listening on UDP.

If hashes match the server opens the normally closed ssh port for a few seconds (long enough to make a connection).

Like a Google Authenticator TOTP code, the correct hash changes every T seconds so identification of the UDP port and interception of the key is only helpful for a limited (if any) amount of time.

Is this worth turning into a robust daemon? Is there a better way to deal with constant ssh probing? A module in a firewall would be ideal. Environment based config would make it fairly easy to use in provisioning for ssh admin with a smaller scan footprint.

View on HN

> Is there a better way to deal with constant ssh probing?

Turn off password auth (aka only accept pubkey auth) and use something like fail2ban to ip-block hosts with repeated failed login

Thank you. I will definitely try the key only. That should reduce probing. Presence will still be there, but if it completely deters probing that will be good enough. I looked at fail2ban, but it seemed like a losing battle with botnet scans.

Thank you for your feedback!

> it seemed like a losing battle with bonnet scans

I'm not sure I understand? fail2ban works like this:

it monitors configured log files for patterns/strings: in this case its looking for multiple failed logins within N minutes from the same IP.

If that condition is met, it adds an iptables rule to reject all connections from that IP.

If you're getting lots of random IPs, try tweaking the failures required or the timing window - you could reduce the number of failures and widen the window to better handle the situation where you might not get many hits from a given host.

If you're using key only access, you have much less to worry about: bots like that are just trying to defeat regular password auth. While its annoying unless its causing you network issues its not a concern once password auth is disabled.

> If you're getting lots of random IPs

That is the problem, it always seems to be random IPs. Thats why failtoban is a losing battle. Failtoban works per IP, but no matter how sensitive the ban rule there always seems to be an endless supply of new IPs.

I do use keys for ssh access so disabling passwords does cover most of the safety concern. I guess it is more of an annoyance than anything. It looks huge in the logs, but network usage wise it probably boils down to once every few minutes.

Reply on news.ycombinator.com