I'm not sure I follow. From what I understand, the issue is that literally all of stdin and stdout is potentially leaked to a globally-readable text file. ssh-keys wouldn't normally be part that leaked information (other than if you `cat` your private key, but by that logic, literally any credentials ever stored in a file or potentially even an env var would be equally susceptible). Yes, anyone with ssh access would have access, but nothing about this vulnerability seems to imply it would allow an unauthorized user to gain ssh access. It doesn't sound like this is something with a specific risk of leveraging into ssh access because the only ones who can read the file are the ones with access in the first place, so there's no more reason to suspect that now compared to any other point in time.
Agreed. I believe this means just means that the entire contents of your ssh session is available in /tmp/framer.txt. But as long as credentials aren't part of your STDIN/STDOUT, then they shouldn't be leaked.
Your ssh private key definitely would never be in there. The server you're connecting to doesn't even know your private key, just the public one.
That's an interesting point; I think it might depend on the exact details of how stuff is getting put into that tempfile. It's possible that anything getting read in via "silent mode" (see `-s` in https://ss64.com/bash/read.html) might not get put into that file, but given that this was a bug rather than a feature, it would probably be better to check the source code (or try an example with an unpatched version) to be sure.
