Exception error reading ssh protocol banner

Hello, Dear Developers,

In the last several days I have got the following error:
SSHException: Error reading SSH protocol banner[Errno 104] Connection reset by peer

The interesting thing is that I haven’t done any changes to a python script, haven’t updated paramiko package and no changes were made to the company server. Another interesting thing is that it works on my local Windows PC.

Bringing some details…
I have a simple Ubuntu 14.04.4 server and a simple backup script which is scheduled via cron (once per week) and which uploads several .zip archives to the company server.

But the last backup was failed because of the error above. The error appears on the step of making a Transport. Here is the piece of code:
`
config = configuration.BackupSystemConfiguration()

host = config.host
port = config.port

transport = paramiko.Transport((host, port))    # <- error is raised here`

I have enabled logging using

import logging
logging.basicConfig(level=logging.DEBUG)

And it shows me the following:

DEBUG:paramiko.transport:starting thread (client mode): 0xf37e9b50L
DEBUG:paramiko.transport:Local version/idstring: SSH-2.0-paramiko_2.4.1
ERROR:paramiko.transport:Exception: Error reading SSH protocol banner[Errno 104] Connection reset by peer
ERROR:paramiko.transport:Traceback (most recent call last):
ERROR:paramiko.transport:  File "/usr/local/lib/python2.7/dist-packages/paramiko/transport.py", line 1893, in run
ERROR:paramiko.transport:    self._check_banner()
ERROR:paramiko.transport:  File "/usr/local/lib/python2.7/dist-packages/paramiko/transport.py", line 2049, in _check_banner
ERROR:paramiko.transport:    'Error reading SSH protocol banner' + str(e)
ERROR:paramiko.transport:SSHException: Error reading SSH protocol banner[Errno 104] Connection reset by peer
ERROR:paramiko.transport:

Again, when I try to execute this script on my local Windows PC with the same version of paramiko (2.4.1) I have no errors — everything works flawlessly.

I will be very thankfull for any advice and help. And excuse me for any mistakes — English is not my native language.

Regards,
John.

I’m trying to use ansible to run a very basic script which is to SSH to a switch and run a show version.
I’m using the standard ios_command module which is from ansible.

by default it uses Paramiko as ssh agent and I’m getting the following Error :

paramiko.transport starting thread (client mode): 0x78c7f250L
paramiko.transport Local version/idstring: SSH-2.0-paramiko_2.1.2
paramiko.transport Banner: C6509#SSH-2.0-paramiko_2.1.2
paramiko.transport Banner: Translating «SSH-2.0-paramiko_2.1.2»
paramiko.transport Banner: % Unknown command or computer name, or unable to find computer address
paramiko.transport Banner: C6509#
paramiko.transport Exception: Error reading SSH protocol banner
paramiko.transport Traceback (most recent call last):
paramiko.transport File «/usr/local/lib/python2.7/site-packages/paramiko/transport.py», line 1749, in run
paramiko.transport self._check_banner()
paramiko.transport File «/usr/local/lib/python2.7/site-packages/paramiko/transport.py», line 1897, in _check_banner
paramiko.transport raise SSHException(‘Error reading SSH protocol banner’ + str(e))
paramiko.transport SSHException: Error reading SSH protocol banner

I have tried to do some chnages and troubleshooting on paramiko packet.py and transport.py but couldnt get that working.

can anyone help me what is this SSH protocol banner checking is and how to solve this?

Thanks
Reza Toghraee

The text was updated successfully, but these errors were encountered:

I know I’ve seen this before but cannot find the ticket offhand ; you may want to try searching the other tickets. That said, this (targeting non POSIX ssh servers) is a common issue that we don’t have a lot of resources for fixing unfortunately. Leaving open for now but may close as dupe later.

Don’t have time to test this out right now, but it looks like the TCP connection remote side is just a plain telnet connection, not consistent with the opening protocol exchange for an ssh transport, where both client and server expect to send/receive a plaintext SSH version exchange (see RFC4253).

