The following is a screen by screen walkthrough of generating both types of SSH 2 keys on an OS/X operating system environment. Then it demonstrates the transfer of that new public key to a remote instance. Click any left side image for a larger screenshot in a new panel.
From a terminal session on OS/X
There is in your home directory ['~'], or you may create, a directory .ssh which needs to have the permissions readible and writeable you and you alone.
Generate a RSA key on OS/X
We need either an RSA or a DSA type of SSH 2 key-pair. First we generate the RSA one thus:
We name the key intended for use with a given service distinctively -- here with the prefix: pmman so that we can tell a keyring of several keys apart as to their intended use.
We also note positively that OS/X requires the use of a passphrase by default. This is a safer practice; advanced users may investigate: man ssh-agent to learn about a tool to handle supplying the needed passphrrase only once in a given terminal session
Generate a DSA key on OS/X
Next we generate the DSA one thus:
Again, we name the key intended for use with a given service distinctively -- here with the prefix: pmman so that we can tell a keyring of several keys apart as to their intended use.
Technically only one key-pair is needed, but for completeness, this example shows the creation of both types of acceptible keys
Inspect the keys, preparatory to scraping and pasting
We can list the content of the directory, and inspect the keys thus
We only dump the 'public' part of the keys, as it is perfectly safe to share or give that to anyone. A public key has no value without both the corresponding 'private' key and the matching 'passphrase'. We will scrape and paste one or the other (or, here, both, in turn) into a web form that also places that key into a virtual machine instance in a later slide.
Control interface for virtual machines
The transfer of the public key part is done using the PMman virtual instance management screen. Log in, and go to it. Then select 'Additional Actions' for the relevant machine that is to receive that keying
Adding a DSA (dss) key
We scraped a copy of the key out of the terminal client and onto the clipboard's temporary store. Then we shifted focus to the web form and pasted it in there.
There is an invisible space after the ssh- which you may confirm by placing the mouse after the second s. The key transfer code tries to correct any problems about missing spaces and such. If you encounter problems, you can open a support ticket for help
Adding a RSA key
Again we scraped the key out of the terminal slient and onto the clipboard's temporary store. Then we shifted focus to the web form and pasted it in there.
There is an invisible space after the ssh- which you may confirm by placing the mouse after the a on the first line. The key transfer code tries to correct any problems about missing spaces and such. If you encounter problems, you can open a support ticket for help
And test that it works
Once one or both of the keys are transferred into the virtual instance, it is time to switch back to the terminal, and do some testing. From the .ssh directory, we use the following commands:
The terminal prompt changes to [root@vm049244170 ~] signalling that one is on another host, and in the user level of the root user. This was set with the -l root option in the initiating ssh command. We move into the .ssh subdirectory, and examine the public key, as held in the authorixed_keys file. As may be seen, this matches the value of the public key we dumped out back on the initiating OS/X host
At this point, we have established the ability to do normal systems administration through that ssh connection. A good first step would be to set up an end user account, and ssh2 keyed access for it.
Copyright © 2009 .. 2013 PMMan.com, a division of 781 Resolution, LLC