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?

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:

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?

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.

It's likely that what's ending up happening is that the network administrator for their work network is blocking TCP port 22 outbound, and UDP port 22 outbound, to block SSH access. This is done for a security concern of data being 'uploaded' from the internal network to a server that is not controlled by the organization. This is also done as a matter of workplace policy.

As an IT security professional, it is my duty to NOT provide answers which would compromise the shared server's security or the workplace's security, but i'm giving you three options here and identifying which ones I recommend in the sections below. One violates policy of the workplace for the girlfriend likely, and also detracts from your server's security, the other two are potential other options.

Option 1: Try and run a web-facing shell client, or set sshd to use port 80.

NOT RECOMMENDED

The only solution in this case is to run a web-facing shell client of some sort, but you'll likely need a web server. The other solution, proposed by Nitin J Mutkawoa of putting your SSH server to port 80 is another option. Both of these options open you to several security risks, including but not limited to:

• Putting SSH on a HTTP port means that MANY servers may try and access a web page on the IP address but will instead hit an SSH connection, which will be a security risk as service scanners see that.
• Putting what should be considered a 'secure' service on a web port will open you to web-based attacks against the port
• Putting SSH on the web facing system will open you to a lot of bruteforce attack vectors.
• Putting a web-facing web based shell client will open you to bruteforce attempts as well
• Putting a web-facing web based shell client up will open you to attack vectors from whatever the 'client' is written in (Java, PHP, etc.) which may include but is not limited to:
  • Remote Code Execution vulnerabilities
  • Privilege Escalation vulnerabilities
  • Denial of Service vulnerabilities.

This also opens your girlfriend to policy violations in the workplace by doing something which workplace policy has set to deny. She could face disciplinary action up to and including getting fired. For this reason as well as the security reasons above you should not implement this option.

Option 2: Don't try and circumvent workplace IT policy

RECOMMENDED

As an IT security professional myself, who has had to terminate network access due to policy violations of other individuals at a workplace in the past, my recommendation is that your girlfriend does not try and SSH to your shared server from a work environment/network. If there are any types of auditing being done on the network, then the network audits may show that someone is attempting to SSH to an unsecure, unvetted server. While you or your girlfriend may individually not have any malicious intent, most workplace "Network/Computer Acceptable Use Policies" will include that you will not be doing personal items on the network without authorization or absolute necessity. Another thing is likely to state "You shall not use certain services such as: [list]".

I would recommend that you review the acceptable use policy for the girlfriend's workplace, and determine whether she would be violating this policy, enough so that she could be facing disciplinary action, such as removal of network access, removal of computer access, or potential dismissal. Do not try and circumvent the policy because your girlfriend could be fired by circumventing it.

Option 3: If the SSH is needed for work-related tasks, contact supervisors/management to see if restriction exemptions can be given to the girlfriend.

ALSO RECOMMENDED

If the access to your shared SSH server is a requirement for the workplace, then your girlfriend needs to talk to her supervisor to determine whether there is a violation of policy by allowing access as such. It would then have to be discussed by management whether or not they can give access, and then from there determines whether it's safe/sane or not to allow the access through the network.

This is likely the second safest option