PublicKeyAuthentication has a weakness: if your private key is stored unprotected, anybody who gains access to your computer will be able to use your credentials to prove his identity and pretend to be you, gaining entry to machines that he should have no access to. Therefore the private key is stored to disk encrypted with a passphrase. To use the key, the SSH client must decrypt it, so it has to prompt you for your passphrase.
This makes PublicKeyAuthentication less convenient than password authentication: every time you log in somewhere, you have to type a long passphrase rather than a short password.
DO use passphrases. It's very tempting to use a passphraseless key so that "you don't have to type in a password every time". Instead, read on.
Authentication agents provide a solution to this. OpenSSH's agent is called ssh-agent(1), PuTTY's is called Pageant. Typically, you launch the agent when you log onto your local machine, which prompts you for the passphrases of any keys you have. The agent then remains persistent and provide your credentials to any client that needs them, so you will no longer be prompted for the passphrase. When you log out, the agent shuts down.
Another good option for a 'trusted' box is keychain which will allow you to run cronjobs over ssh even when you are logged out.
NOTE: Do not run an agent on hosts you do not trust. Their SuperUser can then steal your keys.
This is what ssh-keygen(1) is for. Use a SSH2 key if at all possible.
ssh-keygen -t dsa
- or
ssh-keygen -t rsa
If you accepted the defaults for ssh-keygen(1) you should have two new files in /.ssh, id_dsa and id_dsa.pub (or rsa..)
The .pub file is your public key, you need to upload it to all remote hosts that you want to use Keys with.
You need a .ssh directory in your home on the remote machine. This directory must not have permissions set to more than 700. Depending on whether you're using SSH1 or SSH2, keys go into .ssh/authorized_keys or .ssh/authorized_keys2, respectively (rename the file), which must have its permissions set to no more than 0600. Obviously the directoriy and these files must be owned by the user they belong to. If the permissions are wrong, SSH will refuse to read them (without telling you, unfortunately - it only cries to syslogd(8)). Debian provides a ssh-copy-id(1) program which does all this automagically. Just say
ssh-copy-id hostname
You can tell sshd(8) to allow a certain key to only be used by certain hosts or for certain activities. A brief summary of the available options is below. See sshd(8) for the more extensive documentation. These options are specified as a set of comma seperated options before the key in the authorized_keys file. Spaces are not allowed in options unless they are surrounded by double quotes.
This will only allow this key to be used from localhost and hosts in the .example.com domain. You can also prefix a glob with a ! to negate it.
Using the command keyword you can specify a single command to be executed when the key is used to login, any other command specified by the user will be ignored at the ssh session will end once the command specified in the authorized_keys file has completed.
Would allow someone to login and setup port forward to ports 80 and 25 on host 10.2.1.56
ssh-agent(1) is designed to run as an ancestor process to any ssh(1) session you wish to manage keys for. The preferred mode of operation (although there are other ways) is to invoke ssh-agent(1) with a program as its argument, which will then be spawned by the agent. This might be a window manager, your shell, or something of the sort. As soon as you exit that program your authentication details get cleaned up and the agent exits.
So we have a something along the lines of, say,
/usr/bin/ssh-agent -- /usr/X11R6/bin/twm
in .xinitrc.
When using xdm(1)? or another display manager, it should be configured appropriately to use a call as in the line above, rather than calling your window manager directly.
Pilfered from the fine manual:
if [ -x /usr/bin/ssh-agent -a -z "$SSH_AUTH_SOCK"? ; then
exec /usr/bin/ssh-agent $0
fi #
# /usr/bin/ssh-add < /dev/null & exec /usr/X11R6/bin/twm
if [ -x /usr/bin/ssh-agent -a -z "$SSH_AUTH_SOCK"? ; then
exec /usr/bin/ssh-agent sh -c "exec -a '$0' -- $SHELL"
fi #
#
if [ -x /usr/bin/ssh-add? && ! ssh-add -l &> /dev/null ; then
/usr/bin/ssh-add
fi
The check for existing keys was added here because in contrast to your .xinitrc, .bash_profile is typically executed quite frequently - f.ex, for every xterm(1) you open.
Under Debian 3.0 (woody), and possibly others, ssh-agent is normally set up to run like this anyway. If you use one of the standard session options, it all works fine. However, if (as in my case) you run a custom setup (ie, have a heavily modified .xsession file), then the ssh-agent either doesn't get called for some reason, or it dies early. Using the above script should solve this.
AGENTFILE=/.agent.`hostname`.env
if [ -z "$SSH_AUTH_SOCK"?; then
if [ -f $AGENTFILE?; then
- load them
. $AGENTFILE > /dev/null
- make sure they're not invalid
if [ ! kill -0 $SSH_AGENT_PID > /dev/null 2>?; then
echo "Stale agent file found. Spawning new agent..." eval `ssh-agent | tee $AGENTFILE` ssh-add
fi
else
- no existing settings found, start new agent and save them
echo "Starting ssh-agent..." eval `ssh-agent | tee $AGENTFILE` ssh-add
fi
fi
In fact, it should easily be possible to merge these methods such that you get the benefits of both. I need to mull over the best way to do this. --AristotlePagaltzis
KEYS="id_dsa id_rsa identity insecure sourceforge"
delete_all_keys() {
ssh-add -D
}
add_all_keys() {
local OK_KEYS unset OK_KEYS for i in $KEYS; do
done echo Adding keys... ssh-add $OK_KEYS echo done
}
exec xscreensaver-command -watch | while read command arg; do
case $command in
LOCK)
delete_all_keys ;;
UNBLANK)
add_all_keys ;;
RUN)
echo "Changing screensaver ($arg)" ;;
BLANK)
- placeholder
;;
)
echo Unknown command: $command echo " with arg: $arg"
esac
done
Place this script somewhere in your PATH (eg. $HOME/bin/screenwatch) then start it from either your .xsession or your session manager (Gnome, KDE etc) with x-terminal-emulator -e "$HOME/bin/screenwatch"
To save a lot of more typing, you can forward ssh-agent(1) information with the -A option to SSH. You can thus keep all your credentials on a single machine. NOTE: Do not forward agent connections to hosts you do not trust. Their SuperUser can steal your keys.
.ssh/config convenience (see SSHNotes and ssh_config(5)) is achieved using !ForwardAgent? yes.
Part of CategorySecurity and CategoryNetworking
7 pages link to SSHKeys: