Return to Answer

For background...

There's a great answer on the topic over on Security Stack Exchange which links through to openssh's notes on deprecating ssh-rsa.

It seems the problem is that the original ssh-rsa algorithm (described in RFC 4253) relied on SHA-1 which is now largely defunct for cryptography:

Since 2005, SHA-1 has not been considered secure against well-funded opponents; as of 2010 many organizations have recommended its replacement. NIST formally deprecated use of SHA-1 in 2011 and disallowed its use for digital signatures in 2013. As of 2020, chosen-prefix attacks against SHA-1 are practical.

But it's the signature algorithm that used SHA-1 not the key itself.

With that in mind...

If Cisco 4k allow higher PK than ssh-rsa, why it does not work with default ssh settings?

What's changed is that openssh no-longer allows ssh-rsa by default. The change you made lets your client accept ssh-rsa. So the router still accepts it (even if it moans). But there's no strict hierarchy to the algorithms, just some "better" than others. So allowing "higher" algorithms doesn't mean that router and client share the same "higher" algorithms.

Another possible reason is that while your client and router both shared "better" algorithms, they weren't compatible with a raw RSA key. Eg: they allowed ssh certificates, but you have a key and no certificate. In that case you could use default settings but not your existing key with default settings.

Is there any connection between key type "ssh-rsa" and allowed PK algorithms

From what I can find on the topic, yes. They algorithms can be limited to a single cipher but don't typically care so much about key length. Keys are basically just [some] very large numbers. It doesn't matter how large they are, but the algorithm needs to know what to do with them.

Is there any way (I have tried ssh debug and sshd debug) to understand clearly what PK algorithms are supported on server and client like we do with ciphers?

Although it's a bit cryptic this is available with openssh level 2 debug (-vv). You'll see debug2: KEX algorithms: ... and debug2: host key algorithms: .... You should also see which algorithm was selected. There is also a level three debug (-vvv) if you want to delve deeper.

For background...

There's a great answer on the topic over on Security Stack Exchange which links through to openssh's notes on deprecating ssh-rsa.

It seems the problem is that the original ssh-rsa algorithm (described in RFC 4253) relied on SHA-1 which is now largely defunct for cryptography:

Since 2005, SHA-1 has not been considered secure against well-funded opponents; as of 2010 many organizations have recommended its replacement. NIST formally deprecated use of SHA-1 in 2011 and disallowed its use for digital signatures in 2013. As of 2020, chosen-prefix attacks against SHA-1 are practical.

But it's the signature algorithm that used SHA-1 not the key itself.

With that in mind...

If Cisco 4k allow higher PK than ssh-rsa, why it does not work with default ssh settings?

What's changed is that openssh no-longer allows ssh-rsa by default. The change you made lets your client accept ssh-rsa. So the router still accepts it (even if it moans). But there's no strict hierarchy to the algorithms, just some "better" than others. So allowing "higher" algorithms doesn't mean that router and client share the same "higher" algorithms.

Another possible reason is that while your client and router both shared "better" algorithms, they weren't compatible with a raw RSA key. Eg: they allowed ssh certificates, but you have a key and no certificate. In that case you could use default settings but not your existing key with default settings.

Is there any connection between key type "ssh-rsa" and allowed PK algorithms

From what I can find on the topic, yes. They algorithms can be limited to a single cipher but don't typically care so much about key length. Keys are basically just [some] very large numbers. It doesn't matter how large they are, but the algorithm needs to know what to do with them.

Is there any way (I have tried ssh debug and sshd debug) to understand clearly what PK algorithms are supported on server and client like we do with ciphers?

Although it's a bit cryptic this is available with openssh level 2 debug (-vv). You'll see debug2: KEX algorithms: ... and debug2: host key algorithms: .... You should also see which algorithm was selected. There is also a level three debug (-vvv) if you want to delve deeper.

For background...

There's a great answer on the topic over on Security Stack Exchange which links through to openssh's notes on deprecating ssh-rsa.

It seems the problem is that the original ssh-rsa algorithm (described in RFC 4253) relied on SHA-1 which is now largely defunct for cryptography:

Since 2005, SHA-1 has not been considered secure against well-funded opponents; as of 2010 many organizations have recommended its replacement. NIST formally deprecated use of SHA-1 in 2011 and disallowed its use for digital signatures in 2013. As of 2020, chosen-prefix attacks against SHA-1 are practical.

But it's the signature algorithm that used SHA-1 not the key itself.

With that in mind...

Is there any connection between key type "ssh-rsa" and allowed PK algorithms

From what I can find on the topic, yes. They algorithms can be limited to a single cipher but don't typically care so much about key length. Keys are basically just [some] very large numbers. It doesn't matter how large they are, but the algorithm needs to know what to do with them.

