If we encrypt our data with a longer SSH key which is protected by a shorter passphrase (with a decent entropy), then the limiting factor is entropy of the passphrase. So why do we use a longer key at all? We could simply encrypt the data with the passphrase.

$\begingroup$The only SSH keys that are encrypted under a passphrase are the 'static' ones stored in files, and those are never used to encrypt anything, only to authenticate a host and optionally a client at the start of a session. You can encrypt data with a key derived from a passphrase, but not in SSH, where it would be significantly less secure and robust than the DHE or ECDHE key exchange that is currently used. Note the actual strength of RSA or (now deprecated in OpenSSH) DSA is much less than its size; i.e. 2048-bit RSA has strength of only about 112 bits. ECDSA needs only 2xstrength.$\endgroup$
– dave_thompson_085Aug 30 '18 at 1:04

1 Answer
1

You're not modeling what information the attacker has. The strength of the system only reduces to that of the passphrase if the attacker has a copy of the passphrase-encrypted private key. If they don't, then the strength of the system is the strength of the private key.

You're not supposed to let your passphrase-encrypted private key file fall into adversarial hands. The passphrase is providing a fallback in case that condition is violated.

Note that the passphrase is optional, and that there also exist non-passphrase mechanisms for protecting the private key. OpenSSH supports using smartcards instead of private key files, and there are apps for smartphone-based SSH authentication, where the private key is protected by the device's hardware.