1

I am having an issue with SSH on my web server. I am trying to SSH into the server, which is on the same network as the computer I am connecting from. I get the error:

ssh_exchange_identification: read: Connection reset by peer

However, when I activate a proxy software that routes my traffic through an out-of-network source, I am able to connect perfectly fine. Here is my firewall config:

# Generated by iptables-save v1.4.18 on Tue Dec 31 15:25:01 2013
*filter
:INPUT DROP [416:67311]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [11183:3738813]
:INBOUND - [0:0]
:LOG_FILTER - [0:0]
:LSI - [0:0]
:LSO - [0:0]
:OUTBOUND - [0:0]
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 21 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 20 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 20 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 443 -j ACCEPT
COMMIT
# Completed on Tue Dec 31 15:25:01 2013
# Generated by iptables-save v1.4.18 on Tue Dec 31 15:25:01 2013
*mangle
:PREROUTING ACCEPT [10663:6982022]
:INPUT ACCEPT [10636:6980454]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [11183:3738813]
:POSTROUTING ACCEPT [11192:3739401]
COMMIT
# Completed on Tue Dec 31 15:25:01 2013
# Generated by iptables-save v1.4.18 on Tue Dec 31 15:25:01 2013
*nat
:PREROUTING ACCEPT [510:72807]
:INPUT ACCEPT [76:4516]
:OUTPUT ACCEPT [1160:71212]
:POSTROUTING ACCEPT [1160:71212]
COMMIT
# Completed on Tue Dec 31 15:25:01 2013

ssh -v user@server

Anthonys-MBP-3:~ acagliano$ ssh [email protected] -v
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /Users/acagliano/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 102: Applying options for *
debug1: Connecting to a.rockinwebs.tk [108.6.142.81] port 22.
debug1: Connection established.
debug1: identity file /Users/acagliano/.ssh/id_rsa type 1
debug1: identity file /Users/acagliano/.ssh/id_rsa-cert type -1
debug1: identity file /Users/acagliano/.ssh/id_dsa type -1
debug1: identity file /Users/acagliano/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Connection reset by peer

/var/log/auth.log

Dec  4 00:57:06 acagliano-Satellite-C55-A sshd[23894]: Invalid user admin from 95.110.203.71
Dec  4 00:57:06 acagliano-Satellite-C55-A sshd[23894]: input_userauth_request: invalid user admin [preauth]
Dec  4 00:57:06 acagliano-Satellite-C55-A sshd[23894]: error: Could not get shadow information for NOUSER
Dec  4 00:57:06 acagliano-Satellite-C55-A sshd[23894]: Failed password for invalid user admin from 95.110.203.71 port 44174 ssh2

If I'm reading the logs correctly, was that an intrusion attempt? SSH isn't even running on that port..

Can anyone advise me?

5
  • Does the machine only have one interface, eth0? Also, do you have /etc/hosts.allow and /etc/hosts.deny?
    – Alaa Ali
    Dec 3, 2014 at 21:12
  • The active interface, and the only one in use is eth0. Also, I have an empty hosts.allow file and my hosts.deny file is populated by my intrusion detection software (portsentry), which has allow rules for connections from my network.
    – acagliano
    Dec 3, 2014 at 21:34
  • No, that's not an attempt on SSH on that port, that's the source port. Is this the machine you're trying to connect from, 95.110.203.71? Because the logs clearly say that you're trying to login as admin when there isn't an admin user on the machine. Try using ssh -vvv to connect and give us the output, that'll give more verbose messages.
    – Alaa Ali
    Dec 5, 2014 at 0:58
  • I never attempted to log in as admin on the machine, and that IP address is not what I'm at. The logs clearly showed me logging in as the only user allowed ssh access, and then initializing a root session within that. On another note, I succeeded in switching password authentication to public key authentication. And this issue is actually resolved. For reasons unknown to me, calling back to the server from the same network as the server using the server (and my network's) public IP causes that error. When I ssh to the server's local IP, 192.168.1.4, it works fine. So I guess it's fixed! :)
    – acagliano
    Dec 5, 2014 at 14:12
  • Oops, sorry, I didn't really look at the ssh -v output you posted. So yeah, those logs are someone trying to login as admin. But to further troubleshoot your problem, connect to your web server using ssh [email protected] -vvv, and if you can somehow get another connection to it while trying to do this, do a tail -f /var/log/auth.log on the server so you can see what's happening as you're trying to connect. If you can't, then just inspect the last few lines in auth.log after your SSH connection doesn't go through. EDIT: alright, I guess it is fixed =). Post an answer.
    – Alaa Ali
    Dec 5, 2014 at 14:20

2 Answers 2

1

Ok, with help, I solved my own problem.

First off, for reasons unknown to me, trying to ssh into a server on the same network as the client causes the "reset by peer" issue. Which is why using a proxy, or using the server's local IP (192.168.1.4) resolves the issue.

Secondly, to solve the issue of someone trying to guess my password which I seem to see evidence of in my logs, I changed to public/private key authentication, gave only myself ssh access, and reduced git to the git-shell for security. I also upgraded my iptables rules to start dropping connections to SSH after a certain number of attempts in a time period.

So this issue is resolved. Thanks all.

0

You are unlikely to have firewall issues. "Connection Reset" means that the connection has been established but then the server didn't like either its configuration or the client.

To verify whether this is the case call ssh -v user@server. If you see debug1: Connection established. then your firewall rules are just fine and you should focus on your ssh daemon instead.

Check your sshd log (most likely file /var/log/auth.log) for clues about what is going on. If there is nothing obvious and if you can edit file /etc/ssh/sshd_config set LogLevel to either VERBOSE or DEBUG, restart sshd and try again.

2
  • Would it be possible for a connection from a device on the same network as the server to create an issue that might not otherwise exist? Because this only occurs when I connect from the same network (I even tried to use the local IP, to no avail).
    – acagliano
    Dec 3, 2014 at 23:35
  • Well, we don't know for sure. Thant is why I asked you to run ssh -v user@server and to check the logs.
    – sмurf
    Dec 4, 2014 at 0:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .