Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
If you've administered any remote Linux machines, then you're probably already familiar with SSH. As you may know, SSH provides secure, encrypted network communication. Utilities like ssh and sftp, which are based on SSH, protect remote login sessions and file transfers, respectively, and have largely subsumed similar but insecure and unencrypted utilities such as ftp, rlogin, rsh, rcp, and telnet. (In fact, if any of your systems still use telnet, put down this magazine at once, go disable telnet, install and enable SSH, and then continue reading.)
The ssh utility is easy to use, but typing passwords again and again is a hassle, and precludes scripting remote access. This month, let's explore a better way to use SSH, using OpenSSH (http://www.openssh.org) and SSH protocol version 2. (If you're using a different SSH suite or protocol version 1, some of this month's instructions may not apply or may need to be modified to suit your version of the software.)
To connect to a remote machine, say hosta.example.com, via ssh, simply type:
% ssh hosta.example.com
Typically, the remote machine prompts for a password, but you can also configure the remote machine to use public key authentication.
Public key authentication involves a pair of keys: a private key and a public key. The private key is retained on your local system (where it's arguably very safe), and the public key is propagated to remote systems. When you attempt to login in to a remote machine, the (local) private key and the (remote) public key are "combined" by the remote server and verified. If the keys match, the remote server permits and establishes your login or file transfer session.
For SSH protocol version 2, the DSA algorithm is used to generate the private and public keys. The private key is generated into $HOME/.ssh/id_dsa, and the public key is created in $HOME/.ssh/id_dsa.pub, both on the local host. To use the public key with a remote host, you must append it to $HOME /.ssh/authorized_keys on that host.
Let's go ahead and set that all of that up. First, generate the public and private keys with ssh-keygen, using the command:
[cpde]% ssh-keygen -t dsa[/code]
The command prompts for a passphrase (a password to protect your keys), which you can leave blank for now, and then creates $HOME/.ssh/id_dsa and $HOME/.ssh/id_dsa.pub, the private and public key, respectively.
Make sure to keep your private key private by changing its mode to "read/write by user only" via:
% chmod 600 $HOME/.ssh/id_dsa
Next, copy the id_dsa.pub file to the remote server you'd like to log into and append it to $HOME/.ssh/authorized_keys2 on that server. (If that file doesn't exist, you can simply rename id_dsa.pub to authorized_keys2.) After that file's in place, be sure to set its permissions with chmod 600 authorized_ keys2. If authorized_keys2 is readable by anyone other than you, ssh will refuse to match keys.
You should now be able to login to the machine without a password. If you're unable to login, retry using ssh -v, which prints debugging information. In some cases, the remote server may not permit public-key authentication.
Logging in without a password can be very useful. For instance, it allows you to automate backups and script the execution of remote commands.
With this convenience, however, comes a risk. Since access to the remote machine is now tied to your private key, a compromised key can compromise the remote machine. For an extra level of security, protect your private key with a passphrase. To use a passphrase with public key authentication, follow the exact steps as above, except fill in a passphrase when prompted during the creation of your keys.
If your situation requires you to remember a large number of passphrases, you'll eventually get frustrated having to remember a multitude of machine/passphrase combinations. Luckily, OpenSSH comes with a program named ssh-agent to help manage your keys.