- terminal emulators are not security hardened clients against malicious actors
- ssh lacks PKI and is inconvenient so users never do prekeying in practice, so it's TOFU / zero server assertion in most practical cases (i.e. easy to mitm)
- ssh channel features are a constant concern, for server resources and for client features like agents, agents are easy to disable
- most ssh implementations don't scale that well, it wasn't ever really a goal to do so
- there are few tools for auditing and monitoring, unlike the common protocols/services/clients
ssh-keygen (1):
ssh-keygen supports signing of keys to produce certificates that may be used for user or host authentication.
Certificates consist of a public key, some identity information, zero or more principal (user or host) names and
a set of options that are signed by a Certification Authority (CA) key. Clients or servers may then trust only
the CA key and verify its signature on a certificate rather than trusting many user/host keys. Note that
OpenSSH certificates are a different, and much simpler, format to the X.509 certificates used in ssl(8)https://gitlab.com/secsh/pkixssh
http://tech.ciges.net/blog/openssh-with-x509-certificates-ho...
Right now I'd stick with something like Gravitational Teleport (overkill); Warpgate may become the perfect fit for this niche soon.
https://github.com/warp-tech/warpgate
It's also worth knowing about SSH clients that can use X.509 certificate keys as normal pre-shared keys with any SSH server, like PuttyCAC and built-in for macOS High Sierra and later.
While it supports serial numbers, expiration dates and key revocation lists, it does not allow certificate chaining. That means whoever signs keys for end users has implicit access to the master key.