[davidfiala]

We don't know. We won't know the negative case, but we may someday in some circumstance find out the positive (bugged) case.

But we do know some sane things:

- The stakes couldn't be higher.

- Good: Don't allow inbound SSH connections, even through a fancy $100k firewall.

- Best: Don't let people login with SSH (treat SSH like we treat the serial port: a debugging option of last resort)

[yjftsjthsd-h]

> We don't know. We won't know the negative case, but we may someday in some circumstance find out the positive (bugged) case.

But that's either the same with any tool regardless of whether it's commercially supported / FOSS / made by anonymous devs or not. If anything, FOSS is easier to audit.

[aflukasz]

Re "good"/"best": you are thinking about air gapping, then? Pull based systems are susceptible as any other software.

[davidfiala]

tldr; purpose built tools

SSH is kind of a swiss army knife. But 1000x sharper ;) The delta I'm speaking of would be to have bespoke tooling for different needs. And the tooling for each purpose could have appropriate, structured logging and access controls.

With SSH you can do almost anything. But you can imagine a better tool might exist for specific high-value activities.

Case study:

Today: engineering team monitors production errors that might contain sensitive user data with SSH access and running `tail -f /var/log/apache...`.

Better: Think of how your favorite cloud provider has a dedicated log viewing tool with filtering, paging, access control, and even logs of what you looked at all built in. No SSH. Better UX. And even better security, since you know who looked at what.

---

There are times when terminal access is needed though. SSH kinda fits that use case, but lacks a lot. Including: true audit logging, permissioned access to servers, maybe even restricting some users to a rigid set of pre-ordained commands they are allowed to run. In that cases, a better built tool can allow you to still run commands, but have a great audit log, not require direct network access (mediated access) to servers or internal networks directly, flexible ACLs, and so on.

[quesera]

I find it useful to think of ssh as an encrypted transport layer that only usually runs a shell on the other side.

You can lock down ssh remote commands, and of course require proxied connections. You can include full auditing of command execution.

[tptacek]

Who's running OpenSSH through "fancy $100k firewalls"?

[davidfiala]

It's off topic, but in my consulting and networking, security/firewall appliances are an easy first line approach I see companies buy in to. The security sales pitch sounds good and makes you feel good. Cannot name names.

[tptacek]

I mean, everybody has a perimeter, even the ZT believers, but I think the notion of large networks protected by like a high-end NetScreen or Palo Alto firewall is 10-15 years out of date. We have, like, Tailscale, and netfilter.

[HeatrayEnjoyer]

How would you login without ssh?

[daneel_w]

At the console, where applicable.