Setup SSH Keys with Agent

This guide for setting up SSH Keys with an SSH Agent for auto-logging into Linux based systems. Why set up SSH keys, why not just use your password? SSH Keys are considered more secure than using passwords to access systems, because user accounts are authenticated by the server without ever having to send your password over the network. If the passwords are not transmitted then they can't be intercepted. This works by identifying yourself to an SSH server using public-key cryptography and challenge-response authentication. When you set up an SSH agent then the agent will handle the challenge-response authentication for you.

This guide is not for installing or setting up a SSH server. You must have the sshd service running on your system in order to follow along with this guide. All the examples are take from a Red Hat system. In the following examples, earth is the name on the local system and moon is the remote system. 

Create you key pair

The ssh-keygen command will generate a public and private keypair. The keys will be stored in the users home directory by default, this is the path  ~/.ssh/. The basic command looks like this: ssh-keygen -t [dsa|rsa]  The -t sets the type of keys used. In the example below I create a rsa key pair. This command also sets the passphrase, think of this like setting a password. Make sure you remember the  passphrase because you will use this instead of the password for logging into the remote system (moon).

man@earth> ssh-keygen -t rsa
Enter file in which to save the key (/home/man/.ssh/id_rsa): Press [Enter] key
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/man/.ssh/id_rsa.
Your public key has been saved in /home/man/.ssh/id_rsa.pub.
The key fingerprint is:dfhjodfnk
04:be:15:ca:1d:0a:1e:e2:a7:e5:de:98:4f:b1:a6:01

It is import to protect your private key, so don't share it. 

Note- Do not leave the passphrase blank. Doing this is a bad security practice, because this defeats the purpose of having the extra security of SSH keys. This will make the system less secure. If you have done this just rerun the command and add a passphrase. 

Install Public Key on Remote Host

You install the public SSH key by copying or appending it to the authorized_keys file on a remote host. This file is also located in the users home directory, ~/.ssh/.  For most systems you can use the ssh-copy-id command, which I cover in Method 1.  I will show a work around if the ssh-copy-id command is not available, in Method 2 & 3.

Method 1 - Use The ssh-copy-id Command

The easiest way to install the public key to a remote SSH server is use the ssh-copy-id command. To use the command type "ssh-copy-id <remote host>". This command appends the public key to the authorized_keys file on the the remote host. If the file doesn't exist it will be created. 

In the example below "moon" is the name of the remote host.

man@earth> ssh-copy-id moon
Now try logging into the machine, with "ssh 'remote-host'", and check in:

.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

This the best way is to copy over the public key because ssh-copy-id will create .ssh/authorized_keys file if it doesn't exist. The command also appends the public key to the authorized_keys file, whereas other methods may overwrites the file. This allows the account to use keys from more than one system.

Note- This method will not work on some systems, such as Solaris 10.

Method 2 - Manually Copy the Key File

This method uses the scp command to copy the public key to the remote server. Before the ssh-copy-id  command came about, this was way it was done. The key file will fail to copy to the system if .ssh/authorized_keys doesn't exist. If this happens just login with your password and create the file and try again. The main downside to this method is that it overwrites the authorized_keys file.

man@earth> scp ~/.ssh/id_rsa.pub moon:~/.ssh/authorized_keys

Alternately you can get around this by doing this instead. The command below mimics what the ssh-copy-id command does. It creates the .ssh directory if it doesn't exist and appends the contents of the key to the authorized_keys file.

man@earth> cat ~/.ssh/id_rsa.pub | ssh man@moon "mkdir -p ~/.ssh  &&  cat   >>  ~/.ssh/authorized_keys

Method 3 - If You Automount Your Home Directory

If your home directory automounts across a lot of servers then you can just append the contents of the public key to the authorized_keys file. This method can be a lot faster then other methods. For example if you have 100 hosts you need to connect to, you just need to run the command once to connect to all of them. Instead of running 100 copy commands you just run one. Again this will only work if the hosts your connecting to automount the same home directory that the SSH kays are on.

You can copy it over with the cat command.

man@earth> cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

The other methods will still work if you prefer them to this one. 

Setting up the SSH Agent

At this point when you login to a remote host you now get prompted for the SSH passphrase instead of the password. To automate the login process it is recommended to setup an SSH Agent. Luckily setting up an SSH Agent is easy. The agent holds the passphrase for the user and then presets the passphrase when prompted. 

