You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Lyor Goldstein (Jira)" <ji...@apache.org> on 2020/02/27 14:42:00 UTC
[jira] [Comment Edited] (SSHD-969) compatibility problem with
cisco-2.0 ssh on ios-xr
[ 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-v01@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-sha256@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-v01@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519
> debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
> debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
> debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
> debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
> debug2: compression ctos: none,zlib@openssh.com,zlib
> debug2: compression stoc: none,zlib@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-gcm@openssh.com,aes256-gcm@openssh.com
> debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@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-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org