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.
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.
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.