There are some considerations you need to consider when running an SSH Agent. If a GUI is installed on the system, such as gnome, then the window manager may run the agent for you. This is by far the easiest way to setup an agent. If the system window manager handles SSH keys then you get prompted with a GUI text box for a passphrase the 1st time you try to SSH to a remote host. If you enter the passphrase the GUI will run the SSH Agent for you system wide for the user currently logged into that account. This lasts until the system is rebooted or the user logs out.

You can also run the agent from within a terminal or shell. When you run an agent from the terminal it will only work from that terminal and not system wide like does if the GUI manages the agent. 

To start an SSH Agent in a terminal run the commands show below. 

man@earth> eval `ssh-agent`
man@earth> ssh-add
Enter passphrase for /home/man/.ssh/id_rsa:
Identity added: /home/man/.ssh/id_dsa (/home/man/.ssh/id_rsa)

Note- Add these commands to the .bashrc file to start an agent automatically when you open a terminal emulator. 

If you use VNC, just start your VNC server session in the same terminal you used to starting your agent. This way all your terminal emulators launched in your VNC session, will use the same agent.     

SSH Agent Management

One issue with agents is that sometimes you end up running a lot of agents. This is because the agent doesn't stop running when the terminal closes. You need to run the command below and kill any agents that you are not using.

man@earth> ps aux | grep agent

If there is more than one agent running then you should kill the additional ssh-agent.

man@earth> pkill ssh-agent

This will only kill agents owned by the user running the command in.

One way to kill your ssh-agents is to add a kill statement to the .bash_logout file.

Reference Section
Manpage ssh-copy-id

A Better Way to Setup SSH Keys

Note - I have a newer version of this how-to. Please click here 

This is a guide on setting up SSH Keys for a Linux based user account. Why set up SSH keys, why not just use your password? SSH Keys are considered more secure than using passwords to access systems, because user accounts are authenticated by the server without ever having to send your password over the network. If the passwords are not transmitted then they can't be intercepted. This works by identifying yourself to an SSH server using public-key cryptography and challenge-response authentication. Not to mention if you set up a SSH agent then the agent will handle the challenge-response authentication for you.

This guide is not for installing or setting up a SSH server. You must have sshd service running on your servers in order to get your SSH to work. All the examples are take from a Red Hat or Suse servers. The ssh-copy-id command will not work on Solaris servers but all other commands should work file.

Create you key pair
The ssh-keygen command will generate a public and private keypair. The keys will be stored at ~/.ssh.The basic command looks like this: ssh-keygen -t [dsa|rsa]  The -t sets the type of keys used. In the example below I create a rsa key pair.

man@earth> ssh-keygen -t rsa
Enter file in which to save the key (/home/man/.ssh/id_rsa): Press [Enter] key
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/man/.ssh/id_rsa.
Your public key has been saved in /home/man/.ssh/id_rsa.pub.
The key fingerprint is:dfhjodfnk
04:be:15:ca:1d:0a:1e:e2:a7:e5:de:98:4f:b1:a6:01

Make sure you don't use a blank passphrase. Doing this is very insecure. Having a blank passphrase defeats the purpose of having having the extra security of a key exchange setup. It is also import to never give out your private key, which also compromises security of your account.


The old way of transferring the public key to the remote sytem.

man@earth> scp ~/.ssh/id_rsa.pub moon:~/.ssh/authorized_keys

New way

man@earth> ssh-copy-id user@moon
Now try logging into the machine, with "ssh 'remote-host'", and check in:

.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

The reason the new way is better then the old way is that the ssh-copy-id appends the public key to the authorized_keys file. Where as the old way overwrites the authorized_keys file. This allows the account to use keys from more than one server.

Note- This method will not work on Solaris 10

If your home directory automounts across a lot of servers. You can copy it over with the cat command.

man@earth> cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

You can also use this method if the ssh-copy-id command is not available to you.

man@earth> cat ~/.ssh/id_rsa.pub | ssh man@moon "mkdir -p ~/.ssh  &&  cat   >>  ~/.ssh/authorized_keys"

Setting up the SSH Agent.

