SSH connection refused from specific location only
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