In a Linux box, in BSD or derived such as under OS/X, or under Windows in Putty, a person can generate a LOCAL keypair which is used for keyed SSH access to such Virtual Machine instances. I have completely moved away from password based external access for all new instances, as keys carefully managed are demonstrably safer
So you know: There is some heat, but not a lot of thoughtful light about permitting and using root ssh access. Some not well though out security policies have a phobic avoidance of such. I'll address the matter in a later post, discussing hardening generally, sshd config file hardening, remote syslogs, TCP wrappers, iptables, and dynamic dictionary attack response
For the time being, let's put to one side and get past that security design choice rant, and accept that at least initially, a PMman instance has already made a short term choice for setting up access and for management of such units which are running CentOS or others following the Red Hat approach for management of instances [i.e., not SuSE/SLES, Debian family, nor the BSDs]
Under such Linux, this looks like this:
$ # create a high strength passphrase
$ # I have written of gen-pw.sh before
$ gen-pw.sh -a
a2Wa4aSaLWkRac
$ cd ~
$ cd .ssh
$ ssh-keygen -t dsa -f pippin.pmman.net.dsa
$ # there is a passphrase prompt here and
$ # we use that: a2Wa4aSaLWkRac
$ # -- also make a record of it in a safe place
$ # -- if one maintains multiple keys per box, it can be a
$ # chore to manage this -- but see: man ssh-agent
$ # this generated ~userid/.ssh/hostname.pmman.net.dsa
$ # [the private part] ... and
$ # ~userid/.ssh/hostname.pmman.net.dsa.pub
$ # [the PUBLIC part
$ cat ~userid/.ssh/hostname.pmman.net.dsa.puband scrape and place it in your mouse pastebuffer, and proceed to the web interface. The -f file's name 'hostname.pmman.net.dsa' is arbitrary, but chosen to be mnemonic
Then add a new stanza to: ~userid/.ssh/config like this:
#
Host hostname32.pmman.net hostname64.pmman.net
# optionally one can make a note of the passphrase here, but
# at the risk of exposing such if a local dire read compromise
# is experienced, or a backup of such falls into untrusted hands
IdentityFile /home/userid/.ssh/hostname.pmman.net.dsa
PasswordAuthentication no
Protocol 2
PubkeyAuthentication yes
#Note here a key may be used on more than one host; that is, we can add the same public key into /root/.ssh/authorized_keys of more than one unit -- here, both a 32 bit and a 64 bit instance with similar hostnames. But I get ahead of myself ...
Using a secure means, we need to transfer taht public key to a remote instance, and to add it to the right file; Here, we use the SSL protected web interface under the PMman machine management interface for a given machine, in the [more] menu, first item. By placing the public part into the web form box, the management backend at the datacenter, will be validated as to form, and then place that public key into ROOT's /root/.ssh/authorized_keys file
At that point, one can then ssh to that remote box as root, accept the host key, and take steps for hardening, adding a working userid, and so forth
