SSH public/private key

[HodgeHi]

Hello,

 

I have been looking at securing SSH for a bit and have looked at ssh keygen and configuring the public and private key pairing. I tried it on my server at home and copied my public key over to the authorised keys list on the server. I then proceeded to connect to the server using my macbook pro. It didn't prompt me for a password so i assume all went OK.

 

What i am failing to understand is how you can leverage this for others to use. I mean i have said to the server this is the private key that you need to use. But i can't email the private key everywhere surely. Have i got this all wrong?

 

I used the bombich / AFP548 tutorials to do this, but i think i may be mis-understanding how it is supposed to work.

 

Thanks in advance.

[HodgeHi]

I think that is called RSA. After this you would get challenged for a password after you type 'yes'?

 

The authentication type i am trying to refer to would be DSA. Using DSA you can opt to not use a passphrase and therefore have an unchallenged connection. This is ideal for using remote backup scripts such as rsync.

 

I'm just unsure as to how it can be scaled for example. Can you stick the private key into the authorised list of keys and then distribute the public key to a select few users thus resulting in them being able to connect to the server without a password going over the Internet?

 

Do you know if SSH secures the password before it goes across the web?

[keithu]

Each potential user should generate his own public/private key pair. They provide you with copies of their public keys which you add to the list of authorized keys on the server. That's all there is to it really.

 

If your clients are on Windows have a look at puTTY and pageant.

PuTTY: a free telnet/ssh client

[powdarrmonkey]

You're talking about two different types of keys here: the host identification key, which is presented by the remote machine to you to verify that it is the machine you think it is, and not a man-in-the-middle attack; and the user verification key, which is what you present to the remote machine to prove that you are who you say you are. The only time you should see a 'really connect?' warning is the first time, after that SSH caches the host key, so that if it changes it can bleat at you (a changed key indicates that this is no longer the same machine, and shouldn't be trusted not to be stealing things from you).

 

RSA and DSA keys are just generated using two different algorithms (compare). Same goes for the different key length choices available to you.

 

The public/private arrangement is a bit misleading. In effect, both parts of the key can verify each other, the only difference is that you choose one to keep very, very secret and one to publish. When you authenticate against a machine using keys, you sign the host's challenge with your private portion and it verifies it using the public portion you already told it about. If they match up, you're in.

 

So in practice, any user with an account generates a keypair, makes one known to the server in ~/.ssh/authorized_keys or similar and keeps one secret. For each user, rinse lather and repeat.

 

For interest, keypairs also form the basis for general signing and encryption, for example in emails. In fact, if you use Ubuntu or Debian (and probably lots of other distributions) packages are signed using PKs, so you can be sure they haven't been tampered with, though apt takes care of all that for you. Example: put the following block into a file mytext.txt:

 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hello this text has been cryptographically signed

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkn17F0ACgkQIGby58LrznGVDwCgq4DS5VlL+Y0xPKNHrMHTBxzo
PaEAoIkQJKxuFIc0kFZLr9uwHWM9Hv3L
=OOtB
-----END PGP SIGNATURE-----

and run the following to import the public portion of the relevant key and verify the signature:

 

gpg --keyserver subkeys.pgp.net --recv-keys C2EBCE71
gpg < mytext.txt

Further reading:

http://en.wikipedia.org/wiki/Public-key_cryptography

http://docs.sun.com/source/816-6154-10/contents.htm

 

(note: if you're doing this for your Joomla server, don't. The trade-off between convenience and security is too great. You should never store your private keys on a machine that you don't have absolute and personal control over. Password security is actually superior in this case, even if its more awkward (which is more or less the point)).

Edited April 27, 2009 by powdarrmonkey

[HodgeHi]

it is on the joomla server but for the vle installation. The vle will be installed alongside joomla remotely using ssh among other things