Solved message in syslog: Feb 16 08:46:48 dropbear[15359]: Pubkey auth succeeded for 'admin' with key sha1!!

[GSpock]

Hi,
any idea why this message show up in syslog "Feb 16 08:46:48 dropbear[15359]: Pubkey auth succeeded for 'admin' with key sha1!! "' ?
Thx,
GS

 

[octopus]

Hi,
any idea why this message show up in syslog "Feb 16 08:46:48 dropbear[15359]: Pubkey auth succeeded for 'admin' with key sha1!! "' ?
Thx,
GS

Admin have logged in to your router.

 

[GSpock]

Admin have logged in to your router.

Oh yes, of course that was me! Sorry my OP was not clear enough. What I would like to understand is why the message regarding SHA1!! .... I have generated a pair of pub/private key with puttygen and set-up .ssh/authorized_keys and connexion works OK. Just wondering about that syslog message !

 

[eibgrad]

SHA1 is considered a weaker cryptographic protocol these days than SHA2 (which is why, for example, Google Chrome required all its certs be moved from SHA1 to SHA2 quite some time ago). All that message is telling you is that the SSH server required the use of SHA1 for that particular SSH client, when SHA2 would have been preferred. Whether it matters is up to you to decide. Either way, it works.

 

[GSpock]

SHA1 is considered a weaker cryptographic protocol these days than SHA2 (which is why, for example, Google Chrome required all its certs be moved from SHA1 to SHA2 quite some time ago). All that message is telling you is that the SSH server required the use of SHA1 for that particular SSH client, when SHA2 would have been preferred. Whether it matters is up to you to decide. Either way, it works.

Thanks. But how to enable SHA2 on server side then? In the client, I have generated a pair of keys using ed25519 parameter ...

 

[RMerlin]

The SHA hash is just used to identify the key, it does not play a part in the actual authentication.

 

[GSpock]

The SHA hash is just used to identify the key, it does not play a part in the actual authentication.

Thanks. Let me rephrase the question then: how to avoid that "sha1!!" message in the log file and make sure to use of most recent algorithm then ?

 

[BatKing]

Thanks. Let me rephrase the question then: how to avoid that "sha1!!" message in the log file and make sure to use of most recent algorithm then ?

How did u generate the key pair? check https://docs.github.com/en/github/a...-a-new-ssh-key-and-adding-it-to-the-ssh-agent

depends your local keygen version the parameter you gave, the key pair maybe generated with SHA1 or SHA2 or even other more recent/advance/secure ways. so you may just need to regenerate your key pair with correct parameters.

 

[RMerlin]

Thanks. Let me rephrase the question then: how to avoid that "sha1!!" message in the log file and make sure to use of most recent algorithm then ?

The hash has nothing to do with the algorithm used for the encryption. As I said, it`s just an identifier, so you can trace back which key has been used to connect.

 

[GSpock]

How did u generate the key pair? check https://docs.github.com/en/github/a...-a-new-ssh-key-and-adding-it-to-the-ssh-agent

depends your local keygen version the parameter you gave, the key pair maybe generated with SHA1 or SHA2 or even other more recent/advance/secure ways. so you may just need to regenerate your key pair with correct parameters.

Thanks for the link. I generated the keys with the Putty tool provided from putty.org. When choosing ed25519, there is no other parameter to specify. I did generated the key pair in W10 then copied the pub key in authorized_keys on the router.

 

[GSpock]

The hash has nothing to do with the algorithm used for the encryption. As I said, it`s just an identifier, so you can trace back which key has been used to connect.

Thanks, I finally understood that. The question was how to get rid of this message then ... if possible at all.

 

[Jack Yaz]

Thanks, I finally understood that. The question was how to get rid of this message then ... if possible at all.

Why do you want to? It's a security message to show when someone authenticates against dropbear... The sort of thing you want to keep a log/audit of if you care about network security at all.

 

[GSpock]

Why do you want to? It's a security message to show when someone authenticates against dropbear... The sort of thing you want to keep a log/audit of if you care about network security at all.

When I see such messages in syslog, I am just wondering if I should do something about it. In this case, I was questionning the sha1 because @eibgrad mentioned it is a weaker algorithm. Sorry that I do not have all your competencies, I am just a user learning & trying to make the best to keep my environnement as safe as possible.
Anyway thanks to all for spending time in answering me ;-)

I am still wondering where this "sha1 pub key" comes from, since I have generated a key pair with ed25519 .. but I guess I can live without an answer

 

[Jack Yaz]

Sorry for my blunt tone, I just don't understand the want to hide messages. SHA1 is a weak algorithm, yes, but in this context it is being used to identify the key used. It is not being used by the router for any authentication purposes. SHA1 in this context is being used to produce an ID number for the key.

 

[GSpock]

Sorry for my blunt tone, I just don't understand the want to hide messages. SHA1 is a weak algorithm, yes, but in this context it is being used to identify the key used. It is not being used by the router for any authentication purposes. SHA1 in this context is being used to produce an ID number for the key.

no problem, I can understand it might be sometimes difficult for people with high technical skills to explain things to beginners .... and btw you have already helped me a lot in some others threads

 

[Jack Yaz]

If you want to check how the router generates the hash, you can run the below over SSH:

echo -n "yourkeyvalue" | openssl base64 -d -A | openssl sha1

replace yourkeyvalue with the key contents from Authorized Keys, i.e. the long value between "ssh-rsa" and "user@hostname"

EDIT: to format it in a similar way to syslog, use

echo -n "yourkeyvalue" | openssl base64 -d -A | openssl sha1 | cut -f2 -d" " | sed 's/../&:/g;s/:$//'

 

[rreiner]

Given all of the above -- and ensuring it is clearly understood that this message does NOT indicate that SHA1 is being used for authentication, but rather just used to generate a key fingerprint for logging purposes -- one question hasn't been asked or answered, namely:

Why is the router using SHA1 (rather than SHA2 or SHA3) as a means of generating the key fingerprint for the log? There is really no reason to prefer SHA1 for this (or for anything, in 2021). Switching to SHA2 is as easy as replacing "sha1" in the openssl command with "sha256"...

 

[Jack Yaz]

Given all of the above -- and ensuring it is clearly understood that this message does NOT indicate that SHA1 is being used for authentication, but rather just used to generate a key fingerprint for logging purposes -- one question hasn't been asked or answered, namely:

Why is the router using SHA1 (rather than SHA2 or SHA3) as a means of generating the key fingerprint for the log? There is really no reason to prefer SHA1 for this (or for anything, in 2021). Switching to SHA2 is as easy as replacing "sha1" in the openssl command with "sha256"...

my response question is, why does it matter? it works as-is, why change something for the sake of changing it?

 

[rreiner]

my response question is, why does it matter? it works as-is, why change something for the sake of changing it?

You might ask, why log a key hash at all?

If we're logging the hash, it is so the key can be reliably identified -- perhaps in a later forensic context, i.e. after an intrusion or abuse incident.

SHA1 can no longer be considered a reliable hash. So it fails to achieve the only objective that justifies the log entry.

Forgive me if my 25 years of large-enterprise cybersecurity leadership are skewing my view here. But it seems to me that if the security properties of something can be significantly improved, for all users, with 2 seconds of effort (edit one word, in one command line, in one script), then that effort is justified.