It seems that when I have more than one key held by the agent, any authentication that

I have ended up taking a similar approach as in <a class="issue-link js-issue-link" da

See this thread for the real problem: <a href="https://fogbugz.bitvise.com/default.asp

Same issue on: local host: Ubuntu 17.10 paramiko 2.4.

Another impact of <a class="issue-link js-issue-link" data-error-text="Failed to load

Authentication fails with more than one key in agent,about paramiko/paramiko

Comments (11)

zougloub commented on June 17, 2024 2

A workaround when using gpg-agent is to edit sshcontrol to put the desired key on top.
It would be nice to be able to select the desired key from the agent, but even openssh doesn't seem to be able to do that (no config entry for that, similar to IdentityFile).

from paramiko.

commented on June 17, 2024 1

Ran into this - Paramiko sending one MSG_SERVICE_REQUEST before every MSG_AUTH_REQUEST, because "authenticating" is literally implemented as "the thing you do in response to seeing a MSG_SERVICE_ACCEPT" 😩 - at work this week. It was causing hard to diagnose issues with the golang ssh server code embedded in the Teleport project (symptom is that if you don't auth correctly on try number 1, you get an EOF from the server and everything melts.)

I dug into git history and it's not clear why Robey wrote it this way originally, but it's essentially unchanged from the original commits in 2003. Happy 20th birthday, Paramiko?

As one would expect there are probably dozens of reports and various attempts at fixing this, some are linked above, but re-linking here from my search results: #165, #478, #519, #894, #1121.

The core reason why this is a problem for some target servers but has gone unfixed for so long is simply that the vast majority of targets are OpenSSH, and OpenSSH's MSG_SERVICE_REQUEST handler is idempotent and doesn't care if a client sends one before every MSG_AUTH_REQUEST like Paramiko does.

The RFC, also, does not specify the expected behavior between the transport layer (service request) and the auth layer (auth request/s). Which leads to other server implementations, like golang's, being stricter about what they accept at which stages of the conversation.

Interestingly, while OpenSSH server is idempotent here, the OpenSSH client does only send the single service request (as many of these tickets note).

The linked PRs all tackle this differently, some very hacky, some less hacky. I am partway through rewriting the high level auth flow per #387, but this is quite a bit lower in the stack, and I'm not excited to completely rewrite Transport and AuthHandler if I can avoid it. Which leads to "just how hacky to be today?".

I'll likely synthesize the various approaches taken in others' patches, but I'm also contemplating making any solution opt-in, to limit the usual issue of one bug's fix being another bug's genesis. This is also the approach taken with the higher level auth rewrite: it's new code, opt in for now. Whether this is doable for Transport/AuthHandler, is unclear...

from paramiko.

bitprophet commented on June 17, 2024 1

I have ended up taking a similar approach as in #387, to wit:

New (sub)classes for Transport and AuthHandler, the former indicating the latter automatically
There's already (added in the last few years IIRC) a SSHClient.connect kwarg for specifying an alternate Transport class, so that's the opt-in mechanism for this (and these classes will be released in 3.2 as experimental and opt-in, eventually becoming the primary code path in 4.x).
The new AuthHandler subclass trims out the MSG_SERVICE_ACCEPT handler, and the new Transport adds one
The new Transport tracks an internal attribute re: whether it has seen SERVICE_ACCEPT, and refuses to go very far into any auth_xxx method until it sees that said attribute has been twiddled by aforementioned new handler
The new AuthHandler now actually sends the MSG_USERAUTH_REQUEST in its auth_xxx methods, and then immediately hangs out and waits for the reply (so that, as before, this all appears to be blocking to the average user)

I've tested this enough that I can eg send 2 bad passwords and 1 good one, and observe only 1x MSG_SERVICE_REQUEST gets sent, instead of 3x.

Next week will see it polished and further tested and released to my internal users for alpha testing; it will let us remove the code I gave them this past week to use an earlier alpha for #387 which allows user code to configure the auth flow, in this case to strip out agent keys they know will not succeed. Now, with this, they can drop that code already and not have golang targets blow up after auth failures.

from paramiko.

gellule commented on June 17, 2024

See this thread for the real problem: https://fogbugz.bitvise.com/default.asp?WinSSHD.1.16148.4
Sending multiple service-request for userauth.

from paramiko.

jansegre commented on June 17, 2024

I am experiencing a very similar, if not the same, issue.

I got to this while using fabric and tracked it down to paramiko. My use case is connecting to a Mikrotik Router (which uses ROSSSH ssh server), while using publickey authentication.

These are the 3 most relevant logs, I have hidden the real IPs though.

Successful authentication with openssh client:

OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /Users/jan/.ssh/config
debug1: /Users/jan/.ssh/config line 210: Applying options for my-router
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to X.Y.Z.W [X.Y.Z.W] port 22.
debug1: Connection established.
debug1: identity file /Users/jan/.ssh/id_rsa type 1
debug1: identity file /Users/jan/.ssh/id_rsa-cert type -1
debug1: identity file /Users/jan/.ssh/id_dsa type 2
debug1: identity file /Users/jan/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version ROSSSH
debug1: no match: ROSSSH
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],ssh-dss,[email protected],[email protected],ssh-rsa
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-dss
debug2: kex_parse_kexinit: aes192-cbc,aes128-cbc,aes256-cbc,blowfish-cbc,3des-cbc,none
debug2: kex_parse_kexinit: aes192-cbc,aes128-cbc,aes256-cbc,blowfish-cbc,3des-cbc,none
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 123/256
debug2: bits set: 512/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: DSA 91:6c:5e:09:bf:fc:aa:ac:c9:05:81:e0:3c:69:c0:15
debug1: Host '[X.Y.Z.W]:22' is known and matches the DSA host key.
debug1: Found key in /Users/jan/.ssh/known_hosts:273
debug2: bits set: 522/1024
debug1: ssh_dss_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/jan/.ssh/id_rsa (0x7f9f724162a0),
debug2: key: /Users/jan/.ssh/id_dsa (0x7f9f72700790),
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/jan/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering DSA public key: /Users/jan/.ssh/id_dsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-dss blen 434
debug2: input_userauth_pk_ok: fp 92:ee:7b:f6:eb:a4:99:00:28:69:43:e3:8b:1b:35:7a
debug1: Authentication succeeded (publickey).
Authenticated to X.Y.Z.W ([X.Y.Z.W]:22).
debug2: fd 6 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug1: Requesting authentication agent forwarding.
debug2: channel 0: request [email protected] confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug1: Sending environment.
debug1: Sending env LC_CTYPE = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending command: put test
debug2: channel 0: request exec confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 2621440 rmax 262144
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd close
debug2: channel 0: output open -> drain
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
#0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)

