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?
EDIT:
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 ::
#ListenAddress 0.0.0.0
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
EDIT2:
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:
- It worked fine up until a few days ago.
- 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.
- 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.
- 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?
-v
. Opencmd.exe
, or use Run, to runputty.exe
with-v
. See the.earth.li/~sgtatham/putty/0.64/htmldoc/…sshd_config
andiptables
. I agree with muru to try to gather verbose logs of the client and the server side. Stop thessh
service and runsudo /usr/sbin/sshd -d
in a terminal. It would be interesting to see, whether both sides think, the other closed the connection (which would mean a man in the middle is responsible).