3 ms·
... well. Since we are going deep down the rabbit hole. So your machines other users are potentially a threat. Considering that the folder and contents are chmo
by a904guy 16y ago
... well. Since we are going deep down the rabbit hole. So your machines other users are potentially a threat. Considering that the folder and contents are chmod 600. Only the owning user and root can see them. The key pass is pointless without the key files.
While we are on the subject. Lets dig deeper on this situation. Whats stopping your rouge user on the same box (that can dump the proc table while ssh-keygen is executing in ms) from dumping the ram to extract the stdin password typed out by keyboard then?
If you already have fear of a user INSIDE your box. SSH keys should be the least of your concerns.
- zwp 16y agoAny non-privileged user can "dump the proc table" with ps(1). It's somewhat harder to break process address space separation (root privs, physical access, ...). It's not "fear" but rather "defence in depth" or perhaps "security evangelism". If we don't critique this kind of sloppy use then we tacitly condone it. That leads to (for example) people running "mysql --password=..." and wondering why their DB on shared host got owned. "But the ssh keys aren't readable unless... and we never reuse passwords and...". This kind of analysis is complex and (thus) error prone. Passwords on the command line should [almost always] simply be taboo, period.
- dododo 16y agono, you are using a unix-like system. if the user does not have root privileges, they cannot perform your ridiculous suggestion. the correct way to elicit a password from the user for ssh is to use ssh-askpass. a safe way to pass this to processes such that it does not appear in the process table is to pipe it.