FAQ: Connection failure - 0 bytes received

[jdev]

In SecureCRT, SecureFX, or SFXCL, if an SSH/SFTP connection attempt fails, it may be that the network connections from your app/computer are being blocked from successfully making outgoing connections. This could be caused by a misconfigured firewall (either hardware or software), a switch, router or some other device between you and the server that is not allowing the connection to go through to the remote server or not relaying back its response. It might also be caused by an application installed on your system that restricts/controls an application's ability to even make outgoing network connections -- in which case an exception may need to be added in order for SecureCRT, SecureFX, or SFXCL to successfully make an outgoing network connection.

This article addresses two common scenarios you might see in a SecureFX/SFXCL log, or in SecureCRT with Trace Options debug output enabled (File > Trace Options).

Connected for s seconds, 0 bytes sent, 0 bytes received
In this situation, SecureCRT/SecureFX/SFXCL has asked the operating system to make a TCP connection to the specified host/address. The connection was not established, so no data (bytes) could be sent and no data could be received. This is usually caused by one of these scenarios, all of which are outside SecureCRT's/SecureFX's/SFXCL's ability to fix/resolve:

• SecureCRT/SecureFX/SFXCL is being blocked by local application monitoring and control software that is preventing SecureCRT/SecureFX/SFXCL from making outgoing network connections on this machine.
  Address the situation by adding an exception to the monitoring and control software to allow SecureCRT/SecureFX/SFXCL to successfully make outgoing network connections.
  
  
• SecureCRT/SecureFX/SFXCL is on a machine that has a hardware/software firewall or proxy that is not allowing the machine to make outgoing connections.
  Address the situation by properly configuring the hardware/software firewall/proxy to allow for outgoing connections.
  
  
• The remote server to which you're trying to connect may not accept connections from your machine. SecureCRT/SecureFX/SFXCL cannot force the remote machine to accept its connection request.
  Address the situation by checking with the admin of the remote machine to make sure there are no connection filters in place to prevent successful connection.
  
  
• The remote server to which you're trying to connect may not be listening on the configured address/port. If the remote machine is not configured to listen on the standard protocol port 22 for SFTP/SSH, you will need to configure SecureCRT/SecureFX/SFXCL to connect to the address+port indicated by the administrator of the remote machine's SSH2/SFTP server.
  Address the situation by checking with the admin of the remote machine to verify the listening address+port.
  
  
• There may not be any network connectivity between your machine and the remote machine. SecureCRT/SecureFX/SFXCL cannot connect if there is not a network route between your machine and the remote machine.
  Address the situation by verifying network connectivity between your machine and the remote SSH/SFTP server.

Connected for s seconds, n bytes sent, 0 bytes received
In this situation, SecureCRT/SecureFX/SFXCL was able to get successfully connected to at least send some initial data over the established connection. Typically, the number of bytes sent is equal to the SSH2 ident string that the product sends as the initial protocol handshake to begin setting up the SSH connection with the remote SSH2/SFTP server. For example, a 64-bit SecureCRT 8.5.1 sends the following ident string for negotiating the SSH2 protocol with a server:

SSH-2.0-SecureCRT_8.5.1 (x64 build 1764)
123456789 123456789 123456789 123456789 123456789 123456789

For the 64-bit version of SecureCRT, the ident string would be exactly 40 characters long. Add on the trailing CR and LF characters and you end up with 42 bytes sent for the ident string. For SecureFX/SFXCL, the ident string isn't as long, so you would end up with fewer characters/bytes being sent, but the general idea is the same.

This scenario where a non-zero amount of bytes are sent, but 0 bytes are received is caused when the remote server -- or any networking firewall/proxy in between the client and the server -- accepts the connection, but when SecureCRT/SecureFX/SFXCL sent its ident string the connection was then immediately closed, or timed out later without SecureCRT/SecureFX/SFXCL receiving any bytes back from the connected peer.

Possible causes include:

• The remote server disconnected due to a configuration on the server not allowing the connection to continue.
  Check with your SSH/SFTP server administrator to determine why the server closed the connection.
  
  
• A firewall/switch/router/networking-device somewhere along the network route between SecureCRT/SecureFX/SFXCL's machine and the remote SSH/SFTP server terminated the connection before any data could be returned from the server to SecureCRT/SecureFX/SFXCL. When SecureCRT/SecureFX/SFXCL receives notification from the operating system that a network connection has closed, there is no recourse for SecureCRT/SecureFX/SFXCL to protest nor petition for the connection to remain open; it's closed and SecureCRT/SecureFX/SFXCL can do nothing about it.
  Troubleshoot this issue by inspecting logs of the remote SSH/SFTP server, and every network device in between SecureCRT/SecureFX/SFXCL and the remote SSH/SFTP server.