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 and 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.

LoginGraceTime 1m
PermitRootLogin no
MaxAuthTries 3

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/
The key fingerprint is:
7a:0a:78:61:39:b2:39:1c:40:6b:3a:1c:a8:d1:d7:22 brucelee@mydesktop.localdomain

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/ brucelee@

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
rm newkey

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.