The easiest way to set up ssh without a password

Most people know how to create ssh public and private keys. If you hit enter when it asks for a password, you then have keys that don’t need a password to authenticate. As I show below, you really only need to do this once for each user if you own a whole farm of servers. Only worry about unique keys if you are giving them away to someone else or putting them on a server outside of your control. This may seem lax, but if you tighten up security too much in some places, you end up with unwieldy policies that people find ways to work around.

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa):
Created directory '/home/username/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.
The key fingerprint is:
63:ef:3d:e0:83:86:57:5c:61:57:2c:5c:9f:a4:f2:c6 username@thishost

I like to start by making a line between /etc/ssh/ssh_known_hosts and /home/root/known_hosts. This way, when I accept a host as root, it works for everybody. My philosophy is that if root trusts a host to be what it says it is, everyone else can trust it too:

cd /etc/ssh
ln -s /etc/ssh/ssh_known_hosts /home/root/.ssh/known_hosts

Next I use the same idea for users. Instead of making special keys for each server, I simply use the same one. This allows me to copy my user’s id_rsa.pub to authorized_keys:

scp root@trustedhost:/home/root/.ssh/id_rsa id_rsa
scp root@trustedhost:/home/root/.ssh/id_rsa.pub id_rsa.pub
cp id_rsa.pub authorized_keys

After that, just run a test to see if it works:

>ssh trustedhost pwd
/home/root
>ssh trustedhost ssh thishost pwd
/home/root

How to set up ssh to allow you to run remote commands

Configuration for ssh is done in two places:

  1. In the /etc/ssh directory as root
  2. In the user’s .ssh subdirectory

From a system perspective, /etc/ssh/sshd_config may need to be changed in order to restrict ssh version 1, allow root login (PermitRootLogin) or make other various changes. The sshd daemon can be restarted without disrupting current connections. In /etc/ssh is also a file called ssh_known_hosts. If you will be using ssh as the root user, I recommend making a symbolic link between root’s known_hosts file and this one. Then make sure and connect to any new hosts as root before connecting as a user. In this way, you will maintain a global known_hosts command and individual users will not have to maintain their individual host lists.

From a user perpective, ssh is set up by creating a public and private key pair with the ssh-keygen command:

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa):
Created directory '/home/username/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.
The key fingerprint is:
45:36:66:b8:39:bc:e0:84:ae:eb:50:e3:28:ec:47:0a username@hostname

$ cd .ssh
$ ls -l
total 16
-rw-------   1 username    staff          1675 Nov 24 12:40 id_rsa
-rw-r--r--   1 username    staff           401 Nov 24 12:40 id_rsa.pub

The file ‘id_rsa’ is your private key and should be kept on any system that is trying to ssh out. The file ‘id_rsa.pub is your public key. Give this to other people so that they can put in into a file on their side called ‘authorized_keys’. If you want to test ssh by connecting to yourself, simply move or copy ‘id_rsa.pub’ to ‘authorized_keys’. At this point you should be able to test ssh by connecting to yourself:

$ pwd
/home/username/.ssh
$ ls -la
total 16
drwx------   2 netiq    staff           256 Nov 24 12:50 .
drwxr-xr-x   3 netiq    staff           256 Nov 24 12:47 ..
-rw-------   1 netiq    staff          1675 Nov 24 12:47 id_rsa
-rw-r--r--   1 netiq    staff           401 Nov 24 12:47 id_rsa.pub
$ mv id_rsa.pub authorized_keys
$ ssh localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
 RSA key fingerprint is 3b:4b:af:d1:b3:ec:51:83:96:48:ea:8e:09:83:d4:80.
 Are you sure you want to continue connecting (yes/no)?yes
Warning: Permanently added 'localhost,127.0.0.1' (RSA) to the list of known hosts.
Last unsuccessful login: Mon Nov 24 12:43:24 CST 2008 on ssh from 10.32.12.45
Last login: Mon Nov 24 12:48:14 CST 2008 on /dev/pts/1 from 10.32.12.45
**********************************************************
*                                                        *
*                                                        *
*  Welcome to AIX Version 5.3!                           *
*                                                        *
*                                                        *
*  Please see the README file in /usr/lpp/bos            *
*  for information pertinent to                          *
*  this release of the AIX Operating System.             *
*                                                        *
*                                                        *
**********************************************************
$ exit
Connection to localhost closed.

Generally you will no only connect to yourself, but you will also not use the name ‘localhost’. After running this test, however, you will have created a new file called ‘known_hosts’ that contains a bit of data which describes this server. This is a human-readable file that will collect information about all of the servers that you connect to. This is the file that is over-ridden by /etc/ssh/ssh_known_hosts.

Once ssh is configured, scp and sftp will also work. If you are a micro-focus cobol user, you might see a different ‘scp’ which will seem wierd, simply change your path to fix this or fully qualify scp:

psoft$scp
PVER1
GERR00Not enough parameters
psoft{fsprd75}$whence scp
/usr/lpp/cobol/bin/scp
psoft$/usr/bin/scp
usage: scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file]
           [-l limit] [-o ssh_option] [-P port] [-S program]
           [[user@]host1:]file1 [...] [[user@]host2:]file2

Setup NTP date sync

Make sure you set up ntp to work and then just run it every time. Use dsh date to check that you are working. Below is a configuration file to be put into /etc/rc.d/rc2.d as Sntpd and Kntpd:

#!/bin/ksh

##################################################
# name: Xntpd
# purpose: script that will start or stop the time daemon. Configure it in /etc/ntpd.conf
##################################################

case "$1" in
start )
        startsrc -s xntpd
        ;;
stop )
        stopsrc -s xntpd
        ;;
* )
        echo "Usage: $0 (start | stop)"
        exit 1
esac

/etc/ntp.conf

# @(#)48        1.2  src/tcpip/etc/ntp.conf, ntp, tcpip510 2/16/96 10:16:34
#
#   COMPONENT_NAME: ntp
#
#   FUNCTIONS: none
#
#   ORIGINS: 27,176
#
#
#   (C) COPYRIGHT International Business Machines Corp. 1996
#   All Rights Reserved
#   Licensed Materials - Property of IBM
#   US Government Users Restricted Rights - Use, duplication or
#   disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
#
#
#
#
# Default NTP configuration file.
#
#   Broadcast client, no authentication.
#
#broadcastclient
driftfile /etc/ntp.drift
tracefile /etc/ntp.trace

server mydomaincontroller01
server mydomaincontroller02

peer mypeer01
peer mypeer02

To sync to the ntp server immediately and only if xntpd isn’t running:

ntpdate mydomaincontroller01