7

I am a student and I keep most of my files on my home computer. Unfortunately, i can't use ssh or scp from my laptop which I use at school because of the firewall. I was thinking about trying to use port 443 because that might be open.

My question is: I have multiple computers in my house and so I am using a router. Would it be bad if i were to port forward 443 to my computer? I'm not sure if there are any security issues related with this or if it would screw anything up when trying to use https from my other computers.

  • I never open whatever services to the outside, just a VPN to entry in my home. However I do recognize it is fairly complicated. Interesting twist, port 443 serving pages and ssh at the same time. – Rui F Ribeiro Nov 20 '16 at 8:35
  • @RuiFRibeiro - So instead of opening a service to the outside (SSH), you recommend opening a service to the outside (VPN)? – marcelm Nov 20 '16 at 10:22
  • In short a security tradeoff to a less abused service. Obviously after having a VPN, you are not limited to giving only SSH. – Rui F Ribeiro Nov 20 '16 at 10:25
  • 1
    @RuiFRibeiro VPN less abused (I assume you mean attacked) than SSH? I'm not convinced about that. And for what it's worth, I trust SSH more than typical VPN implementations... – marcelm Nov 20 '16 at 10:38
  • @RuiFRibeiro SSH isn't either. Have a look at port forwarding or sshuttle. – Sebb Nov 20 '16 at 14:05
13

It should work fine, it's not more secure than using a different port for ssh (or less secure for that matter). And no, outbound TCP sockets are not the same as inbound TCP sockets - so it should not interfere with your outbound network traffic.

  • Ok thanks for that it definitely clears stuff up a lot. I know that inbound and outbound are seperate but what if there was another incoming https request? could that ever happen? – yasgur99 Nov 20 '16 at 0:05
  • Only if you are trying to run a webserver, or if someone performs a port scan. In the webserver case, you have to decide if you want to support https on your server (or ssh). And in the port scan case, it isn't different from listening on any other port. – Elliott Frisch Nov 20 '16 at 0:07
  • okay thank you so much (I don't have the rep on here but I'd give u an up vote if I could) – yasgur99 Nov 20 '16 at 0:08
  • 1
    I've done it in the past and it worked perfectly. I remember setting up a keep alive config in the ssh client, because the school router (or proxy, I don't know) dropped inactive connections after a while. – Mauro Ciancio Nov 20 '16 at 4:43
  • @yasgur99 I upvoted for you :-) – meduz Nov 23 '16 at 21:25
5

If you are going to do this, at the minimum, please:

  1. Create a whitelist: Limit access to port 443 from only known IPs
  2. Disable Password logins and only use SSH Keys

You could open yourself up to danger otherwise. What if someone finds a security bug that allows them to automatically login when given an SSH prompt? Your whitelist will reduce that future risk.

By disabling password logins to SSH, if a bad actor on the whitelist manages to access your server, it will be much harder to bruteforce a way in.

This is good security hygiene. If you are a regular university student, the chances of attack could be low, but why take an unnecessary risk?

  • 2
    +1 for using SSH pubkey auth. If you go the whitelist route though, be sure to do it at the firewall (e.g. iptables) level, so before a connection ever reaches sshd. – marcelm Nov 20 '16 at 10:24
2

"HTTPS" is just a name for the TLS (Transport Layer Security) protocol when it is being used to secure the underlying HTTP protocol. Only the endpoints need to be concerned about the underlying protocol, so you can send whatever traffic you like once you have established the secure TLS connection, on whatever port is available, without having to worry about any intervening firewalls, hackers, foreign spies, or rogue security agencies within your own country.

"SSH" has its own protocol, so if you run ssh on port 443 there is always the possibility that a firewall or other snooping agent detects that the traffic is not HTTPS (since it deviates from TLS), and blocks it. The solution to this problem is to wrap the ssh session inside the TLS protocol, which is easily done by means of the program stunnel. On the server, let stunnel listen on port 443 and tunnel the traffic to port 22. Then on the client you need to run another instance of stunnel which listens to some local port and then tunnels the traffic to port 443 on the server.

0

No issues, I've had it on 443 for a long, long time. It's fine. Only thing is you get strange log entries from browsers trying to connect to it, but those are completely harmless.

0

It's worth mentioning that it's steel a cheating. You can use 443 or any other port you reveal, using nmap or some other tool, but the SSH connection has been prohibited on purpose. It means you could be caught easily since you are not going to make a HTTPS request, which is the protocol type the aforementioned port is usually left open for.

In general, you can trigger some monitoring doing that. It is a security violation and a subsequent packet analyze will show comprehensive information regarding this attempt. Just saying.

  • Well, they should then block the protocol (by protocol inspection), and not the port! But that might require more capable firewalls than they have. My take is that, since this is an educational institution, they have probably set a whitelist of outbound ports, which sure includes port 80 and 443 at the very least, in order to just prevent misuse (P2P apps come to mind first), not to prevent information theft. – katti Nov 25 '16 at 22:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.