I was switching a frontend to use SSH instead of HTTP for the backend, and then it hit me. HTTP is stateless, so I can send requests to a server which I don’t trust. But how about SSH? Isn’t SSH a two side channel communication?

Example: Server A executes commands on Server B with SSH. Opens, executes and closes the session.

How safe is this for Server A in case Server B gets compromised? Could an attacker potentially use this connection to log back into Server A, executes commands or pull data on the channel?

To resume is it safe for the end client to SSH into non-trusted servers?

  • 2
    As Server A executes a file on Server B with HTTP, there is nothing Server B can do except respond, as there is no session except the initial TCP connection and the HTTP. That is what I mean by Stateless. With SSH on the other part, you are establishing a connection to that machine and keeping it open until you close the session between both parties. I read others posts here, and it seems its safe as long as X forwarding is not enabled as there is no way for the server B to initiate a shell connection back to the client on server A – nibb11 Feb 3 '18 at 11:27
  • 1
    With HTTP you often keep the connection open to for following requests (HTTP keep-alive). The "stateless" part of HTTP commonly refers to the fact, that each request is independent from each other (i.e. no implicit shared state due to using the same underlying TCP connection) and that any kind of shared state between requests need to be explicitly handled (for example using cookies). Anyway - this is nothing to do on how much one can trust the peer : for example the server can send malware back to the client within HTTP. – Steffen Ullrich Feb 3 '18 at 12:09
  • You are correct Steffen, I used the stateless expression incorrectly here. – nibb11 Feb 3 '18 at 12:47
  • Make sure to turn off X11,Port or Agent forwarding and have a up-to-date ssh Client – eckes Mar 6 '18 at 20:12

It should be as safe as HTTPS, meaning that a malicious server would need to be able to exploit some vulnerability in the client in order to abuse the connection -- which is true for both HTTPS and SSH protocols.

However, you should make sure that you don't forward your ssh-agent to servers you don't trust. A good way to ensure that is to set the following in your .ssh/config:

ClearAllForwardings yes
  • Thanks. I'doing this from a script. So instead of using something like cURL to execute a remote script on a web server (I control the web server of course), I would SSH from the script and run it directly on the command line on the other side. From a security standpoint, the web server is secure with valid certs + IP restricted+auth+token to only respond to the frontend. But it seems so much easier to avoid all this and just SSH from the frontend script and execute the backend script directly which makes me wonder why not more people use this instead of using HTTP. – nibb11 Feb 3 '18 at 20:56
  • The reason people don't do it is likely because it is much easier to do arbitrary remote command execution using SSH. Also, many servers don't expose SSH on a public port (SSH only accessible inside a management VPN). When you build your service in HTTPS, your own code enforce exactly what commands to execute. Additionally, SSH supports doing things like opening forwarding ports on both sides, which increases its attack surface. – Lie Ryan Feb 4 '18 at 22:45
  • You can limit the allowed commands to the SSH user account which would prevent from executing other commands. Since I'm referring to frontend <> backend connections, whatever applies to firewall, VPN and restricted ports in a private network applies to HTTPS as well. You would not open HTTPS connections to the public just like you would not do it with SSH either. It would only be for the frontend communications, securing HTTPS that way requires even more effort as web servers are usually designed for public use. – nibb11 Feb 5 '18 at 17:04

Ssh is designed to be used without needing to trust the server.

However, as with all software, this does not always hold. CVE-2016-0777 and its associated vulnerabilities allowed a malicious server to read a client's private key, which allows them to then impersonate that client to any other server. Here's more information on it:

This was considered a major vulnerability. For most people's threat models, you can assume there isn't another known vulnerability of this type and you can connect safely to unverified servers. But you'll have to make that decision yourself depending on your situation.

  • "Ssh is designed to be used without needing to trust the server" that is my impression as well. All software has bugs, and those bugs can be security issues but do you have any particular reference to that phrase? If SSH was not secure regarding connecting to a compromised server. Then system admins or security researchers would not connect with SSH to a compromised system ever. I guess SSH is as safe as anything else when it comes to the party that initiates the connection (client). – nibb11 Feb 5 '18 at 17:00
  • It's implied by the fact that they patched this and treated it as a serious vulnerability that you should expect your client to be safe when connecting to any server. But I have read more explicit statements before, just having trouble finding them now. – Xiong Chiamiov Feb 5 '18 at 19:49

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