

SSH Key Gen/Install Script. Automates Mass Distribution of SSH Keys - a904guy
http://blog.mediafederation.com/andy-hawkins/ssh-keygen-distribution-skd-install-ssh-keys-automatically/

======
theBobMcCormick
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?

~~~
a904guy
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.

~~~
theBobMcCormick
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.

------
duskwuff
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!

~~~
a904guy
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.

~~~
duskwuff
> There is no plaintext passphrases stored anywhere...

Sure there are - in the config file, and in the command line.

    
    
      59: `ssh-keygen -q -f ~/.ssh/id_{$server['type']} -t {$server['type']} -N '{$server['remote_pass']}'`;
      71: $server['conn']->shell("ssh-keygen -q -f ~/.ssh/id_{$server['type']} -t {$server['type']} -N '{$server['remote_pass']}'");
    

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:

    
    
      39: $_SERVERS[$k]['remote_pass'] = ($_SERVERS[$k]['remote_pass']) ? $_SERVERS[$k]['remote_pass'] : '' ;
    

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.

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

~~~
a904guy
... 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
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.

------
seanieb
It seems to be down for me.

Here's the Google cache:
[http://webcache.googleusercontent.com/search?q=cache%3Ahttp%...](http://webcache.googleusercontent.com/search?q=cache%3Ahttp%3A%2F%2Fblog.mediafederation.com%2Fandy-
hawkins%2Fssh-keygen-distribution-skd-install-ssh-keys-
automatically%2F&ie=utf-8&oe=utf-8)

~~~
a904guy
MediaTemple VPS... Time to migrate to my rackspace server.

~~~
mtmatt
Saw that you were having some issues. Took a look, and everything seemed to be
working fine. Let us know if we can help out with anything.

------
lobster_johnson
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.)

------
kilburn
An option in the config file to specify key length would be good IMHO.

~~~
a904guy
Ahh! good catch, Thank you. I'll zdd that in tomorrow.

