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.

My BASH profile

These are notes on how I like to have my command prompt set up. I'm a BASH user so I will be updating the .profile and the .bashrc files. Both files are located in the users home directory.


This what my prompt looks like. It is a two line prompt, I find that it helps break up the commands from the output. The second line also gives more room for long commands and helps prevent the line from wrapping over top of the prompt.

earth:~

man@earth
< 

The basic bash prompt don't look all the great, as seen below. To get it look like the example above run the command below.

bash

bash$

export PS1="\[\e]2;\h:\w \a\[\e[0;31m\]\u\[\e[0m\]@\e[0;32m\h\e[0;34m\]\n<\[\e[0m\] "

Below I have posted my .profile file.

earth:~

man@earth
< more .profile

PATH=/usr/xpg4/bin:/usr/bin:/bin:/usr/sbin:/usr/local/sbin:/usr/openwin/bin:/usr/local/bin:/usr/ucb:/etc:/usr/X11/bin:/sbin:/usr/openv/netbackup:/usr/openv/netbackup/bin:/usr/openv/netbackup/bin/admincmd:/usr/openv/netbackup/bin/goodies:/usr/openv/volmgr/bin:/usr/sfw/bin/:$HOME

MANPATH=/usr/share/man:/usr/dt/man:/usr/openwin/share/man:/usr/X11/man:/usr/man:/usr/sfw/man:/usr/local/man:

EDITOR=/usr/bin/vi
TMOUT=0
TIMEOUT=0

#alias xterm="xterm -sl 1000 &"
#export PS1="\[\e]2;\h:\w \a\[\e[0;31m\]\u@\e[0;32m\h\e[0;34m\]>\[\e[0m\] "
export PS1="\[\e]2;\h:\w \a\[\e[0;31m\]\u\[\e[0m\]@\e[0;32m\h\e[0;34m\]\n<\[\e[0m\] "

The PATH statement is used to store the paths of the commands you want to use. This way you don't need to provide the full path for each command you want to run. The MANPATH statement is basically the same thing, but used to help you access the man pages.

Get the OpenSSL version

I often have to check which versions of applications we have installed our servers. Below I have post the method of checking the version of OpenSSL installed on a server. The command below should work with any UNIX based operating system. I might even work on Windows.

man@earth> openssl version -a

To find the non system or embedded versions you will have to run the find command. Shown below.

root@earth> find / -name openssl -type f 2>/dev/null

I hope this helps someone

My BASH Promt

Below are my notes on how I like my BASH prompt setup. This prompt has two lines which I find helps to break up the commands from the output. The second line also gives more room for long commands and helps prevent the line from wrapping over top of the prompt. I also update the title bar on the terminal or xterm with the hostname and current working directory. I find this helpful because this way I will always know who I am on the system, what server I'm logged into and what directory I'm in without typing any commands.

earth:~

man@earth
< 

Cut and paste the line below into your terminal or add in to your .profile file. If you like my prompt.
export PS1="\[\e]2;\h:\w \a\[\e[0;31m\]\u\[\e[0m\]@\e[0;32m\h\e[0;34m\]\n<\[\e[0m\] "

If you have any suggestions or questions post them below.

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.

Getting NetBackup 7.5 files for install

We just upgraded our NetBackup from 7.1 to 7.5. These are my notes on upgrading our UNIX and Linux clients.

Go to https://fileconnect.symantec.com and download the required files. You will need to enter a serial number to get access to the files. As seen to the right.

After you download the files you will have to join them together before you can do a install.


Unix joining instructions:
cat "NB_CLT_7.5.0.4-tar-split.1of3" "NB_CLT_7.5.0.4-tar-split.2of3" "NB_CLT_7.5.0.4-tar-split.3of3" > "NB_CLT_7.5.0.4.tar"

now you are ready to begin the install.

How to use VNC to view a remote system

VNC is a free 3rd party program that allows a remote login, similar to Remote Desktop in Windows or Daemonware. One nice thing about VNC, is that it's multi-platform. It works on Windows, UNIX, BSD, Linux and MAC. The down side to using VNC is that it's insecure, but you can wrap it in a SSH tunnel. Most of my experience with VNC is on Solaris and Red Hat. Most of the examples below are from a Solaris server.


To see if any VNC sessions is running on your server run the command below. # ps -ef|grep vnc
If you have a session running it will look like this. rich 15137 14170  0 Nov 24 ?    0:00  vncconfig -iconic
rich  538  8833   0 Nov 24 ?    7:34  Xvnc :1 -desktop server:1 (rich) -auth /home/rich/.Xauthority -geometry 1900
To start a basic VNC server session just type vncserver. # vncserver After you run this command you will get a session ID number. For example the first user of VNC server will get session number 1. When you connect to the session from a remote computer you use the hostname:1.

