I understand what you are saying but in my experience the opposite can be equally true. Unless every system in your org is managing the authorized_keys for every account with automation and hourly validation one can end up with rogue keys, forgotten keys, unmanaged keys. SSH has no concept of identity in this regard. If I temporarily have sudo on a system I can append any random public key into the authorized_keys of any account. It gets even worse if that system allows passwordless sudo. Now there is an audit trail that showed you made a reckless change when it was really me. This risk gets exponentially worse if the system I append a random key into is a command and control or configuration management system. One doesn't even really need sudo for this to be a problem given how much power non root accounts have over applications, deployments, builds and secret management.

Is authorized keys important here? If I send the server my password, it has my password. If I send a server my public key, that's a lot less severe. If an attacker is on the server I expect that the difference is obvious?

Both are vulnerable to phishing via malicious scripts. One could even argue that keys are more dangerous if the attacker can append their own key into authorized_keys one host at a time. Some might be surprised how incredibly easy it is to get a percentage of technical people on an email distribution to execute a script without fully understanding it and this is even leaving things out like compromising npm repositories. Said script can drop a key into authorized_keys or drop a custom key and create an outbound session invoking a gateway port allowing the attack to ssh to the host even if they have no inbound ports open. From there one can repeat the process as access is gained first at the workstation or laptop, then the jump host then build servers, repository servers, staging servers and ultimately production servers.

SSH is a power communications tool. It is equally powerful to both the authorized user and to attackers in my experience. It is often poorly managed if even managed at all even in the most sensitive environments in some of the most high profile organizations.

How would you phish my private key?

I would not. I would phish you running a script that adds my public key to your authorized_keys and would ssh from your client in the background creating a gateway port back to you. At that point I can get your ssh keys and just about anything else. If systems in your org allow ssh multiplexing default is enabled then I can also piggy-back your sessions bypassing MFA/2FA.

I say you but I mean most people. I'm certain that you specifically would not fall for it but about 10% [1] of technical people will.

[1] - stats based on past career and testing of a large technical population.

I'm not sure I understand the attack. I connect to a server that you, the attacker, are on. How does your attack get my private key? Assuming I'm not forwarding my key, and you're not on my laptop.

You run a script that has obfuscated code. The script is "broken" and has an easy problem for you to identify for me. You feel good about finding my amateur mistake.

In the background the script has dropped my public ssh key either into your authorized_keys if you have sshd running, or into a random location if you do not and launches sshd as you in the background if it is not running. It can be on a high random port listening on 127.0.0.1, this is fine.

The script also backgrounds an outbound connection to a machine I control enabling a gateway port that I can use to SSH back to your machine even if you are behind a firewall. It will tell me if you have ssh listening on 22 or on the loopback and what port. My tunneled ssh connection will utilize that ssh key I appended or dropped. I am not on your machine as you. That back-grounded connection can also be added to your .[a-z]* shell login files based on the shell you are using at the time so that if you reboot the tunnel is recreated.

Now I am on your machine as you and I can grab your private keys, ride along your existing SSH channels that you have authenticated with your 2FA/MFA provider assuming the hosts you connect to leave multiplexing enabled, connect to your browser and watch the console http session data and so much more.

This scenario will technically work on most peoples setup. About 10% of people will run the script. No hacker tools or malware required, just an obfuscated script. This will never be detected by anti-malware software. The script language will depend on what I think your organization uses. It could be python, perl, ruby, go, java, bash, anything really.

The only technical mitigating control would be to limit where the person can make an outbound connection. i.e. pre-approve TCP destinations. If a laptop or workstation can SSH to a random cloud provider then the script will work.

You're not on my machine. You're on the server. You still don't have my private key.

What I described above puts me on your machine. This is not theory, it has been tested against many people. Legally of course.

So you were vague about where I execute the script. If I execute the script on my client, obviously you have my key, but that's not interesting. If I execute the script on my server, you do not have my private key, period.

This whole "I can ssh back to your machine past your firewall" is not a thing I understand, I am not aware of that capability in SSH.

I've received the private component attached via email before. People find a way to mess up.

re-using an insecure key is just as easy https://github.com/mikalv/anything2ed25519