So, I am Having the same problem whiele logging into dells idrac 6.
It takes like 4-6 seconds to login, but I get the content of "ls -la" back, after it "crashes".
23:09:53.786 Current date: 2020-02-04
23:09:53.786 Started a new SSH session.
23:09:53.790 Connecting to SSH server 192.168.2.3:22.
23:09:53.792 Connection established.
23:09:54.820 Server version: SSH-2.0-OpenSSH_7.4
23:09:54.820 First key exchange started. Cryptographic provider: Windows CNG (x86) with additions
23:09:54.824 Host key algorithm list after reordering: RSA/sha2-512,RSA/sha2-256,Ed25519,ECDSA/nistp256,RSA,ECDSA/secp256k1,ECDSA/nistp521,ECDSA/nistp384.
23:09:59.530 Received host key from the server. Algorithm: RSA, size: 2048 bits, SHA-256 fingerprint: wkLKJInigQ3DtHH7yGipvv/3DTXGnpfjzW8FpDlpPm4.
23:09:59.537 First key exchange completed using Curve25519. Session encryption: aes256-ctr, integrity: hmac-sha1, compression: none.
23:09:59.537 Attempting password authentication.
23:10:01.757 Authentication completed.
23:10:01.757 Extension "no-flow-control" disabled.
23:10:01.822 Synchronizing with server's host keys.
23:10:01.832 Host key synchronization completed without saving or erasing any keys. Number of keys received: 4.
23:10:01.863 Terminal channel opened.
23:10:01.863 Opened session channel 0.
23:10:01.877 Terminal channel: PTY request accepted.
23:10:01.915 Terminal channel: Terminal shell opened.
23:10:01.924 Terminal channel: Terminal process launched.
This is normal server where no problem occures.
23:10:39.102 Current date: 2020-02-04
23:10:39.102 Started a new SSH session.
23:10:39.107 Connecting to SSH server 192.168.2.2:22.
23:10:39.109 Connection established.
23:10:39.118 Server version: SSH-2.0-OpenSSH_8.1
23:10:39.118 First key exchange started. Cryptographic provider: Windows CNG (x86) with additions
23:10:39.122 Host key algorithm list after reordering: RSA/sha2-512,RSA/sha2-256,Ed25519,ECDSA/nistp256,RSA,ECDSA/secp256k1,ECDSA/nistp521,ECDSA/nistp384.
23:10:39.143 Received host key from the server. Algorithm: RSA, size: 2048 bits, SHA-256 fingerprint: +TELx98+4h1eSL3e2EMPWn3YKW1Cr5OpR0SyGe30BsI.
23:10:39.149 First key exchange completed using Curve25519. Session encryption and integrity: aes256-gcm, compression: none.
23:10:39.150 Attempting password authentication.
23:10:39.158 Authentication completed.
23:10:39.158 Extension "no-flow-control" disabled.
23:10:39.165 Synchronizing with server's host keys.
23:10:39.165 Host key synchronization completed without saving or erasing any keys. Number of keys received: 3.
23:10:39.194 Terminal channel opened.
23:10:39.194 Opened session channel 0.
23:10:39.201 Terminal channel: PTY request accepted.
23:10:39.201 Terminal channel: Terminal shell opened.
23:10:39.211 Terminal channel: Terminal process launched.
===============================================================================
RACADM version 2.91 (Build 02)
Copyright (c) 2003-2010 Dell, Inc.
All Rights Reserved
===============================================================================
RACADM usage syntax:
racadm
Examples:
racadm getsysinfo
racadm getsysinfo -d
racadm getniccfg
racadm setniccfg -d
racadm setniccfg -s 192.168.0.120 255.255.255.0 192.168.0.1
racadm getconfig -g cfgLanNetworking
Display a list of available subcommands for the RAC:
racadm help
Display more detailed help for a specific subcommand:
racadm help
Exception ignored in:
Traceback (most recent call last):
File "C:\UsersDanielAppData\Local\Programs\Python\Python38\lib\site-packages\paramiko\file.py", line 66, in __del__
File "C:\UsersDanielAppData\Local\Programs\Python\Python38\lib\site-packages\paramiko\channel.py", line 1392, in close
File "C:\UsersDanielAppData\Local\Programs\Python\Python38\lib\site-packages\paramiko\channel.py", line 991, in shutdown_write
File "C:\UsersDanielAppData\Local\Programs\Python\Python38\lib\site-packages\paramiko\channel.py", line 967, in shutdown
File "C:\UsersDanielAppData\Local\Programs\Python\Python38\lib\site-packages\paramiko\transport.py", line 1846, in _send_user_message
AttributeError: 'NoneType' object has no attribute 'time'
Process finished with exit code 0
Its possible to supress this ? I cant explain how this error occures and why...
when I connect to another server openssh 8.1 i dont have this problem.
BTW im on windows. Gonna try it on my pi too.
Ok, seems to be an windows related problem.
I have the the same problem:
Exception ignored in: <function BufferedFile.__del__ at 0x10dbe7550>
Traceback (most recent call last):
File "/Users/max/p/pypi__paramiko/.venv/lib/python3.8/site-packages/paramiko/file.py", line 66, in __del__
File "/Users/max/p/pypi__paramiko/.venv/lib/python3.8/site-packages/paramiko/channel.py", line 1392, in close
File "/Users/max/p/pypi__paramiko/.venv/lib/python3.8/site-packages/paramiko/channel.py", line 991, in shutdown_write
File "/Users/max/p/pypi__paramiko/.venv/lib/python3.8/site-packages/paramiko/channel.py", line 967, in shutdown
File "/Users/max/p/pypi__paramiko/.venv/lib/python3.8/site-packages/paramiko/transport.py", line 1846, in _send_user_message
AttributeError: 'NoneType' object has no attribute 'time'
I'm on macos and using an Ubuntu 18.04 server.
P.S. I've checked the same script on linux server and it works fine. So I have this problem only on macos.
Hi,
same issue on with Python 3.8.1
anyone spot a workaround for this?
any updates?
got same problem using Python 3.8.1 paramiko 2.7.1 connecting to OpenSSH_7.9p1, OpenSSL 1.1.1a 20 Nov 2018
This exception is raised from a simple time.time() call here:
def _send_user_message(self, data):
"""
send a message, but block if we're in key negotiation. this is used
for user-initiated requests.
"""
start = time.time()
while True:
...
That's the standard library time module, from import time at the top of the file. How could that possibly fail? Well, this must be during the exit of the process, and python must be cleaning up and freeing everything somehow ... I'm not familiar with this process, but it seems likely related to this stuff, also near the top of transport.py
# for thread cleanup
_active_threads = []
def _join_lingering_threads():
for thr in _active_threads:
thr.stop_thread()
import atexit
atexit.register(_join_lingering_threads)
All those threads are "daemonized" with self.setDaemon(True), so this doesn't wait for them to exit. It just tells them to start the process of stopping, then this atexit handler finishes, and the threads are still working on stopping after the main thread continues to clean up imports and stuff (well that's my wild guess).
So the fix might be to have this atexit handler wait a second or so for the transport threads to actually exit. (Or get rid of the atexit behavior if it's not really needed.)
Same problem on Python 3.7.3 using Vagrant box debian/buster64.
Can reproduce this issue on Paramiko 2.7.1 and Paramiko 2.7.0.
Paramiko 2.6.0 works without this exception.
I'm also getting this on ArchLinux 4/9/2020, Python 3.8.2, and python-paramiko 2.7.1-1.
e: I think @ploxiln is correct. I added a 5 second delay to the end of my script and this no longer happens.
In some cases this happens, i solved the problem like @wirecat said, I slept the thread for 0.1 seconds before read the stdout.
Got the same issue on Python 3.8.4 for Mac Mojave but sleep resolved it.
Solved issue by using context manager (__enter__, __exit__) definitions to close session. time trick mentioned above did not work for me -- currently utilizing PySFTP (wrapper on top of Paramiko).
Had the same problem with:
Paramiko 2.6.0 is working without exceptions.
Solved similar as @synchronizing . I had paramiko cleanup in __del__ method and that was the root cause for me for this issue. After moving the paramiko cleanup to context managers (before GC) everything works.
I found an alternative solution.
I had the same problem when using pysftp
My code was something like :
import pysftp
...... some setup
sftp = pysftp.Connection (host=ftpHost,username=ftpUser,password=ftpPass, cnopts = cnopts , port= ftpPort )
........ some ftp commands
At the end of my code i just added
sftp=None
And the problem was solved.
@eduardogpg putting a sleep worked
I worked around it by closing the stdin file object:
stdin, stdout, stderr = client.exec_command('ls -l')
stdin.close()
I worked around it by closing the
stdinfile object:stdin, stdout, stderr = client.exec_command('ls -l') stdin.close()
This did the trick for me on MacOS Catalina! Thank you!
I am also troubled by this:
File "C:\ProgramData\Anaconda3\envs\claw\lib\site-packages\paramiko\client.py", line 508, in exec_command
chan = self._transport.open_session(timeout=timeout)
AttributeError: 'NoneType' object has no attribute 'open_session'
It happens when I connect to a host which is in the process of booting up and not completely ready to communicate. SSH session gets established, but when I want to use the transport to exec_command, I get this.
Will try the stdin.close() trick
Most helpful comment
I worked around it by closing the
stdinfile object: