Hello,
SshClient works for me fine if ssh connection is possible and it works fine if ssh connection is not possible - one may think now, that everything is fine... :-)
But there is another case: target socket exists, but clients are filtered via software rules.
It took me some while to find the source of this problem that occurred only on one of my machines:
Endless hang at SshClient.Connect() with 100% CPU for one CPU core
The target SSH server is an Alcatel A4400 PBX in which trusted hosts are managed via an Alcatel generic command/menu. Therefore I can not provide any additional technical informations on what is going on there in background.
Via this generic trusted hosts menu, different access rules can be set to the ip addresses of connecting clients - this is what the different behaviour provokes.
In case of the above described problem, SshClient gets into an endless loop at Session.NET.cs:66, which is Renci.SshNet.Session.SocketReadLine(), while receiving (or re-reading?) only zero bytes from/at this._socket.Receive(data). While this occurs, the TCP connection is in CLOSE_WAIT state.
No exception is raised anywhere - not even a catched one.
When trying to connect via putty, it says "Server unexpectedly closed the connection".
ssh client on Ubuntu is more relaxed about this:
nsk@pspc01:~$ ssh -vvv mtcl@oxe192
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /home/nsk/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to oxe192 [10.132.142.192] port 22.
debug1: connect to address 10.132.142.192 port 22: Connection timed out
ssh: connect to host oxe192 port 22: Connection timed out
I would not exclude the possibility that the server's behaviour is not correct, but SshClient should not be vulnerable to bad responses... :-)
Any proposals on how to fix this? I am not sure if it will work to catch zeroes at SocketReadLine()...
Regards,
Nicolas
SshClient works for me fine if ssh connection is possible and it works fine if ssh connection is not possible - one may think now, that everything is fine... :-)
But there is another case: target socket exists, but clients are filtered via software rules.
It took me some while to find the source of this problem that occurred only on one of my machines:
Endless hang at SshClient.Connect() with 100% CPU for one CPU core
The target SSH server is an Alcatel A4400 PBX in which trusted hosts are managed via an Alcatel generic command/menu. Therefore I can not provide any additional technical informations on what is going on there in background.
Via this generic trusted hosts menu, different access rules can be set to the ip addresses of connecting clients - this is what the different behaviour provokes.
In case of the above described problem, SshClient gets into an endless loop at Session.NET.cs:66, which is Renci.SshNet.Session.SocketReadLine(), while receiving (or re-reading?) only zero bytes from/at this._socket.Receive(data). While this occurs, the TCP connection is in CLOSE_WAIT state.
No exception is raised anywhere - not even a catched one.
When trying to connect via putty, it says "Server unexpectedly closed the connection".
ssh client on Ubuntu is more relaxed about this:
nsk@pspc01:~$ ssh -vvv mtcl@oxe192
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /home/nsk/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to oxe192 [10.132.142.192] port 22.
debug1: connect to address 10.132.142.192 port 22: Connection timed out
ssh: connect to host oxe192 port 22: Connection timed out
I would not exclude the possibility that the server's behaviour is not correct, but SshClient should not be vulnerable to bad responses... :-)
Any proposals on how to fix this? I am not sure if it will work to catch zeroes at SocketReadLine()...
Regards,
Nicolas