Netmiko: SSH Issue: paramiko.ssh_exception.SSHException: No existing session
Master issue for this problem...historically this has been a problem, and I don't think there has been a resolution.
ktbyers
All 4 comments
Reference issues:
ktbyers
on 13 Dec 2018
For what it's worth, I've been hitting this issue, and in all the cases I've tested so far, increasing the timeout fixed it. In the two linked tickets, that's what it looks like solved it as well. Your default timeout is 100, I suggest people just stick with it. The only place I've seen it in testing ~12,000 devices has been in older IOS devices. In some cases, even upgrading the IOS didn't fix it, so I'm just gonna generalize and say older Catalyst hardware types. Could be a latency issue, though I doubt it because of my test cases. Just give the device the 100 seconds it's deserved.
If anyone is concerned on avoid the 100 seconds bombing out, you could also do a ping test using NMAP before trying to connect and making sure you get a successful ICMP reply and that TCP 22 is open. It will save you lots of trouble. That you can bump the timers down way low. I do 1-3 seconds. Only if you pass that, then try connecting. Just a thought
Bug replicated below. Technically, the two configs are identical when it gets to paramiko:
import netmiko
net_connect = netmiko.ConnectHandler(device_type='cisco_ios', host='HOSTNAME', username='USERNAME', password='PASSWORD', use_keys=False, allow_agent=False, timeout=5)
import paramiko
remote_conn_pre = paramiko.SSHClient()
remote_conn_pre.set_missing_host_key_policy(paramiko.AutoAddPolicy())
remote_conn_pre.connect(hostname='HOSTNAME', port=22, username='USERNAME', password='PASSWORD', look_for_keys=False, allow_agent=False, timeout=5)
After removing the timeout, no long having issue.
@ktbyers #322 was solved with timeout, but #467 you closed without resolution. If you're thinking that one was caused by bad key/auth negotiation, that would make sense. I think if these come up again, the first recommendation should be to use the default timeout, second being to try connecting in paramiko with the same settings, similar to how I did above, and see if the error persists. Should help isolate the issue to Paramiko.
TomCos
on 16 May 2019
Going to close this since it looks like the referenced issues are also closed.
Thanks @TomCos for the excellent follow up info!
carlmontanari
on 24 May 2019
Yes great follow-up @TomCos. That No existing session issue was a real pain so glad that you dived into it and got a bunch more data on it.
ktbyers
on 24 May 2019
Related issues
JoshuaSmeda
路
3Comments
Rooster-OC
路
5Comments
aegiacometti
路
6Comments
ktbyers
路
7Comments
alexsabry
路
4Comments
Most helpful comment
For what it's worth, I've been hitting this issue, and in all the cases I've tested so far, increasing the timeout fixed it. In the two linked tickets, that's what it looks like solved it as well. Your default timeout is 100, I suggest people just stick with it. The only place I've seen it in testing ~12,000 devices has been in older IOS devices. In some cases, even upgrading the IOS didn't fix it, so I'm just gonna generalize and say older Catalyst hardware types. Could be a latency issue, though I doubt it because of my test cases. Just give the device the 100 seconds it's deserved.
If anyone is concerned on avoid the 100 seconds bombing out, you could also do a ping test using NMAP before trying to connect and making sure you get a successful ICMP reply and that TCP 22 is open. It will save you lots of trouble. That you can bump the timers down way low. I do 1-3 seconds. Only if you pass that, then try connecting. Just a thought
Bug replicated below. Technically, the two configs are identical when it gets to paramiko:
import netmiko
net_connect = netmiko.ConnectHandler(device_type='cisco_ios', host='HOSTNAME', username='USERNAME', password='PASSWORD', use_keys=False, allow_agent=False, timeout=5)
import paramiko
remote_conn_pre = paramiko.SSHClient()
remote_conn_pre.set_missing_host_key_policy(paramiko.AutoAddPolicy())
remote_conn_pre.connect(hostname='HOSTNAME', port=22, username='USERNAME', password='PASSWORD', look_for_keys=False, allow_agent=False, timeout=5)
After removing the timeout, no long having issue.
@ktbyers #322 was solved with timeout, but #467 you closed without resolution. If you're thinking that one was caused by bad key/auth negotiation, that would make sense. I think if these come up again, the first recommendation should be to use the default timeout, second being to try connecting in paramiko with the same settings, similar to how I did above, and see if the error persists. Should help isolate the issue to Paramiko.