man@earth> eval `ssh-agent`
man@earth> ssh-add
Enter passphrase for /home/man/.ssh/id_rsa:
Identity added: /home/man/.ssh/id_dsa (/home/man/.ssh/id_rsa)

Note- Add these commands to the .bashrc file to start an agent automatically when you login to a server. 

There are other ways to set up the agent, such as using the gnome GUI for example. If you use VNC, just start your VNC server session in the same terminal you used to starting your agent. This way all your terminals launched in your VNC session, will use the same agent.

SSH Agent Management
One issue with agents is that sometimes you end up running a lot of agents. Run the command below and kill any agents that you are not using.

man@earth> ps aux | grep agent

If there is more than one agent running then you should kill the additional ssh-agent.

man@earth> pkill ssh-agent

This will only kill agents owned by the user running the command in.

One way to kill your ssh-agents is to add a kill statement to the .bash_logout file.

Reference Section
Manpage ssh-copy-id

Related posts on this site.
How to setup SSH Keys
http://rich-notes.blogspot.com/2013/09/how-to-setup-ssh-keys.html

If you have any questions or comments please post below.

Check for a blank SSH key passphrase

I found out one of my co-workers was not using a passphrase to secure his SSH keys. This is very insecure way to do business. Many people leave passphrase blank because they do not know how to setup a SSH agent, or can't be bothered with setting up the SSH agent. If you don't know to set up a SSH agent refer to my How to setup SSH Keys post. I came up with a way to check all the accounts on the servers I manage. I wanted to know how many other people where not practicing good security. I have tested this script on Solaris 10, Red Hat Linux (RHEL 5) and SuSe (SLES 11.2).

What the script does.
The script mounts the share that all the users home directories auto-mount from.  This way the user needs not to be logged in for me to check there keys. I then copy all the names of the users home directories into a file. The script checks then checks for the word  ENCRYPTED in the id_rsa file. If the word ENCRYPTED is in the file then the passphrase is set. The temp files are then removed and the share unmounted.

This my script I came up with.

#!/bin/bash
# This script is for checking for a blank passphrase. Meaning no passphrase
to secure your SSH file.
# Script most be run as root.
# Example: sudo ./check-sshkeys

mount share:/vol/home /mnt
ls /mnt >/tmp/ls
for s in `cat /tmp/ls`
do echo -e "\e[1m User $s \033[0m "
if ls /mnt/$s/.ssh/id_rsa 2>/dev/null
        then grep ENCRYPTED /mnt/$s/.ssh/id_rsa || echo -e "No RSA
passphrase"
        else echo "RSA key not found"
fi
if ls /mnt/$s/.ssh/id_dsa 2>/dev/null
        then grep ENCRYPTED /mnt/$s/.ssh/id_dsa || echo -e "No DSA
passphrase"
        else echo "DSA key not found"
fi
done
rm /tmp/ls
umount /mnt

Draw backs
Now there are ways that a user can get around this, like putting the word ENCRYPTED in the right file. But most users will not do this, so this should still work for most users. The script above will need to be modified in order to check users who don't have their home directories auto-mounted.

I can't take all the credit for this, I had some help. Below I have posted the link to the forum were I  asked for help on this script.

Ref:
Is there a way to check a users SSH key to see if the passphrase is blank

Using SCP on Windows Command Prompt

In this post, I show how to move files between a Windows machine and a UNIX machine, using the command line. When I say a UNIX machine, I mean all UNIX based operating systems such as UNIX, Linux, FreeBSD and Mac OS. In this post I will be using the free PuTTY utility called PSCP.

As you know SSH is not supported in Windows, you will need to download a 3rd party program.
The People who make PuTTY, which gives SSH terminal emulation on Windows machines, has a program called PSCP. PSCP gives you the ability to use SCP or SFTP form the Windows command prompt.

You could use a GUI program that lets you SCP or SFTP the files. The issue with this approach is that an application with a GUI has limitations. If you use a command line tool, like PSCP, to move the files then you can also put it in a script. A script that can be used by the Windows Task manager or the UNIX crontab. PSCP is free and doesn't need to be installed.

Download pscp from  PuTTY download page.

After you download PSCP move it to your My  Documents folder. As the program doesn't need to be installed, It is ready to use as soon as you download it. All you need to do, to use PSCP is follow the examples below.

