[
https://issues.apache.org/jira/browse/SSHD-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17526812#comment-17526812
]
Thomas Wolf commented on SSHD-1264:
-----------------------------------
I think the problem is that Apache MINA sshd uses one single list of signature
algorithms for both host key signatures in KEX (ssh config
{{{}HostKeyAlgorithms{}}}) and for public key signatures in pubkey auth (ssh
config {{{}PubkeyAcceptedAlgorithms{}}}). But if the server announces via KEX
extension {{server-sig-algs}} that it supports the SHA2 RSA signatures, that
list gets re-ordered.
I see the server sending a packet type 7 (SSH_MSG_EXT_INFO), but the log
doesn't show the contents. I would expect it to contain exactly such a
{{server-sig-algs}} record. The Apache MINA sshd client log would show it if so.
Apache MINA sshd will need to use different lists of algorithms for this.
Re-ordering {{PubkeyAcceptedAlgorithms}} is fine, but {{HostKeyAlgorithms}}
should be unaffected by {{{}server-sig-algs{}}}.
Perhaps the {{HostKeyAlgorithms}} list used for a session could be affected if
the server sends a host key update/rotation KEX extension? That would need to
be handled in SSHD-1255.
> different host key algorithm used on rekey than used for the initial
> connection
> -------------------------------------------------------------------------------
>
> Key: SSHD-1264
> URL: https://issues.apache.org/jira/browse/SSHD-1264
> Project: MINA SSHD
> Issue Type: Bug
> Affects Versions: 2.8.0
> Reporter: James Nord
> Priority: Major
> Attachments: sshd_log.txt
>
>
> when using mina as an ssh client to connect to an open ssh server the host
> key algorithm that is negotiated on the initial connection can have a
> different algorithm than the one used in a rekey.
> This causes an issue as connections can be terminated if the initial host key
> type is in the known hosts, (say ecdsa) but the subsequent on (rsa) is not.
> once connected the same host key algorithm should be used in any subsequent
> re-key events.
> (see log attached from SSHD)
> Note: this is easyish to see by setting opensshd server config `RekeyLimit
> default 10` which will cause a rekey after 10 seconds on a data event.
> e.g.
> {noformat}
> debug1: kex: host key algorithm: ecdsa-sha2-nistp256 [preauth]
> debug1: kex: host key algorithm: rsa-sha2-512 {noformat}
> shows the flop from an agreed exchange of {{ecdsa-sha2-nistp256}} to
> {{rsa-sha2-512}}
> the end result is that if the rsa key is not known then the connection is
> killed
> {{o.a.s.c.k.KnownHostsServerKeyVerifier#acceptModifiedServerKey:
> acceptModifiedServerKey(ClientSessionImpl[jenkins@localhost/127.0.0.1:22])
> mismatched keys presented by localhost/127.0.0.1:22 for entry=localhost
> ecdsa-sha2-nistp256
> AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNZDNvKiE7VBVWziZUlICIpIEMhVy0nL3y2hHYRQGMOaWWPajP86ucgwgeXAWmJOxr4bqMtC9tF0vC1W2l8wYPM=:
>
> expected=ecdsa-sha2-nistp256-SHA256:x5TMcz4T6ggPxxSbx6gfTzk8US6CLuxgmqXNXedu+6w,
> actual=ssh-rsa-SHA256:W60YQsFuMkHf0flHrJFR31lvyYm7Y6BkEMkqHUTOpZQ}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
