|
[introduction] [setup] [use] [links]
Normally SSH requires a login password. This can be a problem if SSH is
to be used unattended, eg. in a batch or cron job. One way of removing the
password prompt is to use an identity file.
This provides a key that is recognised by the remote account and allows
automatic logon.
Note however that this key does not provide an AFS
token, so access to AFS directories will be as system:anyuser.
(If however an AFS token was available before running SSH, and an AFS-aware
version of SSH is used, then this token will also be available at the
remote site. However this doesn't help for repeating jobs unless some form
of token renewal is used.)
It should be emphasised that this method is the best of a bad lot.
Setting up automatic logins is inherently not very secure.
Using SSH passphraseless identity files is however secure against a
network sniff attack, and perhaps less trivially cracked by someone who has
gained access to the client account than explicit passwords saved on disk.
As an example, we will consider setting up a copy from SLAC to RAL
with a batch job at RAL (I have a script to simplify the setup of
repeating LSF batch jobs).
You can create the identity file using ssh-keygen at SLAC.
This will create two files, by default, identity and
identity.pub in your .ssh directory.
It will prompt for a
passphrase (twice), but you should enter an empty one (just press Return),
since the whole purpose of this exercise is to remove the necessity of
entering a passphrase.
Copy identity.pub to authorized_keys (also
in .ssh).
If you already have an authorized_keys file,
just append identity.pub to it (it's an ASCII file, so you can
do this with an editor, or
with cat identity.pub >> authorized_keys).
Copy the identity file to RAL - but make sure you keep it
secret (eg. use scp to copy it and store it in a secure
directory - see the next section for details).
Normally this file is stored in
a .ssh directory but may be called whatever you like.
It is important that the identity file remains secret. If anyone
found it out, then they would be able to login to your SLAC account.
If you store it on a local or NFS disk (NFS is less secure),
the file protection should
prevent anyone apart from the owner reading it, eg. with
chmod go-r .ssh/identity
On AFS, an ACL has to be setup for the whole directory (AFS ignores
most of the Unix file protection bits). Use
fs listacl .ssh
to list the ACL entries and remove any that allow other users access, eg. with
fs setacl .ssh system:authuser none
(and similarly for any other public entries).
Since the authorized_keys file has to be readable by the SSH
daemon, this can cause problems when it is in the same AFS directory as the
identity file. At SLAC this is solved by having authorized_keys
be a soft link to a publicly-readable directory.
To connect with SSH using the identity file, specify it with
the -i option, eg.
ssh -i $HOME/.ssh/identity tersk.slac.stanford.edu
If everything is working, this should log you into tersk
(though you may not have access to your AFS home directory, since this
doesn't necessarily give you an AFS token. This may cause some warning
messages as you log in, but don't worry.)
If the identity
file isn't recognised by the server (eg. it wasn't added
correctly to the authorized_keys file), no error message will
be displayed - it will silently fall back to the normal method and
you will be prompted for a password.
The -i option can also be specified with scp.
With rsync, the identity file has to be passed through to ssh.
This is handled automatically by the syncslac script
syncslac -i $HOME/.ssh/identity $BFROOTr/kanga/EventStore/ \
$BFROOT/kanga/EventStore/
SSH
BaBar Data Distribution
  /BFROOT/www/Computing/Offline/DataDist/ssh-idfile.html last
modified 27th March 2000 by Tim Adye, <T.J.Adye@rl.ac.uk>
|
