I have a WinXP box (called PETER) with Cygwin installed. This is its version:

C:\bin> uname -a
CYGWIN_NT-5.1 peter 1.7.24(0.269/5/3) 2013-08-15 11:55 i686 Cygwin

I have installed SSHD on it for years and everything worked well. Recently I have changed the router from Speedport 722V to Speedport 921V (I needed IPv6). I have properly set port forwarding rules and they seem to work.

Now I have this strange effect:

  • users from the Internet can connect;
  • I can connect via SSH to my Uni, from there connect to PETER;
  • I can connect to PETER to its local IP address;
  • but I can not connect to it by using the public IP address (which is delivered by dyndns.com) or the DNS name.

I have checked that the IP address is correct. It doesn't work for both the DNS name and the numerical IPv4 address. Port forwarding works: Internet users can connect and as the log file shows, I can connect, but my connection is reset, i.e. actively terminated.

This is the SSH output when I try it:

C:\> ssh -vvvv
OpenSSH_6.2p2, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 61: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to [] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/cygdrive/c/text/id_rsa" as a RSA1 public key
debug1: identity file /cygdrive/c/text/id_rsa type 1
debug1: identity file /cygdrive/c/text/id_rsa-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

I only get this eventvwr output: ... sshd: PID 720: Comparing to (p4FDF19DA.dip0.t-ipconnect.de:p4FDF19DA.dip0.t-ipconnect.de).

This is my sshd_config:

Port 22
AddressFamily inet
#ListenAddress ::

# The default requires explicit activation of protocol 1
#Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh_host_rsa_key
#HostKey /etc/ssh_host_dsa_key
#HostKey /etc/ssh_host_ecdsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
StrictModes no
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
PermitEmptyPasswords no

# Change to no to disable s/key passwords
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing, 
# and session processing. If this is enabled, PAM authentication will 
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM no

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
UsePrivilegeSeparation yes
#PermitUserEnvironment no
Compression yes

# after 3*2min of no answer from the client, terminate the connection
# so after a hibernation etc. the connection will most likely be dead.
ClientAliveInterval 2m
ClientAliveCountMax 3

#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem   sftp    /usr/sbin/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#   X11Forwarding no
#   AllowTcpForwarding no
#   ForceCommand cvs server

To make things more obscure, I "fixed" this problem the other day by modifying the /etc/hosts.allow file, but this "fix" doesn't work any more. It was not needed anyhow for the last years, so I'm all the more confused. The other day I was under the impression that the router might reverse-resolve the IP number to a name, something the old router maybe did differently than the new one??

Does anyone have any idea? I'm clueless, but I don't really understand all of the workings (e.g. the /etc/hosts.allow and .deny files are new to me).

More info: It doesn't work even with empty hosts.allowand .denyfiles. SSHD DEBUG3 logging doesn't show any reason for disconnect. Right now, I think it's a hardware problem with the router...

  • Did you set up the same port forwarding in the new router? Do other services work fine?
    – golimar
    Sep 3 '13 at 15:53
  • There are no other services, but I can connect from the outside, so port forwarding must be working OK.
    – cxxl
    Sep 3 '13 at 15:57
  • Do I get your setup right: PETER - SPEEDPORT - INTERNET - UNI? Where do ,,users from the internet'' can connect to -- to the cygwin sshd? You ssh'd into UNI only for testing purposes, to check if you can connect to PETER from the ,,outside''?!
    – mpy
    Sep 4 '13 at 15:56
  • "Users from the Internet" is anyone connected to the Internet and to check that, I connect to Uni and test from there. The "normal" user would just connect from his workplace on the Internet (no Uni).
    – cxxl
    Sep 4 '13 at 16:34
  • have you figured out why?
    – trogper
    Oct 20 '14 at 21:46

The reason for the reset of the TCP connection was an "improvement" in my new router. What I'm trying to do is called "NAT loopback", see WP, and the manufacturers of my router seem to share the (in my understanding faulty) opinion that NAT loopback is a security issue. I don't see how it could be, but there it is: my router actively prohibits such connections.

My solution is a hack, where I have a script run before using SSH. Said script checks if I'm in the office and if so, replaces the DNS address of my server with its local address. Stupid, but I see no other way.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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