[raggi]

Yes.

Do not connect with agent forwarding, as doing so would allow the server operator to connect to other locations as you. Do not forward environment information, though the typical ssh default is not to. You will likely leak your username. If you connect from an internet reachable host, and you made the mistake of not doing the first item in this list, they could easily connect back to you, not requiring any zero days. Other probably lower ROI attacks might include forcing you down to using extremely poor protocol versions or crypto options, resulting in potential information exposure if you remained online long enough to push a relevant sample of traffic. I would pin the client to a very tight set of allowed protocols and cipher suites.

Your terminal emulator program should ideally be sandboxed, iTerm, xterm, rxvt, etc have had bugs found and most aren't regularly fuzzed.

Similarly, having been in the ssh code base plenty, I'm not really sure I would wholly trust the standard openssh(1) client post-auth against a malicious server. It's highly macro-conditioned C with subtle semantics and invariants spread all over the place, extremely large functions, in-line parsing and in-house crypto. It does some things well, like trying to clear keys from memory early, but it's not written in a safe language, nor is it written in a safe way. As far as I know, the client is not fuzzed (though I'd be happy to find out I'm wrong). It also, depending on configuration calls out to other libraries with unfortunate history, zlib in particular, which while there hasn't been a known recent issue, there have been serious issues in the past. Depending on how it was sourced, there may be other issues too. If you look in the OpenBSD repository for example, you'll find the libz it is linking is from zlib 1.2.3, so a good 10 years older than the last relatively serious zlib exploit, which is about 5 years old. The zlib changelog in OpenBSD does not seem to include the patch for CVE-2016-9841. This doesn't prove anything that significant, only points out the reality that this stuff doesn't get as many eyeballs as it really should. I just went diving for 10 minutes and this is what I found. In case you're wondering, the function in question is called from inflate, which is called from ssh_packet_read_poll2 (one of the aforementioned extremely long and macro-configured ssh functions), and is called in both the server and client dispatch code.

Using a modern web browser is a much safer way to go about this, in the end.

[shakna]

> As far as I know, the client is not fuzzed (though I'd be happy to find out I'm wrong).

Just touching on this one part, the rest still applies, openssh does use fuzzing. [0][1] Both client and daemon are fuzzed using AFL, though it does seem to be on an ad-hoc basis rather than automated, but it generally happens before a new release.

Unfortunately, to run AFL on openssh, they do have to patch it a bit, so what gets fuzzed and what is released isn't 1-to-1. This is because the privilege separations tend to defeat methods of detecting most of those sorts of bugs on their own.

[0] https://github.com/djmdjm/openssh-fuzz-cases

[1] For example: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ke...

[raggi]

This is pleasing to hear :)

[CuriousCosmic]

Note that they could only log back into your machine if you use the same credentials to between machines.

This is one of the arguments for generating a unique SSH key on each machine you use. It makes it far harder to break in if you mess up somewhere along the way.

[vbsteven]

Not necessarily. If you have multiple keys active in local your SSH Agent, then connect to a malicious host with Agent Forwarding enabled, the malicious host could try to connect to to a third host and I believe it will try to use all active keys from the local agent.

[CuriousCosmic]

Personally my approach is to use a unique GPG Authentication key per machine with gpg-agent. They can't log back into the current machine and unless it's a targetted attack they shouldn't have any knowledge of my other machines.

Of course there's a list of common services that you could probably try and they could gain access there like say push/pull on github/gitlab however as long as those common services have another layer of protection (i.e. mandatory commit signing) it should limit the effective attack area pretty effectively.

I also generally find that ssh connections will be one way (i.e. you typically only set up SSH authentication to flow in a specific direction). As long as your SSH authentication graph is directed and acyclic (i.e. no loops and connections only go in one direction), there is little ability for a malicious server to access other nodes in the SSH auth graph provided you connect from a leaf or near leaf node.

I don't use agent forwarding because of the issues with it but there are definitely ways to reduce the attack area that it provides.

[hutrdvnj]

Would it increase security if I ssh from a docker container?

[airhead969]

Docker containers aren't provably secure. If you want isolation, use a VM that doesn't have host file system access. This way, if the VM is compromised, just throw it away and it can't leak out the way containers do.

[px43]

> Docker containers aren't provably secure.

Not only are they not provably secure (very few things are), they are explicitly not intended for use as a security boundary. Their whole gimmick is lightweight containers you can use instead of VMs if you trust everyone who's going to run code under them.

[airhead969]

To disambiguate: I don't mean formal verification like seL4, I mean it hasn't been thoroughly audited to show it is reasonably secure. Docker security of images and running containers is pretty shit as I brought up on GH in the beginning. Developers just shrugged it off and focused on whiz-bang features.

The conflation of what amounts to fancy Linux cgroups trickery with hypervisors is a depressing misunderstanding of isolation.

[justinjlynn]

Thanks for the excellent summary and explanation. I knew the answer was that it wasn't safe - but the detail here is remarkable. :)

[thrwaeasddsaf]

> rxvt, etc have had bugs found and most aren't regularly fuzzed.

Recent example: https://www.openwall.com/lists/oss-security/2021/05/17/1

[theteapot]

> Do not connect with agent forwarding, as doing so would allow the server operator to connect to other locations as you.

Just having enabled is enough?! Pretty sure you'd need to forward one or more identities too.

[jesusjosephsson]

> Do not connect with agent forwarding

This requires an explicit argument, right?

[vbsteven]

It's not enabled by default, but unfortunately I've seen many SSH config related articles that advocate some scary stuff like setting ForwardAgent yes for Host * combined with ssh-add <every-key> in .zshrc/.bashrc

[jcpham2]

whoa whao whao wait just a sec