Is there any way (I have tried ssh debug and sshd debug) to understand clearly what PK algorithms are supported on server and client like we do with ciphers?

Although it's a bit cryptic this is available with openssh level 2 debug (-vv). You'll see debug2: KEX algorithms: ... and debug2: host key algorithms: .... You should also see which algorithm was selected. There is also a level three debug (-vvv) if you want to delve deeper.

For background...

There's a great answer on the topic over on Security Stack Exchange which links through to openssh's notes on deprecating ssh-rsa.

It seems the problem is that the original ssh-rsa algorithm (described in RFC 4253) relied on SHA-1 which is now largely defunct for cryptography:

Since 2005, SHA-1 has not been considered secure against well-funded opponents; as of 2010 many organizations have recommended its replacement. NIST formally deprecated use of SHA-1 in 2011 and disallowed its use for digital signatures in 2013. As of 2020, chosen-prefix attacks against SHA-1 are practical.

But it's the signature algorithm that used SHA-1 not the key itself.

With that in mind...

If Cisco 4k allow higher PK than ssh-rsa, why it does not work with default ssh settings?

What's changed is that openssh no-longer allows ssh-rsa by default. The change you made lets your client accept ssh-rsa. So the router still accepts it (even if it moans). But there's no strict hierarchy to the algorithms, just some "better" than others. So allowing "higher" algorithms doesn't mean that router and client share the same "higher" algorithms.

Another possible reason is that while your client and router both shared "better" algorithms, they weren't compatible with a raw RSA key. Eg: they allowed ssh certificates, but you have a key and no certificate. In that case you could use default settings but not your existing key with default settings.

Is there any connection between key type "ssh-rsa" and allowed PK algorithms

From what I can find on the topic, yes. They algorithms can be limited to a single cipher but don't typically care so much about key length. Keys are basically just [some] very large numbers. It doesn't matter how large they are, but the algorithm needs to know what to do with them.

Is there any way (I have tried ssh debug and sshd debug) to understand clearly what PK algorithms are supported on server and client like we do with ciphers?

Although it's a bit cryptic this is available with openssh level 2 debug (-vv). You'll see debug2: KEX algorithms: ... and debug2: host key algorithms: .... You should also see which algorithm was selected. There is also a level three debug (-vvv) if you want to delve deeper.

There's a great answer on the topic over on Security Stack Exchange which links through to openssh's notes on deprecating ssh-rsa.

It seems the problem is that the original ssh-rsa algorithm (described in RFC 4253) relied on SHA-1 which is now largely defunct for cryptography:

Since 2005, SHA-1 has not been considered secure against well-funded opponents; as of 2010 many organizations have recommended its replacement. NIST formally deprecated use of SHA-1 in 2011 and disallowed its use for digital signatures in 2013. As of 2020, chosen-prefix attacks against SHA-1 are practical.

But it's the signature algorithm that used SHA-1 not the key itself.

Is there any connection between key type "ssh-rsa" and allowed PK algorithms

From what I can find on the topic, yes. They algorithms can be limited to a single cipher but don't typically care so much about key length. Keys are basically just [some] very large numbers. It doesn't matter how large they are, but the algorithm needs to know what to do with them.

Is there any way (I have tried ssh debug and sshd debug) to understand clearly what PK algorithms are supported on server and client like we do with ciphers?

Although it's a bit cryptic this is available with openssh level 2 debug (-vv). You'll see debug2: KEX algorithms: ... and debug2: host key algorithms: .... You should also see which algorithm was selected. There is also a level three debug (-vvv) if you want to delve deeper.

For background...

There's a great answer on the topic over on Security Stack Exchange which links through to openssh's notes on deprecating ssh-rsa.

It seems the problem is that the original ssh-rsa algorithm (described in RFC 4253) relied on SHA-1 which is now largely defunct for cryptography:

Since 2005, SHA-1 has not been considered secure against well-funded opponents; as of 2010 many organizations have recommended its replacement. NIST formally deprecated use of SHA-1 in 2011 and disallowed its use for digital signatures in 2013. As of 2020, chosen-prefix attacks against SHA-1 are practical.

But it's the signature algorithm that used SHA-1 not the key itself.

With that in mind...

Is there any connection between key type "ssh-rsa" and allowed PK algorithms

From what I can find on the topic, yes. They algorithms can be limited to a single cipher but don't typically care so much about key length. Keys are basically just [some] very large numbers. It doesn't matter how large they are, but the algorithm needs to know what to do with them.

Is there any way (I have tried ssh debug and sshd debug) to understand clearly what PK algorithms are supported on server and client like we do with ciphers?

Although it's a bit cryptic this is available with openssh level 2 debug (-vv). You'll see debug2: KEX algorithms: ... and debug2: host key algorithms: .... You should also see which algorithm was selected. There is also a level three debug (-vvv) if you want to delve deeper.