7 December 2007
Kickstart and ssh
Posted by brs under: Uncategorized .
Have you ever set up a remote, automated kickstart system only to have it fail on some esoteric piece of new-fandangled hardware? Were you then disappointed to find that while kickstart supports VNC connections, it did not allow ssh connections so that you could get a list of all the bleeding-edge, barely-supported hardware off the box and run some diagnostics in a shell? Well, be disappointed no more!
Enabling ssh connections to an automated kickstart configuration is fairly painless. To start, you’ll need a few things:
- A copy of /usr/sbin/sshd that is accessible. If you are installing over NFS, this can be copied into your distribution directory. If you are installing over HTTP or FTP, you’ll need to use curl to download the binary from some location
- A basic sshd_config file, ssh_host_key and ssh_host_key.pub
- An ssh public key that can be used to authenticate a root login during the installation
A really nice thing about the base system that is contained in an Anaconda install is that it contains all of the necessary libraries to fire up an sshd demon during the installation. This made our work incredibly easy. At this point, we assume that you have a working ks.cfg that you push out to your remote hosts for automated installations. What you’ll need to do is add a %pre script to the file that will configure sshd and start the daemon during the very begging of the installer. The following is part of an example ks.cfg file. Pay attention to the section that says “Lets enable sshd”:
%pre
echo "root:x:0:0:root:/root:/bin/sh" > /etc/passwd
echo 'root:<your_hash_here>:13732:0:99999:7:::' > /etc/shadow
echo "sshd:x:74:74::/var/empty/sshd:/sbin/nologin" >> /etc/passwd
# Make necessary directories and files for logins
mkdir -p /var/empty/sshd
chown root /var/empty/sshd
chmod 700 /var/empty/sshd
mkdir -p /var/log
touch /var/log/btmp
chmod 600 /var/log/btmp
chmod 400 /etc/shadow
# Add public key support
mkdir -p /root/.ssh
chmod 700 /root/.ssh
cp /mnt/source/ssh/authorized_keys2 /root/.ssh
# Start sshd
/mnt/source/ssh/sshd -f /mnt/source/ssh/sshd_config
For this script to work, you’ll need a bunch of things that this document wont cover. We’ll focus strictly on the sshd part. In this script, we require a directory, $KSROOT/ssh where $KSROOT is the directory where your CentOS/RedHat/Fedora installation media is located. The following files will need to be in this directory
- authorized_keys2: Put a public key in here for authentication purposes
- sshd_config: A basic sshd configuration. An example is provided below
- ssh_host_rsa_key: You can copy this from an existing installation that you want to mirror or generate a new one with ssh-keygen
- sshd: The sshd binary from an install of the OS you are installing with Anaconda
The following sshd_config should be sufficient for most cases:
Port 22
Protocol 2
# Logging
SyslogFacility AUTH
LogLevel ERROR
# Authentication:
PermitRootLogin yes
HostKey /mnt/source/ssh/ssh_host_rsa_key
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
# Change to no to disable s/key passwords
ChallengeResponseAuthentication no
UsePAM no
# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL
Obviously, you should not expect these configuration files to be drop-in-ready and you will need to do a little bit of tweaking to get them to play nicely with your environment. The nice thing is, now, you can remotely login to your host as it is installing (or, in this case, if the install fails) to get a list of the hardware, check the kernel ring buffer with dmesg, and run some basic diagnostics. Even though VNC allows you to see the installer, you cannot use a shell. This is, to my knowledge, the best way to get a remote shell during an Anaconda Kickstart install.
One Comment so far...
aastaneh Says:
18 January 2008 at 11:29 am.
This approach is highly effective when dealing with chassis with absolutely no PS2 plugs or VGA output. A big example of this is the Sun Bladecenter, which have neither. This is the only way to get into the innards of the blades during an install session. Another approach could be to spawn a shell in the installation environment, at which point VNC is an acceptable point of access. However, I have not yet found a means to do so.
Leave a Reply
You must be logged in to post a comment.