Hacker News Reader

The failed attempts make it harder to monitor for other attacks because of the noise in log files, network traffic, etc. and if an attacker IP is blocked early they can't try more effective attacks.

View on HN

I've set up a second obstacle by allowing access to the device from a certain range of IPs on the router. Cleaned up the log pretty good.

logins can be delayed [0] and TOTP can be used in conjunction with SSH (without google authenticator)

[0] https://unix.stackexchange.com/questions/105553/how-to-provi...

edit:

quick and dirty notes of my setup [1]

[1] https://pastebin.com/yYzSrM61

Except actual attacks don't show up in logs anyway, so it's still pointless?

The SSH daemon logs when it successfully rejects an access. A successfully rejected access is inconsequential to your security. If you are using secure passwords or pubkey authentication, it will never log a successful login by an attacker. What remains then is exploitation of the SSH server ... but the SSH server doesn't have a code path that logs "I have been exploited".

/etc/sshrc executes before a successful ssh login, you can use that to be notified before an attacker has any access to log files

... so? How does that contradict what I wrote?

Reply on news.ycombinator.com