Daily system administration tasks often require administrators to connect remote systems. But allowing these remote systems to accept passwords makes these systems vulnerable to the risk of brute-force password guessing attacks. Furthermore there are some tasks that require automated non interactive logon to a remote system such as a backup file transfer to a remote system. The use of SSH addresses all these problems. SSH could be configured to accept only public key verified users to logon to a certain system. SSH keys also support password verification to check if the user is authorized to use the access key. This password may be omitted to allow an automated access. This is also good for scripted operations. Since the other alternative would be to enter the password directly into the script which must be avoided for all expenses because it is a huge security risk.
Lets create a ssh key pair for logon.
First of all you need to logon to the remote system. Once you've logged on and your placed in your home directory you're ready to go:
Initiate key generation using the ssh-keygen program. ssh-keygen is for creating a public/private key pair that will be used for logon. ssh-keygen allows the creation of key pairs using DSA or RSA algorithms. DSA keys must be exactly 1024 bits to allow FIPS-186-2 compliance. RSA keys could be 768-4096 bits in length. The default is 2048 bits. Generally DSA keys are preferred because DSA was always an open standard while RSA was protected by patents which were expired in 2000. For the time being there are CERT reports indicating to some vulnerabilities with DSA and ECDSA algorithms. It seems that RSA is safe against these vulnerabilities. But as I told earlier RSA keys are not widely used in the open community since DSA was always preferred due to it was always open-source.
Throughout the examples I'll prefer RSA keys in that it seems they are more susceptible to exploits for the time being.
The command such as this will start key generation:
Lets create a ssh key pair for logon.
First of all you need to logon to the remote system. Once you've logged on and your placed in your home directory you're ready to go:
Initiate key generation using the ssh-keygen program. ssh-keygen is for creating a public/private key pair that will be used for logon. ssh-keygen allows the creation of key pairs using DSA or RSA algorithms. DSA keys must be exactly 1024 bits to allow FIPS-186-2 compliance. RSA keys could be 768-4096 bits in length. The default is 2048 bits. Generally DSA keys are preferred because DSA was always an open standard while RSA was protected by patents which were expired in 2000. For the time being there are CERT reports indicating to some vulnerabilities with DSA and ECDSA algorithms. It seems that RSA is safe against these vulnerabilities. But as I told earlier RSA keys are not widely used in the open community since DSA was always preferred due to it was always open-source.
Throughout the examples I'll prefer RSA keys in that it seems they are more susceptible to exploits for the time being.
The command such as this will start key generation:
Here -t switch is the type of the resulting key it could be either DSA or RSA. Here I'll stick with RSA for the reasons I've explained above.
-C switch is also very useful it allows you assign a text label to your key so it will be easy for you to identify your keys.
It will respond with:
Hit enter here to accept the default filename (id_rsa) and the default location ($HOME/.ssh). It will then continue with:
Here's where the ssh-keygen asks you for a password. You can either hit enter twice and leave the password empty. While this could be useful to automate tasks requiring remote access it could be a potential security risk if the keys are compromised. Following the password the keys will be created and placed under $HOME/.ssh directory. The program will respond with this and quits:
Congratulations the key generation task is over. SSH is very sensitive to file and directory permissions. If it does not like directory permissions for .ssh it will abort key authentication during initial handshake and silently continue with other authentication methods resulting in you would only be able to login using your account password not the password you'd assigned during key generation. This would also preferred automated scripts to fail since authentication without password is not possible. Assuming that you're already located in your home folder use a command like this:
This will set the .ssh directory and files under it to rwx------ which is necessary for folders and private keys. As an increased security measure I've applied it to the public key too.
The next step is to locate the the .ssh folder and make arrangements for logon there. Please execute these commands:
These commands will allow the newly created key appended to the file called authorized_keys. The reason I've preferred to append is to protect the keys that might have been placed in the file earlier. If we'd copied it directly instead this would destroy any existing key.
Once more execute
If everything is okay you'll get a password prompt if you've set one and logged to the system
Now the operation is complete and verified too. You'll need to transfer the keys over to your system and need to remove the private key from the target system. During the authentication the client should have the private key (id_rsa) while all the server needs to have is the $HOME/.ssh/authorized_keys
Cheers,
K.
by: arober11 on 2010-10-25 at 00:55:48ID: 20756
chmod go-w $HOME
Also on the Public key distribution front the following may help:
# Create the necessary directory structure on the remote Host
cd $HOME/.ssh
ssh user@remote.host "mkdir .ssh && chmod 700 .ssh && chmod go-w \$HOME"
# Enter the remote password
# Add your Public key, to the remote hosts authorized_keys file
cat id_dsa.pub | ssh user@remote.host "cat - >> .ssh/authorized_keys"
# Enter the remote password
# Test the connection.
ssh user@remote.host "echo 'If you haven't had to enter a password the key pair has worked :)'"