debug1: fd 2 clearing O_NONBLOCK
Transferred: sent 3600, received 1928 bytes, in 0.0 seconds
Bytes per second: sent 86132.7, received 46128.9
debug1: Exit status 0

Notice how openssh tries the rsa key first, it fails but it is able to continue trying.

Successful authentication with paramiko, when using allow_agent=False:

>>> ssh.connect('my-router', username='jan', allow_agent=False)
DEBUG:paramiko.transport:starting thread (client mode): 0xaf23c90L
INFO:paramiko.transport:Connected (version 2.0, client ROSSSH)
DEBUG:paramiko.transport:kex algos:[u'diffie-hellman-group-exchange-sha256', u'diffie-hellman-group-exchange-sha1', u'diffie-hellman-group14-sha1', u'diffie-hellman-group1-sha1'] server key:[u'ssh-dss'] client encrypt:[u'aes192-cbc', u'aes128-cbc', u'aes256-cbc', u'blowfish-cbc', u'3des-cbc', u'none'] server encrypt:[u'aes192-cbc', u'aes128-cbc', u'aes256-cbc', u'blowfish-cbc', u'3des-cbc', u'none'] client mac:[u'hmac-sha1', u'hmac-md5'] server mac:[u'hmac-sha1', u'hmac-md5'] client compress:[u'none'] server compress:[u'none'] client lang:[u''] server lang:[u''] kex follows?False
DEBUG:paramiko.transport:Ciphers agreed: local=aes128-cbc, remote=aes128-cbc
DEBUG:paramiko.transport:using kex diffie-hellman-group14-sha1; server key type ssh-dss; cipher: local aes128-cbc, remote aes128-cbc; mac: local hmac-sha1, remote hmac-sha1; compression: local none, remote none
DEBUG:paramiko.transport:Switch to new keys ...
DEBUG:paramiko.transport:Trying discovered key 92ee7bf6eba49900286943e38b1b357a in /Users/jan/.ssh/id_dsa
DEBUG:paramiko.transport:userauth is OK
INFO:paramiko.transport:Authentication (publickey) successful!