It looks like the remote side is issuing an input prompt («C6509#») and taking the text sent by the client as a command to invoke, sending an error message and reprompting («C6509#») that the paramiko client side can’t find anything looking like a SSH version string, and aborting the connection.

Can you double check that you can successfully use a standard ssh client to connect to the hostname (and port) that you are using under Ansible? Does the Ansible ios_command module have support for telnet connections, in addition to ssh connections?

What I found today was that I have the same issue and same debug log as sent by Kaag on my Cisco Catalyst 6500 , running IOS s72033-advipservicesk9-mz.151-2.SY10

However, today I tried to connect a Cisco 3850 running cat3k_caa-universalk9.16.03.02.SPA
interestingly it worked on Cisco 3850.

I captured both paramiko logs on 6500 and 3850 to compare :

============6500============
paramiko.transport: Connected (version 2.0, client Cisco-1.25)
paramiko.transport: kex algos:[u’diffie-hellman-group-exchange-sha1′, u’diffie-hellman-group14-sha1′, u’diffie-hellman-group1-sha1′] server key:[u’ssh-rsa’] client encrypt:[u’aes128-cbc’, u’3des-cbc’, u’aes192-cbc’, u’aes256-cbc’] server encrypt:[u’aes128-cbc’, u’3des-cbc’, u’aes192-cbc’, u’aes256-cbc’] client mac:[u’hmac-sha1′, u’hmac-sha1-96′, u’hmac-md5′, u’hmac-md5-96′] server mac:[u’hmac-sha1′, u’hmac-sha1-96′, u’hmac-md5′, u’hmac-md5-96′] client compress:[u’none’] server compress:[u’none’] client lang:[u»] server lang:[u»] kex follows?False
paramiko.transport: Kex agreed: diffie-hellman-group1-sha1
paramiko.transport: Cipher agreed: aes128-cbc
paramiko.transport: MAC agreed: hmac-md5
paramiko.transport: Compression agreed: none
paramiko.transport: kex engine KexGroup1 specified hash_algo
paramiko.transport: Switch to new keys .
paramiko.transport: Trying key 542f7f11dcaafae42ec947dbf96bac97 from /root/.ssh/id_rsa
paramiko.transport: userauth is OK
paramiko.transport: Exception: Illegal info request from server
paramiko.transport: Traceback (most recent call last):
paramiko.transport: File «/usr/local/lib/python2.7/site-packages/paramiko/transport.py», line 1800, in run
paramiko.transport: self.auth_handler._handler_table[ptype](self.auth_handler, m)
paramiko.transport: File «/usr/local/lib/python2.7/site-packages/paramiko/auth_handler.py», line 575, in _parse_userauth_info_request
paramiko.transport: raise SSHException(‘Illegal info request from server’)
paramiko.transport: SSHException: Illegal info request from server
paramiko.transport:
paramiko.transport: Trying SSH agent key 542f7f11dcaafae42ec947dbf96bac97
paramiko.transport: Trying discovered key 542f7f11dcaafae42ec947dbf96bac97 in /root/.ssh/id_rsa

============3850============
paramiko.transport: starting thread (client mode): 0xdeb37810L
paramiko.transport: Local version/idstring: SSH-2.0-paramiko_2.1.2
paramiko.transport: Remote version/idstring: SSH-2.0-Cisco-1.25
paramiko.transport: Connected (version 2.0, client Cisco-1.25)
paramiko.transport: kex algos:[u’diffie-hellman-group-exchange-sha1′, u’diffie-hellman-group14-sha1′] server key:[u’ssh-rsa’] client encrypt:[u’aes128-ctr’, u’aes192-ctr’, u’aes256-ctr’, u’aes128-cbc’, u’3des-cbc’, u’aes192-cbc’, u’aes256-cbc’] server encrypt:[u’aes128-ctr’, u’aes192-ctr’, u’aes256-ctr’, u’aes128-cbc’, u’3des-cbc’, u’aes192-cbc’, u’aes256-cbc’] 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
paramiko.transport: Kex agreed: diffie-hellman-group14-sha1
paramiko.transport: Cipher agreed: aes128-ctr
paramiko.transport: MAC agreed: hmac-sha1-96
paramiko.transport: Compression agreed: none
paramiko.transport: kex engine KexGroup14 specified hash_algo
paramiko.transport: Switch to new keys .
paramiko.transport: Trying key 542f7f11dcaafae42ec947dbf96bac97 from /root/.ssh/id_rsa
paramiko.transport: userauth is OK
paramiko.transport: Authentication (publickey) successful!
paramiko.transport: EOF in transport thread

The difference between the 2 is :

3850 : Kex agreed: diffie-hellman-group14-sha1
6500: Kex agreed: diffie-hellman-group1-sha1

3850: Cipher agreed: aes128-ctr
6500: Cipher agreed: aes128-cbc

3550: MAC agreed: hmac-sha1-96
6500: MAC agreed: hmac-md5

This seems to be related to Cisco IOS implementation of SSH on 6500 or 3560

6509#sh ip ssh
SSH Enabled — version 2.0
Authentication timeout: 120 secs; Authentication retries: 3
Minimum expected Diffie Hellman key size : 1024 bits

3850#sh ip ssh
SSH Enabled — version 2.0
Authentication methods:publickey,keyboard-interactive,password
Authentication Publickey Algorithms:x509v3-ssh-rsa,ssh-rsa
Hostkey Algorithms:x509v3-ssh-rsa,ssh-rsa
Encryption Algorithms:aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
MAC Algorithms:hmac-sha1,hmac-sha1-96
KEX Algorithms:diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
Authentication timeout: 120 secs; Authentication retries: 3
Minimum expected Diffie Hellman key size : 2048 bits

cat test_paramiko_cisco.py
import logging
import paramiko

logging.getLogger(«paramiko»).setLevel(logging.DEBUG)
ssh = paramiko.SSHClient()
ssh.load_system_host_keys(‘/root/.ssh/known_hosts’)
ssh.set_missing_host_key_policy(paramiko.WarningPolicy())
paramiko.util.log_to_file(«/root/paramiko.log»)
ssh.connect(‘SWITCH_IP’, username=’USERNAME’,password=’KEY_PASS_PHRASE’, key_filename=’/root/.ssh/id_rsa’, allow_agent=’False’)
remote_conn=ssh.invoke_shell()
remote_conn.send(«show runn»)
output=remote_conn.recv(5000)
print output

I’m still looking forward to see how to fix the issue with IOS / 6500 .

Источник

I BELIEVE THIS IS A KNOWN «ISSUE» / OCCURRENCE — BUT I COULD NOT FIND A THREAD WITH THE SOLUTION / WORK AROUND IN.
I have a simple script that the aim is to ssh remote access all the devices in a simple device file — if I am able to reach Privilege Exec mode. I print a «Login Successful!» message, if not. I have the simple Error Handling option (for now).
The first 2 devices are known working devices. and the script returns my printed message.
However, the 3rd devices is a device I know I cannot SSH to (this is to test my Error Handling). and the 4th device is another device that is working as expected.
Below is the output I get from my script —
For the 3rd device. I can see my Error Handling working («error message. «), and the script moves onto the 4th device. however I still get the traceback error above the output.
I was wondering if this is bug / not possible to remove. or if there is a way to remove this traceback error??
(below the output is a copy of the full script)

Connecting to Device .

Connecting to Device .

Connecting to Device 1.1.1.1.

Exception: Error reading SSH protocol banner
Traceback (most recent call last):
File «/usr/lib/python3.6/site-packages/paramiko/transport.py», line 2138, in _check_banner
buf = self.packetizer.readline(timeout)
File «/usr/lib/python3.6/site-packages/paramiko/packet.py», line 367, in readline
buf += self._read_timeout(timeout)
File «/usr/lib/python3.6/site-packages/paramiko/packet.py», line 576, in _read_timeout
raise socket.timeout()
socket.timeout

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File «/usr/lib/python3.6/site-packages/paramiko/transport.py», line 1966, in run
self._check_banner()
File «/usr/lib/python3.6/site-packages/paramiko/transport.py», line 2143, in _check_banner
«Error reading SSH protocol banner» + str(e)
paramiko.ssh_exception.SSHException: Error reading SSH protocol banner

error message.
Connecting to Device .

/.ssh/config’ > try: net_connect = ConnectHandler(**ios_device) net_connect.enable() print(‘Login Successful! ‘ + ‘n’) net_connect.disconnect() ##— Error Handling except Exception: print(‘error message. ‘) continue»>

The text was updated successfully, but these errors were encountered:

Источник

I’ve got SSHException: Error reading SSH protocol banner exception when I tried to spawn ssh connection with eventlet. You can run the following code to repeat this error:

The text was updated successfully, but these errors were encountered:

I’m seeing this with when using a ProxyCommand socket. Paramiko hangs at this line until the timeout is reached, then I see the SSH protocol banner error:
https://github.com/paramiko/paramiko/blob/752507a29/paramiko/transport.py#L1700

This also works:

If there are any workarounds, please let me know.

In the failure cases above, the CPU spikes during the 15 seconds until the banner timeout. During that time, paramiko is stuck in a loop between Packetizer._read_timeout() and ProxyCommand.recv() :

No idea why I marked this as «needs investigation» before — we have never supported eventlet/greenlets 🙁 That’s not to say we wouldn’t like to at some point but it’s more of a feature request than an actual bug in my opinion.

I’ve opened a new proper feature ticket for this (so hopefully anybody searching will see that it’s an unimplemented feature) and will link the two together for posterity.

Greenthread/eventlet/gevent has never really been supported by paramiko. Since paramiko is written to use threads as its concurrency model there might be several weird raises with how eventlet interacts with our threading model.

Источник

I have a paramiko client which reboots a linux server which is then reprovisioned using IPXE. I then create a new client, and poll the host with a new client waiting for the server to come back up. Just after the ssh server on my reprovisioned server starts. I noticed that I get an exception, which I which I can’t catch because it’s in a different thread, printing out on the logger that: SSHException(‘Error reading SSH protocol banner[WinError 10053] An established connection was aborted by the software in your host machine’,)

This correlates to the _check_banner function inside of the ssh transport class.

Of course I catch an issue with the client later on and then retry the connection to the host which eventually works after all services on the server are up and running (maybe 1 or 2 minutes later). It also works flawlessly after making a stable connection. This is more of an issue while connecting to a new server while it’s booting up.

I have ran through the code several times (It’s a race condition), but can’t tell if the client.connect call which generates the error succeeds, but I do know that subsequent test calls to ensure that I have a valid connection fail.
Correct me if I am wrong, but if the transport has started, it means that a connection was established to the ssh server, correct?
If this is indeed the case, there may be some additional checks from the client connection code that needs to be added so that an exception is raised in the connect method before t.start_client is called in the connect method for the client.
I would make the changes myself at this point and submit a merge request, but my paramiko-FU is still way too low to know what to check in code and how to check it.

NOTE: This is a linux server that I am connecting to. Not a Cisco switch and not a weird implementation of a windows ssh server.

P.S. Thank you in advance.

The text was updated successfully, but these errors were encountered:

Maybe this is just a matter of suppressing errors on a connection we know is failing or going to fail?

Correct me if I am wrong, but if the transport has started, it means that a connection was established to the ssh server, correct?

Once the socket connection is made, the client and server start the protocol negotiation, where both sides send a short plaintext «banner» consisting of «SSH-» + (protocol version) + «-» + (software version) + (optional comment) + «» + «», then each side can send their preferred lists of compression/ciphers/mac/keys, etc., followed by the formal setup of the secure encrypted transport. What seems to be happening is that the socket connection is accepted by the server, but the server side never sends any data (at least for 15 seconds). My guess is that the server provisioning is stalling on generating new host keys when the entropy pool for the necessary crypto-suitable random number generator is basically empty.

Paramiko handles the transport send/recv control on a separate thread, so your main thread is not blocking during this wait (good), but that makes it harder to determine exactly if/when that timeout occurs from the «main» thread (bad). It does not look like there is any type of usable event for the completion of the protocol negotiation like for most other paramiko cross-thread notifications. After a certain point, the client is going to give up waiting on the server to say something/anything.

it looks like you could try a couple of different workarounds:

1. Set the transport.banner_timeout higher than 15 seconds before calling connect, in hopes that the socket connection eventually is sent data.
2. Set the transport.banner_timeout lower, and poll for the transport.remote_version getting populated by the Transport thread when it does get the initial text line.
3. Test the connection using a plain socket.create_connection() and recv() to pre-screen that the SSH server is in a chatty state. If that test succeeds, then reconnect with paramiko.SSHClient() or paramiko.Transport() .
4. Tweak the server provisioning to ensure the host key(s) and whatever missing bits are present prior to starting sshd actively accepting socket connections.

Out of curiosity, can you test the behavior of the OpenSSH command line client ssh -vv when it connects to a freshly reprovisioned server? That’s usually considered the reference for determining «proper» handling of screwy situations like this.

Источник

0

1

def check_sftp_connection(port_sftp):
    '''try to authorized on CrushFTP via sftp and sownload file'''
    try:
       	print('1')
        transport = paramiko.Transport((args.ip, port_sftp))
       	print('2')
        transport.connect(username=args.username, password=args.password)
       	print('3')
        sftp_con = paramiko.SFTPClient.from_transport(transport)
       	print('4')
        if sftp_con.file('/hello', mode='r', bufsize=-1).read().decode().find("Hello")==-1:
       	    print('5')
            sftp_con.close()
            return "test file not found! Probably sftp protocol works incorrect!", 2
    except:
	return "CrushFTP is not available via sftp protocol", 2
    return '', 0

1
2
Exception: Error reading SSH protocol banner
Traceback (most recent call last):
  File "/usr/lib/python3.4/site-packages/paramiko/transport.py", line 1854, in _check_banner
    buf = self.packetizer.readline(timeout)
  File "/usr/lib/python3.4/site-packages/paramiko/packet.py", line 327, in readline
    buf += self._read_timeout(timeout)
  File "/usr/lib/python3.4/site-packages/paramiko/packet.py", line 497, in _read_timeout
    raise socket.timeout()
socket.timeout

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.4/site-packages/paramiko/transport.py", line 1710, in run
    self._check_banner()
  File "/usr/lib/python3.4/site-packages/paramiko/transport.py", line 1858, in _check_banner
    raise SSHException('Error reading SSH protocol banner' + str(e))
paramiko.ssh_exception.SSHException: Error reading SSH protocol banner

Critical error:  process uptime is too low... Only 8 sec; CrushFTP is not available via sftp protocol