How to overcome blocked SSH attempt

Question

I am trying to SSH to a remote university machine from a library, but I get the error message:

ssh: connect to host remote.machine.edu port 22: Connection refused

I have previously posted about this, and I have also spoken to the network administrator to try to change the port.

The system administrator said:

I have it listening on port 2222, but it looks like that's being blocked further upstream.

He said he would try to think of a way around it, but it doesn't seem like we have a solution currently.

It was suggested to me to SSH over port 443. Is there a reason that 443 would work if 22 or 2222 didn't?

Any other solutions would also be appreciated.

(The machine is not down).

---

To clarify:

• When I SSH to the remote machine everywhere except the library, using the default port (which I guess is 22 from the library error message) it works fine.

• I'm not sure why the system administrator said he had it listening on port 2222. I assumed that meant that he was trying something different from the 22 that was failing from the library. (Because if it was always 2222, I would NEVER be able to ssh). Either way, he said that it looks like that's being blocked further upstream.

• Should I ask him to try to listen on port 443?

• Is there some different way I can get around the problem?

Answer 1

Your system administrator looks a bit confused. My guess is that he has forwarded the public port 22 to local port 2222 on the computer where the SSH server is located, but this has no relation to the problem.

If you can SSH from anywhere except the library, then the problem is with the library. If you are using the library computers or network server, their firewall must be blocking SSH. The library could be using paid software or private data that they wouldn't want to be copied elsewhere.

One solution is not to use the library network. If you have some other network or computer that you can use from the library.

Otherwise, using a port that is never blocked by the firewall, such as 443 which is used for HTTPS, will let you bypass the restriction. But this needs cooperation from the university system administrator.

In particular, the system administrator will have to forward public port 443 on the university router to local port 22 (or 2222?) on the SSH server.

His ability to do so depends on whether the same router is also accepting HTTPS URL queries for the same public IP address. Meaning that the same computer is housing both an SSH server and a Web server.

If this is the case, then port 443 is already taken. The same one port cannot be used for two purposes by two servers. You would need in that case to also contact the network administrator of the library and try to find another port that is not blocked. Then you will need to convince the university administrator to open that port in his firewall and forward it to port 22 (2222?) on the SSH server.

This is becoming complicated. It might be simpler to copy the files to your laptop or USB key and SSH them from outside the library, if the problem is passing files. Again, this would only be possible if the library has not installed any safeguards to block such actions in order to protect its proprietary data.

If you need SSH for other purposes than passing files, and have no other solution than using the library computers or network, you will need to contact the library firewall administrator for a solution.

Answer 2

It seems that the library blocks traffic on port 22 (SSH). Probably port 443 (HTTPS) is not blocked, since otherwise users of the library network would not be able to surf the web in a secure manner. If this assumption is true, the easiest solution would be to change the SSH server's listing port to 443.

If this is not possible (e.g. because a webserver is running in parallel to the SSH server and already listening on port 443) you could leverage another SSH server which listens on port 443 as an intermediate hop, like described here

Whichever solution you choose, all circumvent a regulation put in place by the library's network operators. Therefore and to avoid trouble, I suggest you consult the libraries terms of use first.