Run the command as shown below to move files from the Windows machine to a UNIX machine

Command Prompt

C:\> pscp.exe files man@earth:/path

Run the command as shown below to move files form a UNIX machine to a Windows machine.

Command Prompt

C:\> pscp.exe man@earth:/path/files  C:/path/

In the example above, man is the user name and earth is the name of the UNIX server. The user name can be left off if the user account in Windows have the same name as the user account on the UNIX server. I would highly recommend that you use the same user name on both systems.

Some options
If you want to force the use of ether SCP or SFTP add -scp or -sftp right after pscp.exe. If you want to use a SSH agent to manage you SSH Keys add the -agent option. I will go more into how to use SSH Key with PSCP in a future post.

Draw Back
In the method I shown here, you must start the SCP or SFTP session from the Windows machine. The Windows machine can't accept incoming requests, because there is no SSH sever running on the the Windows machine.

References
PuTTY documention

How to setup SSH Keys

Note - I have a newer version of this how-to. Please click here 

This is a guide on setting up SSH Keys for a UNIX based account. What are SSH keys you ask? They are means of identifying yourself to an SSH server using public-key cryptography and challenge-response authentication. SSH Keys are considered more secure than using passwords to access systems, because user accounts are authenticated by the server without ever having to send your password over the network. If the passwords are not transmitted then they can't be intercepted.
This guide is not for installing or setting up a SSH server. You must have SSH running on your servers in order to get your SSH keys to work. All the examples are take from a Solaris 10 (SPARC) server. This guide should as work on any UNIX based operating system like Linux, BSD and the Mac.

Create you key pair
The ssh-keygen command will generate a public and private keypair. The keys will be stored at ~/.ssh.The basic command looks like this: ssh-keygen -t [dsa|rsa]  The -t sets the type of keys used. In the example below I create a rsa key pair.

man@earth> ssh-keygen -t rsa
Enter file in which to save the key (/home/man/.ssh/id_rsa): Press [Enter] key
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/man/.ssh/id_rsa.
Your public key has been saved in /home/man/.ssh/id_rsa.pub.
The key fingerprint is:dfhjodfnk
04:be:15:ca:1d:0a:1e:e2:a7:e5:de:98:4f:b1:a6:01

Make sure you don't use a blank passphrase. Doing this is very insecure. Having a blank passphrase defeats the purpose of having having the extra security of a key exchange setup. It is also import to never give out your private key, which also compromises security of your account.

Copy public key
Copy you public key to the authorized_keys file on the remote server.

man@earth> scp ~/.ssh/id_rsa.pub moon:~/.ssh/authorized_keys

If your home directory automounts across a lot of servers. You can copy it over with the cat command.

man@earth> cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

Setup Agent
At this point, when you login you get prompted for a passphase. To stop this from happening you need to setup a SSH agent. Run the command below and type in your passphare when prompted.

man@earth> eval `ssh-agent`
man@earth> ssh-add
Enter passphrase for /home/man/.ssh/id_rsa:
Identity added: /home/vivek/.ssh/id_dsa (/home/man/.ssh/id_rsa)

There are other ways to set up the agent such as using the gnome GUI for example. Unfortunately that only works if your running a gnome desktop. If your a VNC user, you should start your VNC server session after starting your agent in the same terminal. This way all your terminals launched in your VNC session, will use the same agent.

One issue with agents is that sometimes you end up running a lot of agents. Run the command below and kill any agents that you are not using, as a good practice.

man@earth> ps -ef | grep agent

References
g-loaded.eu
Symantec: SSH and ssh-agent

If you have any questions or comments please post below.

Restict SSH logins

As a System Administrator you always want to make your servers more secure. With that being said I'm going to restrict ssh logins. To do this, I will make a change to the /etc/ssh/sshd_config file. This change will limit the ability of accounts to login using ssh to only accounts in a the users group. The example below is from a Solaris 10 server, but this will still work on any UNIX, BSD and Linux system. We have done this on Solaris 10, RHEL 5 and SLES 11 servers at my work place.


Before you begin,  login to the server using a remote console or at least more then one terminal. I had one co-worker lock himself out of the server because he forgot to add himself to the users group before he restarted ssh. I would also take note of any programs that use ssh so you don't lock them out.

