0

I just recently setup a VPS server for myself and I did take all the necessary precautions when I set it up. I intend to access access a website on my local machine using a command like ssh -L 8080:127.0.0.1:3000 remote-user@remote-ssh-server.

While I did take all the security precautions, I am wondering that if the remote server is somehow compromised without me knowing about it, would the intruder be able to access my local computer when I am connected to it?

Further, is the above mechanism for browsing local pages on my remote secure against eavesdropping and MIM attacks?

  • Secure against what? The question in your 2nd paragraph asks about specific risks that can be answered, but the question in 3rd paragraph is missing all of that. – user1686 Nov 16 '20 at 13:31
  • @user1686 Thanks, edited question to make it more specific. – philosopher Nov 16 '20 at 13:49
1

if the remote server is somehow compromised without me knowing about it, would the intruder be able to access my local computer when I am connected to it?

The high-level functions are not symmetric; things like shell sessions only work in one direction. The client will not respond to "shell" or "exec" channel requests coming from the server – it deliberately doesn't even have the necessary code to handle them.

However, there are requests that go in the opposite direction. If you connect with "agent forwarding" enabled, the client will allow the server to use all keys in your ssh-agent (though not retrieve the actual private key). If you connect with "X11 forwarding" enabled, the client will likewise allow the server to access your X11 window contents and possibly even spoof input. If you use Kerberos and connect with "GSSAPI delegation" enabled, the server will outright get a copy of your Kerberos credentials.

Additionally, if you still have an interactive shell connection (i.e. not using -N or ControlMaster), a process on the server can send any data to your terminal so long as it has write rights to the /dev/pts/# device. Most terminal emulators generally will ignore "risky" escape codes (such as the OSC "run command" sequence being the most problematic example), but the server can still annoy you by making the terminal window move around the screen, by rickrolling you in ANSI art, etc. Finally, although the terminal emulators should be reasonably hardened against malformed data, they have had various exploits in the past.

Further, is the above mechanism for browsing local pages on my remote secure against eavesdropping and MIM attacks?

It does protect against both passive and active attacks along the path between you and the SSH server, as all data is tunnelled inside the SSH connection and gets the same protection (encryption and integrity) as everything else that goes over SSH.

It does not protect against attackers on the server itself, as the sshd has full access to the cleartext data it receives. (If plaintext data comes in, plaintext data has to come out, for hopefully obvious reasons.) The sshd can modify your data and it can even connect you to a different destination than you asked for.

It also does not protect against attackers anywhere along the path between the SSH server and the actual forwarding destination (the server's own OS being a possible attack point). You would still need the actual forwarded connection to use HTTPS to protect it.

  • Thank you. As a follow-up, would there be a way for me to connect to my server securely so that even if the server were compromised, my client would be airtight? – philosopher Nov 16 '20 at 15:03
  • Turn off the features that were described. Use -N to avoid opening an interactive terminal channel, etc. – user1686 Nov 16 '20 at 15:15

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.