LPI Linux Certification in a Nutshell (69 page)
Read LPI Linux Certification in a Nutshell Online
Authors: Adam Haeder; Stephen Addison Schneiter; Bruno Gomes Pessanha; James Stanger
Tags: #Reference:Computers
The Digital Signature Algorithm (DSA) is an open standard
used for creating digital signatures based on public key encryption. DSA
is used in many different applications, including SSH and GPG, because it
is an open standard and not subject to traditional copyright. The Rivest,
Shamir, Adleman (RSA) algorithm is the first algorithm widely used to
create digital signatures, but it is subject to copyright restrictions
that some developers find onerous.
You will find that SSH uses RSA by default, whereas GPG uses DSA. As
with many algorithms, you can specify various bit lengths; 1024 and 2048
are common lengths, but given the increase in processor speeds that permit
ever-faster brute force attacks, 2048 is currently considered the minimal
length to provide acceptable security.
In most cases, you will want to generate SSH keys for your own
accounts and perhaps your root account. Use
ssh-
keygen
for this. A
reference for the needed commands appears at the end of this section
(the short of it is: run
ssh-keygen -t dsa
and
press the Enter key at all the prompts). This key allows password-less
remote logins, as long asPubkeyAuthenticationis enabled in the server
configuration file.
In
~/.ssh/id_dsa.pub
you can find the
public key you’ve generated through
ssh-keygen
. You need to transport this key to the
remote machine. Because it’s a public key, it does not need to be
secure. On the remote machine, put the key at the end of
~/.ssh/authorized_keys2
. Once the key is in that
file, all users who have the private-key counterpart will be able to log
in to that remote account without a password.
users
Sometimes it makes sense to let users log into other
machines without having to set up authentication themselves. The
easiest way to do this is to create and modify all the files on one
machine, as described in the following procedure, and then use
tar
and
ssh
in a pipe to
transfer them to the other hosts.
Enable
HostbasedAuthenticationin
/etc/ssh/sshd_config
configuration files on
all hosts.On the Exam
The exam may ask you about the
HostbasedAuthenticationfeature and
its purpose. Make sure that you know its purpose, as well as the
exact location of the
/etc/ssh/sshd_config
file.Your client configuration is in
/etc/ssh/ssh_config
. All hosts should haveHostbasedAuthentication yesset
there, and if they have aPreferredAuthenticationsstatement, it
should listhostbasedfirst.
The hosts’ private keys should be readable only by
root
(otherwise, the key would not be all
that secret). Exactly what is needed to get SSH access to the keys
depends on the version. If your SSH package includes an executable
called
ssh-keysign
, it must be SUID root (it
may not be installed that way, so you must check this manually)
and must provide the signing service that proves the host’s
identity in the key exchange. If the package does not contain
ssh-keysign
, make sure the
ssh
executable is SUID root through
chmod u+s /usr/bin/ssh
.On each host, create
/etc/ssh/shosts.equiv
. This file defines the
hosts with equivalent security levels. In these files, enter the
hostnames of all the hosts as they appear in reverse
lookups.On each host, create
/etc/ssh/ssh_known_hosts
. This file must
contain the host keys of all the hosts involved, under the names
you used in the previous item. The easiest way to do this is to
connect to all the hosts using the right names. After doing that,
the user account that made the connections will have all the
correct entries in its
~/.ssh/known_hosts
file. Simply transfer the entries to the system file.
After the previous steps are carried out on all the hosts, all
ordinary users should be able to use
ssh
back and
forth between all the nodes with no other authentication. However,
this is not true for the
root
user; she still
needs user key or password authentication. Trusting a remote
root
is far more serious than trusting a mundane
remote user.
The RSA algorithm has become the
de
facto
standard used in SSH and is employed by default,
although it is possible to use additional algorithms. When it comes
time to save the key you generate using RSA, you can use any name you
wish. However, most people stick to the defaults:
- ~/.ssh/id_rsa
The name of the file that contains the private key. This
file should be readable and writable only by the owner and no
one else. If anyone else were to obtain a copy of this file, he
would be able to decipher all communications encrypted by your
copy of SSH.- ~/.id_rsa.pub
The name of the file that contains the public key. You can
give this key to anyone you wish. Individuals will import this
key into their keychains. Once a user imports this key, they can
decipher encrypted text or files that you send to them.
When SSH first starts after installation, it will create a
key pair, namely
/etc/ssh/ssh_host_rsa_key
and
/etc/ssh/ssh_host_rsa_key.pub
, assuming that
the server is using the default RSA algorithm. This public key always
has a
.pub
ending, and resides in the
/etc/ssh/
directory. The SSH server on your system
uses this file to authenticate itself to anyone who logs on. The
ssh-keygen
command can be used to view the contents
of the public key file:
$ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub1024 98:2g:h8:k9:de:9f:fg:90:34:v3:35:3j:26:24:26:7k ssh_host_rsa_key.pub
If the server is using the DSA algorithm, the key names will be as
follows:
/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_dsa_key.pub
On the Exam
Make sure that you know the syntax for the-toption of
ssh-keygen
. Make sure that you understand the
differences in filenames created between specifying thedsaand the defaultrsaarguments to the-toption.
ssh-agent
makes it practical to use
passphrases on your private keys. The principle is to use
ssh-agent
to add your keys to a background agent on
the system that will hold them in escrow. You give your passphrase only
once, when you add the key. The agent will give the keys out to other
processes owned by you that request the keys. You should be aware that
the
root
user can also request the keys without
your noticing, so you must trust the
root
user.
The process is quite simple; start the agent, and then add the
passphrase you used to create the key:
$eval `ssh-agent`Agent pid 11487
$ssh-addEnter passphrase for /home/janl/.ssh/id_dsa: passphrase
Identity added: /home/janl/.ssh/id_dsa (/home/janl/.ssh/id_dsa)
By default, all your keys will be added. If several of your keys
have the same passphrase, they will all be added without further
questions. If they have different passphrases,
ssh-add
will be prompted for them. If you include a
file on the
ssh-add
command line, the key in that
file will be added and the command will not prompt for keys.
ssh-agent
works by setting two environment
variables:SSH_AUTH_SOCK, which names
the socket on which to communicate with the agent, andSSH_AGENT_PID, which makes it easy to kill the
agent. That is also why the PID (process ID) shows up in the previous
listing. The agent emits a shell script that, when evaluated, sets those
variables correctly.
Since using passphrases makes remote logins immeasurably more
convenient, it may be a good idea to make it simple for your users to
use passphrases by starting
ssh-agent
whenever they
log in. However, the users’
.bashrc
or
.login
scripts are not a good place for the
command, nor is the system
/etc/profile
, because
you don’t need the command to run every time a new terminal is started.
A good place to put it is in the system-wide
Xsession
scripts. Exactly which script is used to
start an X session depends on which distribution and which desktop
people use (KDE, GNOME, classical X, their own custom session). But on
Debian-based and Red Hat-based systems, there are standard ways to do
it.
On Debian-based systems, if you putuse-ssh-agenton a line by itself in
/etc/X11/xdm/xdm.options
, anyone who later logs in
with the X Window System will cause the script
/etc/X11/Xsession.d/90xfree86-common_ssh-agent
to
run. It is reproduced here for convenience:
STARTSSH=
SSHAGENT=/usr/bin/ssh-agent
SSHAGENTARGS=
if grep -qs ^use-ssh-agent "$OPTIONFILE"; then
if [ -x "$SSHAGENT" -a -z "$SSH_AUTH_SOCK" -a -z "$SSH2_AUTH_SOCK" ]; then
STARTSSH=yes
if [ -f /usr/bin/ssh-add1 ] && cmp -s $SSHAGENT /usr/bin/ssh-agent2; then
# use ssh-agent2's ssh-agent1 compatibility mode
SSHAGENTARGS=-1
fi
fi
fi
if [ -n "$STARTSSH" ]; then
REALSTARTUP="$SSHAGENT $SSHAGENTARGS $REALSTARTUP"
fi
This script first looks for the system-wideuse-ssh-agentsetting, then very carefully
checks whether any of the
ssh-agent
-related
variables are set already, because if they are set, an agent should
already be running. Finally, it redefinesREALSTARTUPso that the agent will be started
later in the Debian scripts. The script could just as well have runeval 'ssh-agent'directly.
On Red Hat–based systems, you can accomplish the same effect by
adding the
preceding
script to
/etc/X11/xinit/xinitrc.d
, but it should be changed
to run the agent directly, as Red Hat–based systems do not set up all
the environment variables that Debian-based systems do. In most versions
of Linux, the agent is started
automatically
. This includes, for example,
all recent versions of Ubuntu and other Debian-based systems.
But none of these automated systems adds any keys to the agent.
That means that users will still be prompted for a passphrase. Users can
run
ssh-add
(perhaps in their
.bashrc
files) and enter their passphrases once
into a shell terminal each time X starts.
It may be a good idea to doctor the automated X setup further with
an
ssh-add
command. If run without a terminal,
ssh-add
pops up a graphical passphrase input
box.
On the Exam
You may be asked to provide the proper syntax for making sure
ssh-agent
is running (which iseval `ssh-agent`). Also be ready to show how
to use
ssh-add
after the user has generated a
key.
OpenSSH respects
TCP wrapper configurations, described in
Chapter 23
.
sshd
, like the Linux
login
program, denies logins when the file
/etc/nologin
exists. When remotely maintaining
hosts in a way that may disrupt user activities, you should create this
file with a helpful explanation of what is happening. This will stop all
nonroot logins by any method, so you can do your maintenance
undisturbed. The file is usually created by the
shutdown
command as well, to keep users from
logging in while the machine is shutting down. The file is removed after
a complete boot:
#cat >/etc/nologin
If there is any reason to suspect that your maintenance work can
disconnect you or break the login mechanism, you should keep multiple
login sessions open while doing the work. Test logging in again before
closing them. Otherwise, doing a tiny PAM change that breaks all
authentication could force you to reboot the machine into single-user
mode to recover.
Consider scheduling an
at
or
cron
job to remove
/etc/nologin
at a particular time, in the event you
log yourself out. Such a job can be handy when restarting
sshd
from a remote location as well.
