OpenSSH Automatic Login
Overview
OpenSSH
provides a mechanism to use the Digital Signature Algorithm
to provide an alternative to manually typing in a password when
logging in to a remote machine. This is quite convenient, and
I believe more secure than typing in the password, as, among
other things, the password characters are sent one at a time
to the remote machine, so anybody watching the traffic can infer
some details of the password (such as the number of characters!).
This automatic login also applies to
scp
and thus makes that program more convenient.
This method applies to
OpenSSH
using protocol version 2. I have also used this with the original
ssh, but don't have notes about the steps involved. I have had
OpenSSH and ssh operate with one another to perform automatic authentication,
but have no details of how I did that!
This process involves two machines:
-
a client machine
client.example.domain,
which is the one from where the connection and login is started.
-
a server machine
server.example.domain,
running the ssh daemon, and to where the login attempt is directed.
This is a one way operation, so you need to repeat these steps
from the server machine if
you want to have automatic login from the server to the client.
Note that this is not necessarily a desirable idea, for instance
if the server is a firewall machine, you probably do
not
want automatic authentication on internal machines, as this simply helps
somebody who has broken into the firewall machine.
Creating Keys
On the
client.example.domain
machine,
user1
runs the command
ssh-keygen -t dsa
to generate the public and private keys, using the DSA algorithm.
I used all the default values, and no pass phrase. This is
less secure than using a pass phrase, but is more convenient.
Your call as to the risk/benefit to you. [If you use a pass phrase,
you will be prompted for it each time you use
ssh
or
scp
which does rather negate the effect of automatic login. However,
it does mean that compromise of your password on the client, or
somebody with the root password (administrator access on Windows),
does not gain access to other machines using your ID.]
The above creates a pair of files in the
~user1/.ssh
directory. These are the public
(id_dsa.pub)
and private
(id_dsa)
keys which ssh uses for authentication. The public key needs to be
replicated to all servers where you wish to login. The private
key is
used on the client machine only
and should not be copied around. It
must
be kept private, and to enforce this, ssh will refuse to use it unless it is
readable (or readable and writable)
only by the owner
(i.e. mode 400 or 600). The owner of the file
must be
user1.
Distributing The PUBLIC Key
Copy the file
id_dsa.pub
to the
server.example.domain
machine (e.g. by using scp) and add it to the file
~user1/.ssh/authorized_keys2
file. If this file exists, add the new data to the end; otherwise create
the file mode 644. The safest way to do this is to use the commands
cat id_dsa.pub >> ~user1/.ssh/authorized_keys2
chmod 644 ~user1/.ssh/authorized_keys2
Note that the
~user1/.ssh/authorized_keys2
file consists of very long lines, one line per client machine
configured to automatically login to this machine. Using a text
editor with line and/or word wrap will split these long lines, and make the
file contents useless!
And that's it.
Logging In As A Different User
If
user1
wants/needs to login to the remote machine as
user2
the command to use is
ssh user2@server.example.domain
Adding
user1's
public key to the
~user2/.ssh/authorized_keys2
file on
server.example.domain
allows
user1
to login on the remote machine as
user2
without being prompted for a password.
Update
The file
~/.ssh/authorized_keys2
is not hardwired into ssh. It is the default, but Arch linux, at least,
changes the default by dropping the 2, that is, as installed, the file is called
~/.ssh/authorized_keys.
This is set in the
/etc/ssh/sshd_config
file, with a comment that both file names are checked by default, but
Arch linux overrides the default and specifies the shorter name.
So, if you apply the above steps, and it does not work, check the settings
of the file
/etc/ssh/sshd_config
on the
server
machine. Either change the config file, or rename
~/.ssh/authorized_keys2
to
~/.ssh/authorized_keys