Some ssh tips
Part of Guide to the Local System.
This version 20091116, L.S.Lowe.
These notes were made for OpenSSH version 3.6.1p2 on a
Red Hat Enterprise Linux 3 system, or SL3 system, and
for version 3.9p1 on a SL4 system.
On other systems, the file placements may be
different, and I suppose there might be different defaults.
Using user-key authentication
For an individual user, login without using a password is best done using
ssh keys, protected by a pass-phrase.
(If you're the administrator and want password-less login but
don't want to give all users individual keys,
then you can consider using host-based authentication: next section).
For individual user-keys, then on the client machine
(where you are calling from)
first you generate your public and private key pair using the
ssh-keygen command, for example:
ssh-keygen -t rsa [1024 bits is default in RHEL4/SL4 and earlier]
or ssh-keygen -t rsa -b 2048 [2048 bits is default in RHEL5/SL5]
When prompted for a pass-phrase, enter a suitably obscure string
(that you can remember!).
The pass-phrase is used to encode your private key before it is stored
in a private file.
If you use a null pass-phrase,
then that's good-enough security if all the hosts you are accessing
are on a private network behind your client host,
but otherwise you run the risk that, if your system is compromised,
someone could steal the contents of your private key file,
and then use it to login as you, to misuse and maybe compromise the hosts
that you access using that key.
Then using the contents of file $HOME/.ssh/id_rsa.pub
on your client
(or other public key file, if you didn't follow the ssh-keygen above exactly),
append those contents to file $HOME/.ssh/authorized_keys
on your intended server.
One simple method of doing this is (from the client machine):
ssh firstname.lastname@example.org 'cat >> .ssh/authorized_keys' < ~/.ssh/id_rsa.pub
Of course, if your client and server share a home file system, then
you can do that append directly:
cat >> ~/.ssh/authorized_keys < ~/.ssh/id_rsa.pub
If on that server you want to limit what client computers can use that key
(as a good security measure) then prefix that authorized_keys entry with from=myclient;
other prefixed restrictions such as
command=, environment=, no-port-forwarding, no-X11-forwarding, no-agent-forwarding, no-pty,
see man sshd for more information.
That server file might contain several different public keys
if you want it to.
During a login session, if a ssh-agent is started automatically by
your system (as is normal for a GUI session like KDE or Gnome),
then you just need to enter your pass-phrase once for that session,
by running the command ssh-add and providing it.
After that, any ssh commands you issue will use the agent
rather than asking you for the pass-phrase.
If you do not get prompted for a pass-phrase, only a password ....
If you do not get prompted for a pass-phrase even though you think you've
set one up, then there are various possibilities:
one is that your authorized_keys file is not accessible on the server;
another is that your public-key has not been found in the authorized_keys file.
If you get prompted for a pass-phrase and then a password ....
It can happen that you get prompted for your pass-phrase
and you enter it correctly,
but then you get prompted for a password.
One possible reason for that is that your identity on the server is
for example for a file-based authentication scheme on the server,
perhaps your id may exist in /etc/passwd but not in /etc/shadow.
It's a requirement that a shadow password entry exists for you on the server,
even if it only exists as an entry with a * password.
Otherwise the server administrator will see entries in the log messages
such as "could not get username from shadow".
Another possible reason is that the shadow password entry exists but indicates
that your account or password has expired.
To summarise, for user-key authentication to work, it's not important that
you actually have or know the password for your id on the server,
but it's important that the ssh server can access a shadow password entry for you
and verify that it's not expired.
AFS and Kerberos quirks
Note that if your remote system has Kerberos-style authentication and AFS,
such that AFS permissions take precedence over the Unix file permissions,
then you might have to put your private key file in private/.ssh/,
and public key and authorized_keys files in public/.ssh/,
and put appropriate links to them in your .ssh/ directory,
where private and public are directories with the corresponding AFS permissions.
If you authenticate using an ssh-key on such a system, then this
on its own may not give you full access to your AFS files.
Consult local documentation.
Using host-based authentication (protocol version 2)
In host-based authentication, user credentials such as password or
user key do not have to be presented, explicitly or implicitly.
It's the ssh equivalent of the deprecated rsh protocol,
though with a little bit more security.
The userid on both systems has to be the same,
otherwise you are requested for a password.
The server has to trust the client not to fake the userid, nor
to be more vulnerable to attack;
this is best met if the administrator(s) for those systems are the same.
We assume here you're starting from a standard default configuration setup.
To use host-based authentication,
the following need to be in place,
otherwise you will be prompted for a password:
- On the server host, file /etc/ssh/shosts.equiv needs to have a line containing the full hostname for each required client host.
You can alternatively use filename /etc/hosts.equiv but bear in mind that
that filename is also used by rlogin/rsh/rcp and PBS protocols.
Never put a userid after the hostname: it would give that remote userid
the ability to logon as anybody.
Individual users could use $HOME/.shosts instead: that would require IgnoreRhosts no below.
(For the root user to use this method, $HOME/.shosts seems to be a requirement).
- On the server host, file /etc/ssh/ssh_known_hosts needs
to have a line containing the full hostname,
the key type (such as ssh-rsa), and the ssh public key value,
for each required client host.
(The ssh-keyscan command is useful for this).
- On the server host, file /etc/ssh/sshd_config needs
to have the following in effect
(the first line is essential, the others provide better security, and also
prevent the user from specifying a different client-side userid):
Remember to restart the sshd daemon after making those changes.
- On the client host, file /etc/ssh/ssh_config needs to be readable by all, as usual, and needs to contain the following:
The first line has to appear in the main body of the file.
The second line can appear in the main body of the file,
or in a Host subsection of the file,
or can be supplied in a ssh command -o option.
If that second option is in effect but not the first one
(and you are not root),
then the ssh client will issue the message
ssh-keysign not enabled in /etc/ssh/ssh_config
and this sort of authentication will fail.
I guess this is because the ssh client works in user-mode,
but for hostbased authentication needs to use a helper program ssh-keysign
to obtain the client's private key with which to encrypt some shared data,
so that the server can decrypt that data with the client's public key,
and so prove to the server that the client host really knows the private key.
But that's just a guess!
Helper ssh-keysign needs to be setuid/setgid to
whatever uid/gid the client private key is readable in: usually root.
- On the client host, the public key files /etc/ssh/ssh_host*key.pub
need to be readable by all, as usual,
or at least readable by the client userid.
(The corresponding private-key files should be readable by root only, as usual.
This is how the system normally sets them up, anyway).
Using host-based authentication (protocol version 1)
I believe the only difference here is to
use RhostsRSAAuthentication for protocol version 1,
wherever HostbasedAuthentication is used for protocol version 2.
But nobody uses protocol version 1 anymore, for security reasons.