Attacks on SSH not detected when publickey authorization is enforced.

Issue #102 open
Christopher Engelhard created an issue

Hi, there appear to be some issues with detecting attacks when the ssh daemon is configured to enforce public key authentication:

Working:

(0) Invalid user (both with and without public key):

sshd[12196]: Connection from <IPv4> port <Port> on <IPv4> port 22
sshd[12196]: Invalid user pi from <IPv4> port <Port>
sshd[12196]: Connection closed by invalid user pi <IPv4> port <Port> [preauth]
sshguard[695]: Attack from "<IPv4>" on service 100 with danger 10.

Not working:

(1) Existing user without valid public key:

sshd[12194]: Connection from <IPv6> port <Port> on <IPv6> port 22
sshd[12194]: Failed publickey for root from <IPv6> port <Port> ssh2: ED25519 SHA256:<Hash>
sshd[12194]: Connection closed by authenticating user root <IPv6> port <Port> [preauth]

(2) Valid user with key but wrong password or other failure authenticating the key:

sshd[12188]: Connection from <IPv6> port <Port> on <IPv6> port 22
sshd[12188]: Accepted key ED25519 SHA256:<Hash> found at /var/lib/ssh/ce/authorized_keys:2
sshd[12188]: Postponed publickey for ce from <IPv6> port <Port> ssh2 [preauth]
sshd[12188]: Connection closed by authenticating user ce <IPv6> port <Port> [preauth]
sshd[12192]: Connection from <IPv4> port <Port> on <IPv4> port 22
sshd[12192]: Received disconnect from <IPv4> port <Port>:11:  [preauth]
sshd[12192]: Disconnected from <IPv4> port <Port> [preauth]

(3) Root with valid key, but root login not permitted

sshd[12531]: Connection from <IPv4> port <Port> on <IPv4> port 22
sshd[12531]: Accepted key ED25519 SHA256:<Hash> found at /var/lib/ssh/root/authorized_keys:1
sshd[12531]: Postponed publickey for root from <IPv4> port <Port> ssh2 [preauth]
sshd[12531]: Accepted key ED25519 SHA256:<Hash> found at /var/lib/ssh/root/authorized_keys:1
sshd[12531]: ROOT LOGIN REFUSED FROM <IPv4> port <Port>
sshd[12531]: Failed publickey for root from <IPv4> port <Port> ssh2: ED25519 SHA256:<Hash>
sshd[12531]: ROOT LOGIN REFUSED FROM <IPv4> port <Port> [preauth]
sshd[12531]: Connection closed by authenticating user root <IPv4> port <Port> [preauth]

For (1), SSHGuard could match

Failed publickey for <User> from <IP> port <Port> ssh2: <KeyAlgo> <Hash>

I don't understand why (3) is not matched, because this has nothing to do with publickey auth, but in any case, one could easily match

ROOT LOGIN REFUSED FROM <IP> port <Port>

(2) is more difficult, because it would involve multi-line matching. It is also somewhat out of scope for SSHGuard, as it involves an attacker having the private keys to that account. The same applies to (3) if that problem only exists with pubkey auth. (1), however, should be matched, since a key-less attack on root is one of the most commonly occurring attacks in my logs, and it would be nice if those guys were banned, even if they have no chance of actually breaking in.

Maybe someone can test whether (3) also occurs when using password logins. I can't, because on Fedora, this test gets handed off to PAM, and with UsePAM=no nothing works properly ...

Version: sshguard-2.2.0 on Fedora 28

Comments (5)

  1. Daniel Aleksandersen

    Do you want to attempt a patch for (3), @Christopher Engelhard?

    I believe you can use commit d46780116a527394de3d9baa204586a4bea3e63d as a template for what changes needs to be done (sans defining a new service, reuse the existing SSH service). Start by copying a sample of the line you want to match into attacks.txt so you can use test-sshg-parser to quickly test your work.

    (2) requires a lot more work and should be split out into its own issue.

  2. Christopher Engelhard reporter

    Sure, I can do that.

    (2) is probably not worth tackling, tbh. If you know the account and have its key, why would you then use the server to crack the key's passcode? That would be insane.

  3. Christopher Engelhard reporter

    I created a pull request.

    I also did some more testing, and there are some caveats to these changes: (1) Following your other rules, I'm matching both ROOT LOGIN REFUSED FROM x.y.z and ROOT LOGIN REFUSED FROM x.y.z [preauth]. This can result in one attempt being counted as 2 attacks. (2) I also added matching for Failed publickey ... . However, if a user has a lot of keys in e.g. ssh-agent, each one triggers this rule, causing the user to be banned. A user really shouldn't do that, but it isn't strictly speaking an attack, so you might not want to include it. An attacker will either have stolen the correct key or have none at all, so it's not that important.

  4. Log in to comment