ssh_exchange_identification: read: Connection reset by peer

Question

I've got an odd and urgent problem. I'm trying to connect to a vendor's ftp site. I have tried connecting from multiple places. I've found that I cannot connect from my production server1 but I can connect from my testserver1 which are both housed in the same datacenter. I can also connect from the backup server located in another datacenter. I cannot connect from my office computer, but I can connect from my home computer. Up until about 2 days ago, I was able to connect on all of these boxes.

sftp -v username@host

Connecting to host...
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to host [**.**.**.**] port 22.
debug1: Connection established.
debug1: identity file /home/***/.ssh/id_rsa type -1
debug1: identity file /home/***/.ssh/id_dsa type -1
debug1: loaded 2 keys
ssh_exchange_identification: read: Connection reset by peer
Couldn't read packet: Connection reset by peer

I'm able to successfully ping the host from all boxes. I've run traceroutes for all of them as well and it doesn't appear to be cutting off anywhere. I've been on the phone with the vendors network admin and she says that despite it saying connection established on my end, she doesn't see me connecting anywhere in the logs.

I've tried browsing some other similar questions but I'm not having any luck. If anyone can point me in the right direction or shed any light on the situation it would be greatly appreciated. I've tried turning off the firewall on my office machine and still no luck. We're not using keys so I'm not sure why they are loading. Where it is being reset is where it prompts me for my password on the machines where it works.

I'm also more than happy to call the vendor's customer service if it's something on their end.

Update adding -vvv gave me the line: debug2: ssh_connect: needpriv 0 between the applying options and connecting to host lines.

Solution

In this case, we were able to get in touch with the vendor we were trying to connect to and their ISP. Their ISP watched and indeed they were, for whatever reason, closing our connection immediately.

Comments

[daemonofchaos]

Are there any entries in your /var/log/auth.log that might indicate what the potential problem is? Have you verified that your IP is not listed in iptables or perhaps hosts.deny?

[voretaq7]

Try more -vs and see if you get better debugging info? (-vvv is usually a good level for debugging funky problems)

[PigSpider]

@voretaq7 I tried -vvv but I didn't get any more information.

[Tyler K]

Yes, those log files are all contained on the host.

[Tyler K]

From the error message, you're failing to authenticate. Also, you are may want to test if they're now blocking port 20, since you initiate the connection on port 22, then swap to 20 for authentication (or at least this is what I remember).

[lsd]

It will also not read the keys if the perms on the home directory are more permissive than 700.