Paramiko : Error reading SSH protocol banner

Recently, I made a code that connect to work station with different usernames (thanks to a private key) based on paramiko.

I never had any issues with it, but today, I have that : SSHException: Error reading SSH protocol banner

This is strange because it happens randomly on any connections. Is there any way to fix it ?

Solution 1:

It depends on what you mean by "fix". The underlying cause, as pointed out in the comments, are congestion/lack of resources. In that way, it's similar to some HTTP codes. That's the normal cause, it could be that the ssh server is returning the wrong header data.

429 Too Many Requests, tells the client to use rate limiting, or sometimes APIs will return 503 in a similar way, if you exceed your quota. The idea being, to try again later, with a delay.

You can attempt to handle this exception in your code, wait a little while, and try again. You can also edit your transport.py file, to set the banner timeout to something higher. If you have an application where it doesn't matter how quickly the server responds, you could set this to 60 seconds.

Solution 2:

Adding to TinBane's answers, suggesting to edit transport.py: you don't have to do that anymore.

Since Paramiko v. 1.15.0, released in 2015, (this PR, to be precise) you can configure that value when creating Paramiko connection, like this:

client = SSHClient()
client.connect('ssh.example.com', banner_timeout=200)

In the current version of Paramiko as of writing these words, v. 2.7.1, you have 2 more timeouts that you can configure when calling connect method, for these 3 in total (source):

• banner_timeout - an optional timeout (in seconds) to wait for the SSH banner to be presented.
• timeout - an optional timeout (in seconds) for the TCP connect
• auth_timeout - an optional timeout (in seconds) to wait for an authentication response.

Solution 3:

When changing the timeout value (as TinBane mentioned) in the transport.py file from 15 to higher the issue resolved partially. that is at line #484:

self.banner_timeout = 200 # It was 15

However, to resolve it permanently I added a static line to transport.py to declare the new higher value at the _check_banner(self): function.

Here is specifically the change:

• It was like this:

 def _check_banner(self):
        for i in range(100):
            if i == 0:
                timeout = self.banner_timeout
            else:
                timeout = 2

• After the permanent change became like this:

 def _check_banner(self):
        for i in range(100):
            if i == 0:
                timeout = self.banner_timeout
                timeout = 200 # <<<< Here is the explicit declaration 
            else:
                timeout = 2

Solution 4:

I had this issue with 12 parallel (12 threads) connections via single bastion. As I had to solve it "quick and dirty" I've added a sleep time.

for target in targets:
    deployer.deploy_target(target, asynchronous=True)

Changed to:

for target in targets:
    deployer.deploy_target(target, asynchronous=True)
    time.sleep(5)

This works for me. As well I've added a banner_timeout as was suggested above to make it more reliable.

client.connect(bastion_address, banner_timeout=60)