Failed authentication with paramiko, when allow_agent defaults to True:

>>> ssh.connect('my-router', username='jan')
DEBUG:paramiko.transport:starting thread (client mode): 0xaf1d110L
INFO:paramiko.transport:Connected (version 2.0, client ROSSSH)
DEBUG:paramiko.transport:kex algos:[u'diffie-hellman-group-exchange-sha256', u'diffie-hellman-group-exchange-sha1', u'diffie-hellman-group14-sha1', u'diffie-hellman-group1-sha1'] server key:[u'ssh-dss'] client encrypt:[u'aes192-cbc', u'aes128-cbc', u'aes256-cbc', u'blowfish-cbc', u'3des-cbc', u'none'] server encrypt:[u'aes192-cbc', u'aes128-cbc', u'aes256-cbc', u'blowfish-cbc', u'3des-cbc', u'none'] client mac:[u'hmac-sha1', u'hmac-md5'] server mac:[u'hmac-sha1', u'hmac-md5'] client compress:[u'none'] server compress:[u'none'] client lang:[u''] server lang:[u''] kex follows?False
DEBUG:paramiko.transport:Ciphers agreed: local=aes128-cbc, remote=aes128-cbc
DEBUG:paramiko.transport:using kex diffie-hellman-group14-sha1; server key type ssh-dss; cipher: local aes128-cbc, remote aes128-cbc; mac: local hmac-sha1, remote hmac-sha1; compression: local none, remote none
DEBUG:paramiko.transport:Switch to new keys ...
DEBUG:paramiko.transport:Trying SSH agent key 4b47d4ff4ceb80c91c80d1d8e1f05d7d
DEBUG:paramiko.transport:userauth is OK
INFO:paramiko.transport:Authentication (publickey) failed.
DEBUG:paramiko.transport:Trying SSH agent key 92ee7bf6eba49900286943e38b1b357a
INFO:paramiko.transport:Disconnect (code 2): 
DEBUG:paramiko.transport:Trying discovered key 92ee7bf6eba49900286943e38b1b357a in /Users/jan/.ssh/id_dsa
---------------------------------------------------------------------------
SSHException                              Traceback (most recent call last)
<ipython-input-19-b9a070eaf75e> in <module>()
----> 1 ssh.connect('nw-office', port=11235, username='jan')

/Users/jan/Projects/hammock/.virtualenv/lib/python2.7/site-packages/paramiko-1.15.1-py2.7.egg/paramiko/client.pyc in connect(self, hostname, port, username, password, pkey, key_filename, timeout, allow_agent, look_for_keys, compress, sock, gss_auth, gss_kex, gss_deleg_creds, gss_host, banner_timeout)
305             gss_host = hostname
306         self._auth(username, password, pkey, key_filenames, allow_agent,
--> 307                    look_for_keys, gss_auth, gss_kex, gss_deleg_creds, gss_host)
308 
309     def close(self):

/Users/jan/Projects/hammock/.virtualenv/lib/python2.7/site-packages/paramiko-1.15.1-py2.7.egg/paramiko/client.pyc in _auth(self, username, password, pkey, key_filenames, allow_agent, look_for_keys, gss_auth, gss_kex, gss_deleg_creds, gss_host)
517         # if we got an auth-failed exception earlier, re-raise it
518         if saved_exception is not None:
--> 519             raise saved_exception
520         raise SSHException('No authentication methods available')
521 

