Re:What SSH Hacking Attempts Look Like
by vxl on Saturday May 05, 2018 @07:38AM
(#17001394)
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.
[ Parent
| 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.
Re:What SSH Hacking Attempts Look Like
by seldomcomment on Saturday May 05, 2018 @07:44AM
(#17001404)
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]
Re:What SSH Hacking Attempts Look Like
by zAy0LfpBZLC8mAC on Saturday May 05, 2018 @10:23AM
(#17001918)
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
Re:What SSH Hacking Attempts Look Like
by zAy0LfpBZLC8mAC on Sunday May 06, 2018 @07:38AM
(#17006061)
... so? How does that contradict what I wrote?