Keystroke timing obfuscation added to SSH(1)

Re:Keystroke timing obfuscation added to SSH(1) by vladvasiliu on Tuesday August 29, 2023 @02:24PM (#37311836)

Same way you'd get the password? It's either a physical or virtual server you more or less control, in which case the siblings' answers apply. Otherwise, it's probably some kind of image or something someone else controls, in which case bake in or send them your public key or certificate (if you've got colleagues in the same situation as yourself).

[ Parent | on HN ]

Re:Keystroke timing obfuscation added to SSH(1) by marginalia_nu on Tuesday August 29, 2023 @04:49PM (#37313844)

Getting a password does not require modifying the system. Injecting a public key does.

[ Parent | on HN ]

Re:Keystroke timing obfuscation added to SSH(1) by vladvasiliu on Tuesday August 29, 2023 @05:30PM (#37314411)

The password needs to be generated somehow, right? Assuming you don't you use a pre-baked password that repeats across machines, you could replace the password generation and retrieval with deploying a public key instead.

[ Parent | on HN ]

Re:Keystroke timing obfuscation added to SSH(1) by rollcat on Tuesday August 29, 2023 @05:21PM (#37314295)

The remote system must generate its own SSH private key; you could use that opportunity to deploy the authorized keys before sealing the system as read-only.

[ Parent | on HN ]