In a nutshell: How secure are SSH clients? Can servers mess with them?

I saw this Ghost in the Shell bash remake today. Funny enough and there are a few movies (The Matrix, Star Wars, etc) that are delivered over SSH. There are also games that rely on you connecting over SSH.

But it occurred to me today that when we talk about SSH security, we're really focussing on the server; the transport security and authentication mechanisms, stopping brute force attacks and random remote exploits. What about the client? My client is running as me, it can do a lot of damage to a lot of local files... It certainly doesn't need root to hurt me.

What can an SSH server do that we might not expect? Is my client broadcasting data about me? Is there an exploit vector like a web browser?

  • a vulnerability might come from the ssh client as any other software could have on your machine, in this case the server could harm using an undisclosed exploit for the given vulnerability
    – elsadek
    Commented Apr 24, 2017 at 10:36
  • 1
    There have been several server -> client vulns in Putty; see the list: cvedetails.com/vulnerability-list/vendor_id-12807/…
    – paj28
    Commented Apr 24, 2017 at 11:03
  • ANSI/Terminal Control sequences are also a possible risk to consider. If a local terminal is involved it should not suffer from escapes which can read out content, redefine keys, write files, rename Windows and similar.
    – eckes
    Commented Mar 7, 2018 at 8:09

3 Answers 3


2 options come to mind:

  1. vulnerabilities in the SSH client
  2. "hack back"

I run SSH honeypots, and a colleague wrote a script to take the password that the attacker used to create or change an account on the honeypot and use it to connect back to the attacker's SSH and enumerate the home directory. He has a 10% success rate...

This might be a corner case, but it highlights that once you make a connection to another computer, all bets are off. They know about you, your IP, and can use any information you provide against you.

  • I'm not sure if I'm understanding this right, but does this rely on the attacker also running an ssh server for you to connect back to?
    – user942937
    Commented Sep 23, 2020 at 5:23
  • Yes, the attackers were running ssh servers on their attacking machines.
    – schroeder
    Commented Sep 23, 2020 at 6:36

First, obviously, if there's a bug in the SSH client, it might allow the server to execute code there. A really bad bug could even allow a man-in-the-middle to exploit the client. The rest of the attack surface consists of where SSH sends data that it receives from the server.

The text received through the SSH connection is, in your case, sent to a terminal. Terminals parse escape sequences — that's how they display colors, move the cursor, etc. There can be bugs in the escape sequence parser. Additionally, some escape sequences may request things that go beyond affecting the display, such as changing the terminal's title, resizing the window, or injecting input data (e.g. a command to query the cursor position or the window title). Modern terminals disable the truly dangerous commands (the ones that cause injected input that can be arbitrary text set through another escape sequence). For more on this topic, see Can "cat-ing" a file be a potential security risk?, How can I protect myself from this kind of clipboard abuse?, and How to avoid escape sequence attacks in terminals?. The solution is to verify that your terminal doesn't allow dangerous sequences. For added safety, instead of opening a terminal where you run a shell where you run ssh, run ssh directly in the terminal, and disable any keyboard handling it may have (EscapeChar none in the OpenSSH client configuration); this way, even if a malicious server manages to inject input, there's no risk that it would be executed as a shell command on your machine.

SSH can also forward network connections, allowing the server to reach the client besides the terminal. This can bypass a firewall restriction. Two common forwarded network connections carry risks of their own. X11 forwarding gives the server access to your local X server; this is pretty much equivalent to giving shell access to the server as it allows things like injecting input in other applications (a useful feature for things like macro recorders and window manager-based input remapping, but lacking proper firewalling). SSH agent forwarding lets the server use your private keys to potentially log in elsewhere. So when you connect to untrusted server, make sure that you don't activate any forwarding. Turn on forwarding selectively for known servers.

Additionally there is a privacy exposure if you send a default username or a public key offer.


Just an addition to @schroeder's answer.

A SSH session is generally not off ground but is started from a terminal application. Ordinarily, terminal applications do not expect random bytes and can have weird behaviour when they receive control characters. Most use them to control their own appearance. Never researched that, but there could be vulnerabilities in the terminal application. Anyway simply having the terminal writing some lines with same foreground color and background color could lead to interesting results if the user often do cut and paste in terminal windows.

Not the answer you're looking for? Browse other questions tagged .