0

I have an RHEL 6.8 x86_64 server that has had a long running problem with the SSH server. It has openssh-5.3p1-118.1.el6_8.x86_64 installed. Every so many attempts to connect to SSH/SFTP, the server gives back the error: 

ssh_exchange_identification: read: Connection reset by peer

It doesn't happen every time, so it is very hard to debug. When it does happen, even with more verbose logging, nothing shows up in the SSH logs about what happened. What I have noticed is that I have to restart sshd every few weeks or it quits working all together.

Can you offer any suggestions on how I could diagnose this issue and fix it?

Update (27-Aug-16): Here's the results of ssh -vvv on a failed connection:

timothys-MacBook-Pro:~ tbutler$ ssh -vvv tbutler@myserver
OpenSSH_6.9p1, LibreSSL 2.1.8
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to myserver [xx.xx.xx.xx] port 22.
debug1: Connection established.
debug1: identity file /Users/tbutler/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/tbutler/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/tbutler/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/tbutler/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/tbutler/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/tbutler/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/tbutler/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/tbutler/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9
ssh_exchange_identification: read: Connection reset by peer

I tried logging in again and received the same result. Finally on the third try, I was able to connect, which resulted in the debug information looking much the same, but then continuing with:

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
Timothy R. Butler
  • 703
  • 2
  • 11
  • 22
  • Do you only have to restart `sshd` to resolve it? I'm also wondering if there could be firewall (or fail2ban or similar) rules that may be interfering intermittently. – Julie Pelletier Aug 26 '16 at 01:45
  • Every few weeks, yes. However, it does have issues at other times that are very intermittent -- sometimes just retrying a second or third time will resolve the issue. – Timothy R. Butler Aug 26 '16 at 02:03
  • Post the whole verbose log with `-vvv` switches of failed connection. The context matters. Also server logs might help. It might be only connection rate limit enforced by the server, because of various scans/log in attempts. – Jakuje Aug 26 '16 at 08:18
  • Thanks, @Jakuje. I've posted the verbose output above. When the connection fails, I don't see any reference to it in the server log. Do you think it could be that there are that many fake login attempts? – Timothy R. Butler Aug 27 '16 at 16:13
  • 1
    Certainly yes. How many of them do you have in time frame of, lets say 1 minute? – Jakuje Aug 27 '16 at 18:39

0 Answers0