Automatic login without prompting for password.
To securely manage a dedicated sever from a remote location, a desktop computer with secure access
can send or synchronize file updates between its local file system and the server. File transfer
with ftp can be done, but the process can be tedious and prone to typing errors. ftp can pose
another potential issue since it sends information including passwords in clear text.
It is desirable to be able to distribute updates from the desktop computer to the server in a
more secure and automated fashion. If you have frequent updates and have more than one dedicated
servers to manage, this automated task will become a real time saver since there is no manual
intervention, thus less typing errors.
This section shows how to send a file to a dedicated server using scp (secure copy using ssh
protocol). Since scp will ask for a login password, we need to come up with a secure mechanism
so that the server receiving the transferred file can automatically authenticate and recognize
the desktop computer and will no longer request the login password.
Not sending the login password will secure the remote management of your server. But it is
absolutely essential that the access to the desktop computer has to be completely secure,
since anyone with access to this desktop computer can login your dedicated server without
the need to provide a password.
Since we change the secure shell setup so that it does not ask for a login password, it is
recommended that you should disable root login and limit the number of unsuccessful logins.
Without root login, it is much harder for an intruder to make any attempt to log in your
dedicated server, since he has to supply a correct login user name first, and certainly
the credentials from his desktop computer will not match the authorized keys on your
dedicated server, hence again prompting for a password.
Change or add the following lines to the file /etc/ssh/sshd_config
restart the ssh service (service sshd restart
). You must be absolutely
certain that no mistakes can be made to the configuration file of the sshd service, since
if the sshd cannot be restarted successfully, you will no longer be able to log in your
dedicated server via the secure shell. If you are not sure regarding the changes, try it
on a local test server to sort out all issues first.
You need to create a public key that has the credentials of the desktop computer (client)
that you plan to use to log in the dedicated server. The command ssh-keygen
can quickly generate the key in the subdirectory .ssh as in the following example. Note that
you can leave the passphrase empty.
brucelee ~ % ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/brucelee/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/brucelee/.ssh/id_rsa.
Your public key has been saved in /home/brucelee/.ssh/id_rsa.pub.
The key fingerprint is:
Copy this public key generated from your desktop computer to your server. You can do this chore
with any file transfer method or via scp as following.
scp .ssh/id_rsa.pub firstname.lastname@example.org:~/.ssh/newkey
Once the public key is placed on the server, log in to your server and append or rename the
public key to the file authorized_keys
. Appending is recommended if you
plan to manage the dedicated server from more than one desktop computers. The file
authorized_keys contains the required credentials for each desktop computer.
The following step is required each time adding a new desktop computer (that needs to
suppress password) to the server's list of computers to support.
cat newkey >> authorized_keys
chmod 600 authorized_keys
Once authorized_keys is updated, your server will not prompt for passwords from computers whose
credentials (public key) match the ones in this file. This applies to both ssh and scp.