# vi /etc/ssh/sshd_config
Add the following line to the /etc/ssh/sshd_config file. AllowGroups users You can use any group you want, you don't have to use the users group. Often you will find that many people like to use the group sshusers for this function. I use the default group users, because all the user accounts use SSH to access my servers. Make sure you check all you application accounts and make use they are the in the group that are using for SSH. otherwise your applications may no longer work.

To have the changes take affect you need to restart the sshd process. # svcadm restart ssh or # /etc/rc2.d/K03sshd stop
# /etc/rc2.d/K03sshd start

Test the the new setup by trying to login with one accout not in the users group and one that is. The account that is in the users group should be able to login, but the account that is not should not.

 If you have anything to add please post below.

Run Commands Remotely on Multiple Servers

Have you ever had to run the same command on several servers? It takes a lot of time to login to each server and then run a command or group of commands. There is also the possibility for errors, so I wrote this note to remind myself how to do this, if ever I need it. To get the most from this post you need to have your SSH agent working. If your SSH agent is not working don't worry the script below will still work, but you will have to login to each server on your list as the script moves along.

I'm going to use a real world example to explain how to run commands on many servers. I often have to do security checks on my servers. Many of the checks I do consist of checking file permissions and ownership. An easy enough check, but it can take time if you have to check more then 10 servers. So with that being said, we are going to check ownership and permissions on the /etc/resolve.conf file. I will using a space theme for the terminal examples in this guide. The user account is man and the servers are earth, moon, mars and saturn. 

Lets get started by testing the command we are going to use.
man@earth> ssh moon ls -l /etc/resolve.conf
-rwxr-xr-x  1 root  root  20 Oct  6  2011 /etc/resolv.conf
man@earth>
Ok above I logged into moon and ran the ls -l command and the result was printed to the screen. After the command executed the connection to moon was disconnected and you are returned to earth.
Test the in a script.man@earth>for s in moon
> do
> ssh -q $s ls -l /etc/resolve.conf
> done
-rwxr-xr-x  1 root  root  20 Oct  6  2011 /etc/resolv.conf
man@earth>
Let me explain what is going on in the script above. The line for s in `moon` makes s a variable. So when the 3rd line says ssh -q $s it is seen as ssh -q moon, by the computer. The -q option for ssh stops any ssh banner from displaying. Which will make seeing the out put from several servers much easier to see.

Open your favorite text editor and create the file below and call it check.
#!/bin/bash
servers="moon mars saturn"
for s in $servers
do
ssh -q $s uname -n
ssh -q $s ls -l /etc/resolve.conf
done
Now lets test the check script.
man@earth> bash check
moon
-rwxr-xr-x  1 root  root  20 Oct  6  2011 /etc/resolv.conf
mars
-rwxr-xr-x  1 root  root  20 Oct  6  2011 /etc/resolv.conf
saturn
-rwxr-xr-x  1 root  root  20 Oct  6  2011 /etc/resolv.conf
man@earth
Now the output shows the script logging into moon 2 times and running uname -n and then the ls command. Then followed by output from mars and saturn.

Note - By typing bash in front of a BASH script you can execute the script without making it executable.

To make the script a little more useful I'm adding a server list file called servers. I will also append the output of the commands to a file called result, on the server (earth). The final script is below.

Example of the servers file
moon
mars
saturn

The final script
#!/bin/bash
for s in `cat servers`
do
ssh -q $s uname -n >> result
ssh -q $s ls -l /etc/resolve.conf >> result
done


I hope this helps someone

Forwarding Display

These are my notes on how to forward a display on a UNIX based operating system.

For this example we will useing the names home & remote for our servers. Home is the starting sever and remote is the server your logging into and displaying the app back to the home server. rich@home# ssh -X remote Can also use -Y instead of -X. This is more secure then the method described below.

Some work places don't allow X forwarding so you have to use the DISPLAY variable. rich@home# xhost + remote
server2 being added to access control list
rich@home# echo $DISPLAY
:1.0
rich@home# ssh remote
rich@remote# export DISPLAY=home:1.0 At this point you can now forward your display. Export DISPLAY works with BASH and KSH. Use setenv DISPLAY for CSH. Take a note of the fact that this 2nd way of forwarding your display is insecure. 

Reference
How to export display from Linux to FreeBSD