You will also need to set the VNC password to connect the session. # vncpasswd This sets the password for your account.

If you want more options, check the these popular options below. For screen size use -geometry widthxhight. If the computer you are connecting from doesn't have VNC Viewer installed then, you can use the -httpd option to connect using a web browser.  # vncserver :3 -geometry 800x600 -http

VNC is installed on MACs and you can turn on the VNC server by going to System Preferences -->  Sharing. Select Remote Management and then click Computer settings. In the drop down select VNC viewers may control screen with password. Then put in desired password in box.

The xstartup file controls the desktop you get. Uncomment lines 4 & 5 to get a gnome desktop.

Sometimes you need to shutdown the VNC session your using. # vncserver -kill :#Replace # with the session number VNC gave you.

Now that you have started the VNC server you will want to connect to use it. From a UNIX or Linux  you run the following command. vncviewer hostname:1 # vncviewer server1:1
If you are using VNC from a Windows PC, then there is a VNC viewer application.


Warning: If you auto-mount your home directory. Beware that different operating systems have different setting in the xstartup file. All VNC sessions use the same xstartup file, so changes made by you or the VNC program will effect the VNC experience. I ran into an issue when I tried to use the gnome desktop on both a RHEL & Solaris 10 servers. When I got the gnome desktop working for RHEL the gnome desktop was unusable with Solaris 10. The best way to get around this is to use different accounts or different windowing programs on different operating systems.

Important VNC files
$HOME/.vnc/xstartup -- The file that controls them all. This is the main config file used for the session on VNC server.

$HOME/.vnc/passwd -- The VNC password file

$HOME/.vnc/host:display#.log -- The log file for Xvnc and applications started in xstartup

$HOME/.vnc/host:display#.pid -- Identifies the Xvnc process ID, used by the -kill option.

Package list for Solaris 10
SUNWxvnc                VNC Server
SUNWvncviewer       VNC Viewer

Updating Java in NetBackup

These are my notes on updating the embedded Java in NetBackup. The Symantec NetBackup patches can't keep up with the Java security patches from Oracle. The way to get around this is to use the Java installed on the server instead of the embedded Java in NetBackup. Sometimes System administrators will just link the embedded program to the system program, this is not what I'm doing here. It is similar though, the fix I'm explaining here is supported by Symantec. The examples I give on this post are from a Solaris 10 (x86) server, but the steps below will work on any server that NetBackup runs on. The embedded Java is installed on all NetBackup servers and clients.

First we need to find all the java on the server. Running the commands java -version or which java is not enough. These commands only show the main Java on the server, as shown by the examples below. # java -version
Java version "1.6.0_33"
Java(TM) SE Runtime Environment (build 1.6.0_33-b03)
Java HotSpot(TM) Server VM (build 20.8-b03, mixed mode)
# which java
/usr/bin/java
Use the find command to find all the Java on your server. # find / -name java -type f
/usr/jdk/instances/jdk1.6.0/bin/amd64/java
/usr/jdk/instances/jdk1.6.0/bin/java
/usr/jdk/instances/jdk1.6.0/jre/bin/java
/usr/jdk/instances/jdk1.6.0/jre/bin/amd64/java
/usr/jdk/instances/jdk1.5.0/bin/java
/usr/jdk/instances/jdk1.5.0/bin/amd64/java
/usr/jdk/instances/jdk1.5.0/jre/bin/java
/usr/jdk/instances/jdk1.5.0/jre/bin/amd64/java
/usr/openv/java/jre/java
/usr/openv/java/jre/amd64/java The last two lines in the above example are the embedded Java in NetBackup.

To find out what version of Java is on the server. Put the path statements above into the terminal with  -version at the end. Like the example below.
# /usr/jdk/instances/jdk1.6.0/bin/java -version
Java version "1.6.0_33"
Java(TM) SE Runtime Environment (build 1.6.0_33-b03)
Java HotSpot(TM) Server VM (build 20.8-b03, mixed mode)
Open the .nbjConf in your favorite editor. # vi /usr/openv/java/.nbjConf
Change the JAVA_PATH to: JAVA_PATH=/usr/jdk/instances/jdk1.6.0/jre/bin/java
If NetBackup uses a different version of Java then the Java installed on your system it will still work for the client. I have tested this with NetBackup 7.1, which was using java 1.6.0_26, and set it up to work with Java 1.5.0_36. The Media server and the Master server need to have the same version of Java in order to work though.

Test Nebackup by performing a backup. If there are no errors then delete the two embedded Java files for NetBackup.

References:
NetBackup Instructions

If you have any questions or comments, please post them below.