Ubuntu – SSH connection refused from specific location only


Me and my girlfriend share a Ubuntu server I set up for different stuff. Lately however, she has been experiencing a problem that has me, her, and both of our respective colleagues confounded and confused.

Whenever she's at work using her job's WiFi, she connects using PuTTy, but just gets a "Server unexpectedly closed network connection" error. She is never prompted for a password before the error. If she sets up her phone as a hotspot that she connects her laptop to, she can successfully log in. If she's at home or at my place, she can also log in using the same laptop (without hotspot). She can also log in using her phone while that phone is connected to her job's WiFi.

In the auth.log on the server, I see her connection attempt coming in, but the only post is that made is one stating

refused connect from [IP-ADDRESS] ([IP-ADDRESS])

There is no more information in that log.

Stuff we tried so far (including "I seriously doubt this will work, but why not"-attempts):

  • Delete PuTTy registry inputs to reset the session keys on her computer.
  • Delete and add her server user from scratch.
  • Run ssh-keygen -A to update the keysets, with sudo service ssh restart to update changes.
  • Try to login using just IP-address and not web address.
  • Try to login using both the form [username]@[serveraddress] as well as just [serveraddress].
  • Adding a SecureShell addon in Chrome to replace Putty (same result, though with a slightly different error:

    ssh_exchange_identification: Connection closed by remote host NaCl plugin exited with status code 255

Any other ideas to what might be going on here?


The contents of /etc/ssh/sshd_config, and the output if iptables -L was requested:

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

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

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

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

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

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

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

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# 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 yes

Also; the outout of iptables -L:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination


I can't be sure of course, but I do not think that it is very likely that her job blocks outbound traffic on port 22 for a couple of reasons:

  1. It worked fine up until a few days ago.
  2. She works for an organisation that is basically a research institute that researches IT. Most of the people there use Linux almost religiously, and I believe a large majority of the people there would be quite angry if they could not use SSH connections.
  3. The head of IT there, who has a doctorate in informatics, had a 5 minute look at the problem and was also stumped. I think he of all people there should know if it was company policy to block port 22.
  4. My server does register an inbound connection request, and actively refuses it. If port 22 was blocked, would this not result in there not being any updates in auth.log at all?

Best Answer

refused connect from [IP-ADDRESS] ([IP-ADDRESS])

This particular message is emitted by the TCP wrappers library when it decides to reject a connection. Ubuntu's sshd is built to use TCP wrappers.

Check the two files "/etc/hosts.allow" and "/etc/hosts.deny" on the ssh server. You have an entry in one of those files which causes ssh connections from that address to be rejected. See the Ubuntu man page for these files.

Related Question