[ https://issues.apache.org/jira/browse/SSHD-969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17046686#comment-17046686 ]
Lyor Goldstein edited comment on SSHD-969 at 2/27/20 2:41 PM: -------------------------------------------------------------- {quote} I noticed that Mina SSH sends msg 50 (SSH_MSG_USERAUTH_REQUEST) before key exchange completes {quote} I cannot figure out what scenario can lead to this - authentication messages are exchanged +after+ keys have been exchanged - never over insecure channel. We have such checks in code: {code:java} @Override public Boolean doAuth(Buffer buffer, boolean init) throws Exception { ValidateUtils.checkTrue(init, "Instance not initialized"); ServerSession session = getServerSession(); if (!UserAuthMethodFactory.isSecureAuthenticationTransport(session)) { if (log.isDebugEnabled()) { log.debug("doAuth({}) session is not secure", session); } return false; } {code} Note that even by your own log, the {{SSH_MSG_USERAUTH_REQUEST}} is not sent - it is +enqueued +to be sent when KEX completed: {quote} 2020-02-25 20:12:15.532Z [pool-171-thread-1] DEBUG o.a.s.c.session.ClientSessionImpl:808 - writePacket(ClientSessionImpl[cisco@/10.90.10.193:22])[SSH_MSG_USERAUTH_REQUEST] Start flagging packets as pending until key exchange is done {quote} It may be the case that the server has some kind of race condition and has not yet updated its internal state that KEX is completed when {{SSH_MSG_USERAUTH_REQUEST}} arrives. Anyway, you have not mentioned what MINA SSHD version you are using. Please try the latest one. Another thing to notice is that some servers behave in a special way and expect flows that are not always standard. To that effect, try and activate the "delayed KEX" option in our code (see [this link|https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md#configuring-the-protocol-exchange-phase]). This option delays KEX from the client side until the server has sent its identification first. It might fix this issue entirely, but perhaps it may introduce enough of a delay to overcome the suspected race condition in the server. was (Author: lgoldstein): {quote} I noticed that Mina SSH sends msg 50 (SSH_MSG_USERAUTH_REQUEST) before key exchange completes {quote} I cannot figure out what scenario can lead to this - authentication messages are exchanged +after+ keys have been exchanged - never over insecure channel. We have such checks in code: {code:java} @Override public Boolean doAuth(Buffer buffer, boolean init) throws Exception { ValidateUtils.checkTrue(init, "Instance not initialized"); ServerSession session = getServerSession(); if (!UserAuthMethodFactory.isSecureAuthenticationTransport(session)) { if (log.isDebugEnabled()) { log.debug("doAuth({}) session is not secure", session); } return false; } {code} It may be the case that the server has some kind of race condition and has not yet updated its internal state that KEX is completed when {{SSH_MSG_USERAUTH_REQUEST}} arrives. Anyway, you have not mentioned what MINA SSHD version you are using. Please try the latest one. Another thing to notice is that some servers behave in a special way and expect flows that are not always standard. To that effect, try and activate the "delayed KEX" option in our code (see [this link|https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md#configuring-the-protocol-exchange-phase]). This option delays KEX from the client side until the server has sent its identification first. It might fix this issue entirely, but perhaps it may introduce enough of a delay to overcome the suspected race condition in the server. > compatibility problem with cisco-2.0 ssh on ios-xr > --------------------------------------------------- > > Key: SSHD-969 > URL: https://issues.apache.org/jira/browse/SSHD-969 > Project: MINA SSHD > Issue Type: Bug > Reporter: Yuefeng > Priority: Major > > When mina ssh library is used to connect with a Cisco IOS-XR device, the > connection is consistently reset by IOS-XR, here's mina log > > > {code:java} > 2020-02-25 20:12:15.531Z [sshd-SshClient[468ca10d]-nio2-thread-1] DEBUG > o.a.s.c.session.ClientSessionImpl:271 - > initializeProxyConnector(ClientSessionImpl[null@/10.90.10.193:22]) no proxy > to initialize > 2020-02-25 20:12:15.531Z [pool-171-thread-1] INFO > com.forwardnetworks.client.a.f.a.d:20 - Connected to 'xrv9k' > 2020-02-25 20:12:15.531Z [pool-171-thread-1] DEBUG > o.a.s.c.session.ClientSessionImpl:204 - > addPasswordIdentity(ClientSessionImpl[*****@/10.90.10.193:22]) SHA256:****** > 2020-02-25 20:12:15.532Z [pool-171-thread-1] INFO > com.forwardnetworks.client.a.f.a.d:28 - Authenticating client session to > xrv9k for up to 10000 seconds. > 2020-02-25 20:12:15.532Z [pool-171-thread-1] DEBUG > o.a.s.c.s.ClientUserAuthService:162 - > auth(ClientSessionImpl[cisco@/10.90.10.193:22])[ssh-connection] send > SSH_MSG_USERAUTH_REQUEST for 'none' > 2020-02-25 20:12:15.532Z [pool-171-thread-1] DEBUG > o.a.s.c.session.ClientSessionImpl:808 - > writePacket(ClientSessionImpl[cisco@/10.90.10.193:22])[SSH_MSG_USERAUTH_REQUEST] > Start flagging packets as pending until key exchange is done > 2020-02-25 20:12:15.533Z [sshd-SshClient[468ca10d]-nio2-thread-5] DEBUG > o.a.s.c.session.ClientSessionImpl:167 - > signalAuthFailure(ClientSessionImpl[cisco@/10.90.10.193:22]) > type=IOException, signalled=true: Connection reset by peer > {code} > > Ssh (openssh) successfully connects to the save device > {code:java} > fwd-collector@collector:/usr/local/fwd/logs$ ssh -vvv ****@10.90.10.193 > OpenSSH_7.2p2 Ubuntu-4ubuntu2.7, OpenSSL 1.0.2g 1 Mar 2016 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: /etc/ssh/ssh_config line 19: Applying options for * > debug2: resolving "10.90.10.193" port 22 > debug2: ssh_connect_direct: needpriv 0 > debug1: Connecting to 10.90.10.193 [10.90.10.193] port 22. > debug1: Connection established. > debug1: key_load_public: No such file or directory > debug1: identity file /home/fwd-collector/.ssh/id_rsa type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /home/fwd-collector/.ssh/id_rsa-cert type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /home/fwd-collector/.ssh/id_dsa type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /home/fwd-collector/.ssh/id_dsa-cert type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /home/fwd-collector/.ssh/id_ecdsa type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /home/fwd-collector/.ssh/id_ecdsa-cert type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /home/fwd-collector/.ssh/id_ed25519 type -1 > debug1: key_load_public: No such file or directory > debug1: identity file /home/fwd-collector/.ssh/id_ed25519-cert type -1 > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.7 > debug1: Remote protocol version 2.0, remote software version Cisco-2.0 > debug1: no match: Cisco-2.0 > debug2: fd 3 setting O_NONBLOCK > debug1: Authenticating to 10.90.10.193:22 as 'admin' > debug3: hostkeys_foreach: reading file "/home/fwd-collector/.ssh/known_hosts" > debug3: record_hostkey: found key type RSA in file > /home/fwd-collector/.ssh/known_hosts:28 > debug3: load_hostkeys: loaded 1 keys from 10.90.10.193 > debug3: order_hostkeyalgs: prefer hostkeyalgs: > ssh-rsa-cert-...@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa > debug3: send packet: type 20 > debug1: SSH2_MSG_KEXINIT sent > debug3: receive packet: type 20 > debug1: SSH2_MSG_KEXINIT received > debug2: local client KEXINIT proposal > debug2: KEX algorithms: > curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c > debug2: host key algorithms: > ssh-rsa-cert-...@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-ed25519-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519 > debug2: ciphers ctos: > chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc > debug2: ciphers stoc: > chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc > debug2: MACs ctos: > umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 > debug2: MACs stoc: > umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 > debug2: compression ctos: none,z...@openssh.com,zlib > debug2: compression stoc: none,z...@openssh.com,zlib > debug2: languages ctos: > debug2: languages stoc: > debug2: first_kex_follows 0 > debug2: reserved 0 > debug2: peer server KEXINIT proposal > debug2: KEX algorithms: > ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group14-sha1 > debug2: host key algorithms: ssh-rsa > debug2: ciphers ctos: > aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com > debug2: ciphers stoc: > aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com > debug2: MACs ctos: hmac-sha2-512,hmac-sha2-256,hmac-sha1 > debug2: MACs stoc: hmac-sha2-512,hmac-sha2-256,hmac-sha1 > debug2: compression ctos: none > debug2: compression stoc: none > debug2: languages ctos: > debug2: languages stoc: > debug2: first_kex_follows 0 > debug2: reserved 0 > debug1: kex: algorithm: ecdh-sha2-nistp256 > debug1: kex: host key algorithm: ssh-rsa > debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 > compression: none > debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 > compression: none > debug3: send packet: type 30 > debug1: sending SSH2_MSG_KEX_ECDH_INIT > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY > debug3: receive packet: type 31 > debug1: Server host key: ssh-rsa > SHA256:lja7613FGu9mq/VD7ArGz4zFA4xsRqxAIPuls7yr8GU > debug3: hostkeys_foreach: reading file "/home/fwd-collector/.ssh/known_hosts" > debug3: record_hostkey: found key type RSA in file > /home/fwd-collector/.ssh/known_hosts:28 > debug3: load_hostkeys: loaded 1 keys from 10.90.10.193 > debug1: Host '10.90.10.193' is known and matches the RSA host key. > debug1: Found key in /home/fwd-collector/.ssh/known_hosts:28 > debug3: send packet: type 21 > debug2: set_newkeys: mode 1 > debug1: rekey after 4294967296 blocks > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug3: receive packet: type 21 > debug1: SSH2_MSG_NEWKEYS received > debug2: set_newkeys: mode 0 > debug1: rekey after 4294967296 blocks > debug2: key: /home/fwd-collector/.ssh/id_rsa ((nil)) > debug2: key: /home/fwd-collector/.ssh/id_dsa ((nil)) > debug2: key: /home/fwd-collector/.ssh/id_ecdsa ((nil)) > debug2: key: /home/fwd-collector/.ssh/id_ed25519 ((nil)) > debug3: send packet: type 5 > debug3: receive packet: type 6 > debug2: service_accept: ssh-userauth > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug3: send packet: type 50 > debug3: receive packet: type 51 > debug1: Authentications that can continue: keyboard-interactive,password > debug3: start over, passed a different list keyboard-interactive,password > debug3: preferred > gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password > debug3: authmethod_lookup keyboard-interactive > debug3: remaining preferred: password > debug3: authmethod_is_enabled keyboard-interactive > debug1: Next authentication method: keyboard-interactive > debug2: userauth_kbdint > debug3: send packet: type 50 > debug2: we sent a keyboard-interactive packet, wait for reply > debug3: receive packet: type 60 > debug2: input_userauth_info_req > debug2: input_userauth_info_req: num_prompts 1 > Password: > {code} > I noticed that Mina SSH sends msg 50 (SSH_MSG_USERAUTH_REQUEST) before key > exchange completes (IOS-XR sends reset immediately after). > With openssh, msg 50 is sent after key exchange and msg (5, 6). > -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org