yup, not an extensive list, but further demonstrative:
- 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
fun for toys, but i wouldn't put credit card details in there, unlike some streamers started doing lately.
ssh definitely supports PKI, it's just not the standard workflow for individuals
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)
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.
I'm not talking about supporting public key cryptography, I'm talking about having a specific and usable deployment of a PKI. The closest thing SSH has is SSHFP, which depends on DNSSEC, which is according to many opinions, DOA.
