1. It can't be easily grokked. How many options does it have. Dozens? Hundreds? Compare to FTP.
2. Only specialists appear to understand the PKI infrastructure which underpins this security enough to properly manage the keys; possibly with expensive appliances. Compare to FTP; it's easy to grok managing and securing a string.
3. It's leaky. When you connect by FTP you present only the creds you desire. When you connect over SSH you expose all of your identities / keys to the other server. Pretty dumb.
Any secure system (more secure than FTP, at least) will have a lot of knobs. Most of the time, it is well handled by sticking to defaults. THis is something SSH has done well, and HTTPS not so well; I've had to set TLS configs on my web servers, while SSH is a simple `apt install ssh && cat /etc/ssh/ssh_host_ecdsa_key.pub`
> Only specialists appear to understand the PKI infrastructure ... Compare to FTP, it's easy to grok managing and securing a string.
It's also easy to break into a typical string-password-protected service. If FTP needed the higher security, it would have to use complex crypto. Crypto is hard.
But, as I said above, it doesn't have to be hard to use, only implement.
> It's leaky
Agreed, SSH should have some support for matching keys with hosts automatically. But it already supports doing this manually. Check out IdentityFile in ssh_config's manual.
2. Only specialists appear to understand the PKI infrastructure which underpins this security enough to properly manage the keys; possibly with expensive appliances. Compare to FTP; it's easy to grok managing and securing a string.
3. It's leaky. When you connect by FTP you present only the creds you desire. When you connect over SSH you expose all of your identities / keys to the other server. Pretty dumb.