SSHException: No existing session

The exceptions happens because of the disconnection, I had to go through the code to learn that.

The disconnect code, is for protocol error, the log on the original issue report seems to help a bit more and state that.

For my use case it's complicated to make a workaround since I'm not directly using paramiko, I'm using fabric. And also the connection part has to work for other hosts, some of which will use rsa keys and other dss keys.

Can anyone give any hint on how to proceed? Or any way I can help fix this bug? I'm not familiar with the SSH protocol specification.

from paramiko.

corbie commented on June 17, 2024

I can confirm this issue also affects SSH version 1.99, client Cisco-1.25 (ASA OS 9.6.2). Paramiko sends a new SSH_MSG_SERVICE_REQUEST for each key loaded from an ssh-agent, but the remote server expects the conversation to start with a single SSH_MSG_SERVICE_REQUEST followed by SSH_MSG_USERAUTH_REQUEST message for each key. RFC 4252 Section 5 seems to support this:

An authentication request MAY result in a further exchange of
messages. All such messages depend on the authentication 'method
name' used, and the client MAY at any time continue with a new
SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST
abandon the previous authentication attempt and continue with the new
one.

Abbreviated logs follow:

DEB [20161129-00:08:20.538] thr=2   paramiko.transport: starting thread (client mode): 0x5e4fc90L
DEB [20161129-00:08:20.538] thr=2   paramiko.transport: Local version/idstring: SSH-2.0-paramiko_2.0.2
DEB [20161129-00:08:20.553] thr=2   paramiko.transport: Remote version/idstring: SSH-1.99-Cisco-1.25
INF [20161129-00:08:20.553] thr=2   paramiko.transport: Connected (version 1.99, client Cisco-1.25)
DEB [20161129-00:08:20.554] thr=2   paramiko.transport: Write packet <kexinit>, length 631
...
DEB [20161129-00:08:20.560] thr=2   paramiko.transport: Got payload (172 bytes, 7 padding)
DEB [20161129-00:08:20.560] thr=2   paramiko.transport: Read packet <kexinit>, length 164
DEB [20161129-00:08:20.560] thr=2   paramiko.transport: kex algos:[u'diffie-hellman-group14-sha1'] server key:[u'ssh-rsa'] client encrypt:[u'aes256-cbc', u'aes256-ctr'] server      encrypt:[u'aes256-cbc', u'aes256-ctr'] client mac:[u'hmac-sha1'] server mac:[u'hmac-sha1'] client compress:[u'none'] server compress:[u'none'] client lang:[u''] server lang:[u'']   kex follows?False
DEB [20161129-00:08:20.560] thr=2   paramiko.transport: Kex agreed: diffie-hellman-group14-sha1
DEB [20161129-00:08:20.561] thr=2   paramiko.transport: Cipher agreed: aes256-ctr
DEB [20161129-00:08:20.561] thr=2   paramiko.transport: MAC agreed: hmac-sha1
DEB [20161129-00:08:20.561] thr=2   paramiko.transport: Compression agreed: none
DEB [20161129-00:08:20.576] thr=2   paramiko.transport: Write packet <kex30>, length 261
...
DEB [20161129-00:08:20.716] thr=2   paramiko.transport: Got payload (1340 bytes, 8 padding)
DEB [20161129-00:08:20.716] thr=2   paramiko.transport: Read packet <kex31>, length 1331
DEB [20161129-00:08:20.736] thr=2   paramiko.transport: Write packet <newkeys>, length 1
DEB [20161129-00:08:20.737] thr=2   paramiko.transport: OUT: 00 00 00 0C 0A 15 00 00 00 00 00 00 00 00 00 00    ................
DEB [20161129-00:08:20.737] thr=2   paramiko.transport: kex engine KexGroup14 specified hash_algo <built-in function openssl_sha1>
DEB [20161129-00:08:20.738] thr=2   paramiko.transport: IN: 00 00 00 0C 0A 15 00 00                            ........
DEB [20161129-00:08:20.738] thr=2   paramiko.transport: IN: 00 00 00 00 00 00 00 00                            ........
DEB [20161129-00:08:20.738] thr=2   paramiko.transport: Got payload (12 bytes, 10 padding)
DEB [20161129-00:08:20.738] thr=2   paramiko.transport: Read packet <newkeys>, length 1
DEB [20161129-00:08:20.738] thr=2   paramiko.transport: Switch to new keys ...
DEB [20161129-00:08:20.747] thr=1   paramiko.transport: Trying SSH agent key REMOVED
DEB [20161129-00:08:20.748] thr=1   paramiko.transport: Write packet <service-request>, length 17
DEB [20161129-00:08:20.748] thr=1   paramiko.transport: OUT: 00 00 00 1C 0A 05 00 00 00 0C 73 73 68 2D 75 73    ..........ssh-us
DEB [20161129-00:08:20.748] thr=1   paramiko.transport: OUT: 65 72 61 75 74 68 00 00 00 00 00 00 00 00 00 00    erauth..........
DEB [20161129-00:08:20.768] thr=2   paramiko.transport: IN: 00 00 00 1C 0A 06 00 00 00 0C 73 73 68 2D 75 73    ..........ssh-us
DEB [20161129-00:08:20.768] thr=2   paramiko.transport: IN: 65 72 61 75 74 68 A1 B2 33 3B 86 66 DA 53 0E D4    erauth..3;.f.S..
DEB [20161129-00:08:20.768] thr=2   paramiko.transport: Got payload (28 bytes, 10 padding)
DEB [20161129-00:08:20.768] thr=2   paramiko.transport: Read packet <service-accept>, length 17
DEB [20161129-00:08:20.768] thr=2   paramiko.transport: userauth is OK
DEB [20161129-00:08:20.781] thr=2   paramiko.transport: Write packet <userauth-request>, length 1125
DEB [20161129-00:08:20.783] thr=2   paramiko.transport: OUT: 00 00 04 6C 06 32 00 00 00 07 63 6F 6E 73 6F 6C    ...l.2....consol
DEB [20161129-00:08:20.783] thr=2   paramiko.transport: OUT: 65 00 00 00 0E 73 73 68 2D 63 6F 6E 6E 65 63 74    e....ssh-connect
DEB [20161129-00:08:20.783] thr=2   paramiko.transport: OUT: 69 6F 6E 00 00 00 09 70 75 62 6C 69 63 6B 65 79    ion....publickey
DEB [20161129-00:08:20.783] thr=2   paramiko.transport: OUT: 01 00 00 00 07 73 73 68 2D 72 73 61 00 00 02 17    .....ssh-rsa....
DEB [20161129-00:08:20.783] thr=2   paramiko.transport: OUT: 00 00 00 07 73 73 68 2D 72 73 61 00 00 00 03 01    ....ssh-rsa.....
...
DEB [20161129-00:08:20.804] thr=2   paramiko.transport: Got payload (44 bytes, 19 padding)
DEB [20161129-00:08:20.804] thr=2   paramiko.transport: Read packet <userauth-failure>, length 24
INF [20161129-00:08:20.805] thr=2   paramiko.transport: Authentication (publickey) failed.
DEB [20161129-00:08:20.816] thr=1   paramiko.transport: Trying SSH agent key REMOVED
DEB [20161129-00:08:20.816] thr=1   paramiko.transport: Write packet <service-request>, length 17
DEB [20161129-00:08:20.816] thr=1   paramiko.transport: OUT: 00 00 00 1C 0A 05 00 00 00 0C 73 73 68 2D 75 73    ..........ssh-us
DEB [20161129-00:08:20.816] thr=1   paramiko.transport: OUT: 65 72 61 75 74 68 00 00 00 00 00 00 00 00 00 00    erauth..........
DEB [20161129-00:08:20.832] thr=2   paramiko.transport: IN: 00 00 00 4C 10 01 00 00 00 02 00 00 00 2E 50 72    ...L..........Pr
DEB [20161129-00:08:20.832] thr=2   paramiko.transport: IN: 6F 74 6F 63 6F 6C 20 65 72 72 6F 72 3A 20 65 78    otocol error: ex
DEB [20161129-00:08:20.832] thr=2   paramiko.transport: IN: 70 65 63 74 65 64 20 70 61 63 6B 65 74 20 74 79    pected packet ty
DEB [20161129-00:08:20.832] thr=2   paramiko.transport: IN: 70 65 20 35 30 2C 20 67 6F 74 20 35 00 00 00 00    pe 50, got 5....
DEB [20161129-00:08:20.832] thr=2   paramiko.transport: IN: 62 B6 7A 03 86 C7 D8 3C 6E EE 1E 4A 5D AE AE 6A    b.z....<n..J]..j
DEB [20161129-00:08:20.832] thr=2   paramiko.transport: Got payload (76 bytes, 16 padding)
DEB [20161129-00:08:20.832] thr=2   paramiko.transport: Read packet <disconnect>, length 59
INF [20161129-00:08:20.832] thr=2   paramiko.transport: Disconnect (code 2): Protocol error: expected packet type 50, got 5

