@drewdevault@forgejo I hope you don't have to make the same sacrifice as Forgejo does, password being echoed back because PTY allocations are disabled for SSH sessions.
@Gusted@forgejo My SSH keys can't leak, they're all on HSMs. And it shouldn't even be possible to make an SSH key that isn't password protected, but here we are in 2024 with people in charge of our security tools continuing to make terrible decisions
@feld@forgejo Having a verified SSH key is also a form of 2FA. For both occasions, you still need to know the password, so if your SSH key is leaked, it won't give anyone instant access to your account.
> Something that has come up in these situations is that such people usually have a (verified) SSH key added to their account and could use that to prove they are the owner of the account, by the possession of such SSH key.
okay so what's the point of enforcing any TOTP if it's basically defeated by possessing a verified SSH key?
@sun@forgejo@Gusted you're misunderstanding; with this change to Forgejo if an attacker targets a developer and is successful in intercepting their password and scoop up their SSH key from their $HOME you can defeat the TOTP on their account by using the SSH key you just stole
So the TOTP is now functionally useless when you're the target of an attack because the average developer is too stupid to password protect it and in 2024 you're not forced to password protect your keys
OpenSSH should not come with the capability to remove the passphrase from an SSH key. Sure, it's technically possible for anyone to write a tool that can do it, but it should refuse to support it. We can't just hope people will make better decisions, we need to force them in the right direction even if it's painful.
And then they can learn how to use their tools properly, like using ssh-agent so the key stays unlocked in memory during their session...