OpenSSH Automatic Login
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
and thus makes that program more convenient.
This method applies to
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:
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
want automatic authentication on internal machines, as this simply helps
somebody who has broken into the firewall machine.
a client machine
which is the one from where the connection and login is started.
a server machine
running the ssh daemon, and to where the login attempt is directed.
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
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
directory. These are the public
keys which ssh uses for authentication. The public key needs to be
replicated to all servers where you wish to login. The private
used on the client machine only
and should not be copied around. It
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
Distributing The PUBLIC Key
Copy the file
machine (e.g. by using scp) and add it to the file
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
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
wants/needs to login to the remote machine as
the command to use is
public key to the
to login on the remote machine as
without being prompted for a password.
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
This is set in the
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
machine. Either change the config file, or rename