Wait, it's creating a separate public key in your home directory on every device listed, all with the same (plaintext!) passphrase, then sets up every device to SSH to any other one? Smells like bad practice!
For your comment that was edited stating: "the script was storing passwords in plain-text in the user home folder", There is no plaintext passphrases stored anywhere... and you can use different passwords per each device per the config file. This script follows the exact procedure for ssh-keys defined by OpenSSHD in general, ssh-keys are more secure than logging in using a password in general. As for the reverse connections, I have a version that utilizes the reverse key in the config array that keeps them from distributing across server, only to and from the localhost. I took it out to roll this version out as I still haven't tested it fully.
It gets even better - if you forgot to set REMOTE_PASS in the config file, it defaults to empty, and you end up with a passwordless key on most of your machines:
Even if you're only copying keys "to and from the localhost", you've still just given all your servers access -- likely without a password -- to your desktop computer.
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.
... 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.
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.
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.
The language doesn't really matter, especially considering its a single use app. It can be done via any LibSSH2 binding, or even with a more complex expect binding.
The reason for php is simple, I had already wrote the libssh2 code for what I needed. I submitted it, in hopes it saves someone else the time.
Are you really generating a separate keypair for each server? Why?
Why not generate one key pair on your management host, and then use the standard "ssh-copy-id" command to push the public key out to each managed server?
For the ability to remove a key from a single device/server. Considering the keys are tagged with user+host, removal is easily identifiable. A single key solution isn't ideal for my configuration.
Using ssh-copy-id is the standard method, but doesn't suite what I wanted.
Why would you want to remove a key on the management server? Why have all keys copied to all servers?
You say ssh-copy-id doesn't suite what you want, but you could easily create a much shorter script that just loops over the list of server and runs ssh-copy-id.
This seems wrong and overengineered for so many reasons. PHP, really? A simple one-line script will suffice to copy keys with ssh-copy-id or similar. (It gets even simpler if you use something like dsh or Capistrano.)
