4 ms·

When you run ssh-keygen it creates the two keys, public and private, neither contain the 'plaintext' passphrase in your home directory like you mentioned. The o

by a904guy 16y ago

When you run ssh-keygen it creates the two keys, public and private, neither contain the 'plaintext' passphrase in your home directory like you mentioned. The only concern may be bash history, I'll include a wipe for that. Secondly, even while being transmitted using SSH they are NOT in plain-text. As the SSH connection itself is encrypted, so while executed in plaintext, the password is NOT stored in plain text, or transmitted in plaintext as identified by those commands. Finally, the remote_password being blank is by design, passwordless keys are less of a security threat than any weak user supplied password. They serve their purpose in the real world amongst private networks. EDIT for 'and in the command line.': Reviewing the command history doesn't show the libssh2 or php5 commands being executed on either BSD or debian. EDIT for your comment 'in the config file': If your suggesting that the software is insecure by the fact that the user leaves the config file after usage, then perhaps that user should be allowed in the environment to begin with.

zwp 16y ago
The command, including password, is also visible in the process table. Some unices limit visibility of other users' processes but many do not.
- 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 ago
    Any 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 ago
    no, 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.

by a904guy 16y ago

zwp 16y ago

The command, including password, is also visible in the process table. Some unices limit visibility of other users' processes but many do not.

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 ago
  Any 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 ago
  no, 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.