This is specifically affecting the asa_command module in Ansible 2.2 when using an encrypted private key with ssh-agent on OS X 10.12, Python 2.7.12. The workaround is to set key order manually, adding the required key to ssh-agent first; this ensures that the first publickey authentication is successful.

The code in #478 corrects this issue.

from paramiko.

rarylson commented on June 17, 2024

Hi,

I confirm this problem in my Mikrotik RouterOS 6 routers.

I've tested and reviewed the code in PR 478 (#478). It seems good and it fixed all my problems with Mikrotik routers.

from paramiko.

jean-christophe-manciot commented on June 17, 2024

Same issue on:

local host: Ubuntu 17.10
paramiko 2.4.0 (used by ansible 2.4.2.0)
gpg-agent 2.2.3-1
remote host: ASAv 9.8(2)

I confirm that paramiko tries to connect with the first SSH key managed by gpg-agent, and fails to find a key supported by the remote device (Cisco ASAv) in the list of SSH keys available in sshcontrol.

Trying to connect with ansible/paramiko fails:

2017-12-27 18:36:17,508 p=30500 u=root |  creating new control socket for host 172.21.154.231:22 as user admin
2017-12-27 18:36:17,508 p=30500 u=root |  control socket path is /root/.ansible/pc/9c316ba63b
2017-12-27 18:36:17,508 p=30500 u=root |  current working directory is /media/actionmystique/SAMSUNG5-Virtual/Labs/GNS3/git-Ansible-Labs-Collection/Cisco-Nexus-9k/7.0.3.17.1/Ansible
2017-12-27 18:36:17,508 p=30500 u=root |  using connection plugin network_cli
2017-12-27 18:36:17,576 paramiko.transport starting thread (client mode): 0x21121310L
2017-12-27 18:36:17,576 paramiko.transport Local version/idstring: SSH-2.0-paramiko_2.4.0
2017-12-27 18:36:17,576 paramiko.transport Remote version/idstring: SSH-2.0-Cisco-1.25
2017-12-27 18:36:17,577 paramiko.transport Connected (version 2.0, client Cisco-1.25)
2017-12-27 18:36:17,577 paramiko.transport kex algos:[u'diffie-hellman-group14-sha1'] server key:[u'ssh-rsa'] client encrypt:[u'aes128-cbc', u'aes192-cbc', u'aes256-cbc', u'aes128-ctr', u'aes192-ctr', u'aes256-ctr'] server encrypt:[u'aes128-cbc', u'aes192-cbc', u'aes256-cbc', u'aes128-ctr', u'aes192-ctr', u'aes256-ctr'] client mac:[u'hmac-sha1', u'hmac-sha1-96'] server mac:[u'hmac-sha1', u'hmac-sha1-96'] client compress:[u'none'] server compress:[u'none'] client lang:[u''] server lang:[u''] kex follows?False
2017-12-27 18:36:17,577 paramiko.transport Kex agreed: diffie-hellman-group14-sha1
2017-12-27 18:36:17,577 paramiko.transport HostKey agreed: ssh-rsa
2017-12-27 18:36:17,577 paramiko.transport Cipher agreed: aes128-ctr
2017-12-27 18:36:17,577 paramiko.transport MAC agreed: hmac-sha1
2017-12-27 18:36:17,577 paramiko.transport Compression agreed: none
2017-12-27 18:36:17,618 paramiko.transport kex engine KexGroup14 specified hash_algo <built-in function openssl_sha1>
2017-12-27 18:36:17,618 paramiko.transport Switch to new keys ...
2017-12-27 18:36:17,644 paramiko.transport Trying SSH agent key 2f7a15a2a73f48f77bd29d0bb27e6397
2017-12-27 18:36:17,646 paramiko.transport userauth is OK
2017-12-27 18:36:23,230 paramiko.transport Authentication (publickey) failed.
2017-12-27 18:36:23,253 paramiko.transport Trying SSH agent key 96208e97b46ec2b2b54895c1c955d51c
2017-12-27 18:36:23,255 paramiko.transport Disconnect (code 2): Protocol error: expected packet type 50, got 5
2017-12-27 18:36:23,257 paramiko.transport Trying SSH agent key 12e96f16dad2f5b51942c26f3ed164dd
2017-12-27 18:36:23,257 paramiko.transport Trying SSH agent key ad13a38e248fa587518a05cf1cbee557
2017-12-27 18:36:23,257 paramiko.transport Trying SSH agent key a5e6316e8b66accee130ed145cc9b8db
2017-12-27 18:36:23,258 p=30500 u=root |  connecting to host 172.21.154.231 returned an error
2017-12-27 18:36:23,258 p=30500 u=root |  ssh [email protected]:22 : Private key file is encrypted
To connect as a different user, use -u <username>.
2017-12-27 18:37:17,600 p=30399 u=root |  fatal: [ASAv1]: FAILED! => {

Trying to connect with openssh 7.6p1 succeeds:

# ssh [email protected] admin logged in to ASAv1
Logins over the last 1 days: 24.  Last login: 17:32:50 UTC Dec 27 2017 from 172.21.0.1
Failed logins since the last login: 0.  
Type help or '?' for a list of available commands.
ASAv1> en
Password: **********
ASAv1# sh ver

Cisco Adaptive Security Appliance Software Version 9.8(2) 
Firepower Extensible Operating System Version 2.2(2.52)
Device Manager Version 7.8(2)
...

If I move the required key in first position of ~/.gnupg/sshcontrol file, then this issue does not appear..

from paramiko.

radssh commented on June 17, 2024

Another impact of #387 it would appear. Specifically the remote switch (typically) dropping the connection on receiving a second SSH_MSG_SERVICE_REQUEST message, when expecting the dialog to continue with SSH_MSG_USERAUTH_REQUEST.

from paramiko.

rarylson commented on June 17, 2024

Hi, I proposed an improved version on the top of the fix proposed by @jansegre (it fixes more problems, when different auth methods are tried in a Mikrotik or Cisco router, for example).

I also verified that the commit passes in all Paramiko tests.

I also made a pull request to jansegre (in it's fork). But as bitprophet and radssh are working in a more general solution on #387, I'm not creating a new pull request in the mainstream.

However, I'm showing my changes here and I hope they can help.

from paramiko.

ssbarnea commented on June 17, 2024

Any chance of seeing this resolved? Somehow I just realised that if you happen to use more than one ssh key and ssh agent, paramiko is not for you.

The reordering of keys is not going to work because is almost impossible to know a-priory which ssh key is needed for a specific host.

from paramiko.

Authentication fails with more than one key in agent about paramiko HOT 11 OPEN

Comments (11)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent