Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This question already has an answer here:

I have been able to log on to my dev box (which is in my home network) for a while now, using ssh username@publicip however recently this has become impossible due to the following error

ssh_exchange_identification: read: Connection reset by peer

Whats strange is, if i use the network address instead of the public address I am able to connect with no issues.

My colleague is also able to SSH to the public ip address with no issues as well.

What could be the cause of this and how can I solve it? I did a quick google which suggested I look in my etc/hosts.deny file, however I don't have one.


share|improve this question

marked as duplicate by Dennis Kaarsemaker, Jenny D, kasperd, Tom O'Connor Aug 14 '14 at 21:08

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

By "public address" and "network address" you mean that you're using the external facing IP address vs. the internal facing IP address? – mgjk Aug 14 '14 at 12:32
up vote 1 down vote accepted

If you're using rsa key authentication, you might want to make sure the authorized_keys file hasn't been recently modified on the dev server.

If all else fails, you can run sshd in debug mode sshd -d and then ssh connect from your client terminal. This will print out a lot of information. Search for errors/failures in the output.

To do this:

  1. sudo service sshd stop # don't worry, your active ssh connections will not be terminated, only new connections will be affected.
  2. /usr/sbin/sshd -d ... puts out debug info...

  3. from the client terminal (your workstation), connect to the dev server via ssh using the -v option (verbose): ssh -v

  4. read through the debug info on the sshd -d output and the ssh client verbose output

  5. -- fix issue --

  6. Ctrl-C to exit the sshd -d" to exit debug.
  7. sudo service sshd start # restart sshd daemon
share|improve this answer
If you're using rsa key authentication, you might want to make sure the authorized_keys file hasn't been recently modified on the dev server. - this is exactly what had happened. thanks – Biscuit128 Aug 14 '14 at 12:59
How would a change to authorized_keys cause a connection reset? As far as service sshd stop, it is true that you can usually run that without affecting established connections, however I have seen systems where running that command twice will kill all established ssh connections. – kasperd Aug 14 '14 at 15:00
I've seen this before where someone used Putty to generate keys and did a copy-n-paste to the UNIX/LINUX system with line breaks. This corrupted the authorized_keys file and gave the connection reset by peer error. I would agree that you need to use extreme caution when stopping sshd as to not lock yourself (or others) out. As a rule, NEVER CLOSE ACTIVE SESSIONS while sshd has been stopped. You may not be able to get back in. If you have cpanel (or similar), you can restart the service of http. – Satalink Aug 14 '14 at 15:08

Can you test a ping to your host? It could be resolving incorrectly. If this is the case, you may want to check the TTL on the DNS, or to manually resolve it set the following line in your /etc/hosts where your IP address is x.x.x.x and your host is

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.