Help answer threads with 0 replies.
Go Back > Articles > Jeremy's Magazine Articles
User Name


By jeremy at 2004-09-30 13:43
Using Keys with SSH
by Jeremy Garcia

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 ( 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, via ssh, simply type:

% ssh
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/, 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/, 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 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 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.

Typing ssh

by kvedaa on Fri, 2004-10-08 21:18
I agree that there is some added risk to using public key authentication with SSH, but this can be mitagated by keeping your private key secure.

I think that this is a better solution then depending on expect scripts, where if you do not want to type in all your passwords in each time you run the script you must embed the passwords in either the script or some other reachable data file.

I am unaware of other options that will allow an administrator to run scripts on remote systems. If your system is too important to risk one of the above situations you can of course avoid both of these, but it means that you will have to manually login these systems when you have work to do, which is workable if you only have a few machines to work with, or if you simply are a glutton for punishment.

by Luskacik on Fri, 2004-10-15 13:59
I have troubles to work with keys authentification for users.
For root it is going well, but I neet set "PermitRootLogin no" in /etc/ssh/sshd_config it don't work for users.
I think, that it is security requirement to set PermitRootLogin to no.
Is it possible to work also for users?


Of course it is possible to log like another user.
# su localuser
$ ssh remoteuser@remotehost

Sorry for so stupid question above. :-)

by sewer_monkey on Tue, 2005-11-01 10:17
I don't mean to be splitting hairs here, but I'd like to make the following corrections nonetheless:

The line:
[cpde]% ssh-keygen -t dsa[/code]

has an incorrectly spelled [code] tag, and as such the code box is not being rendered. I don't think this was intentional, just a simple typo on Jeremy's (or whoever posted this) part.

Secondly, I'd like to comment about the following statement:

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.
This quote seems to suggest that the private key is actually transmitted to the remote machine (so that the remote machine can use it as part of the authentication process), which is not the case. I think this paragraph would be better rephrased as something like this:

When you attempt to login in to a remote machine, the (local) private key and the (remote) public key are used together by the local machine and the remote server respectively as part of the authentication process. If the keys match, the remote server permits and establishes your login or file transfer session.
Just my 2 cents...


All times are GMT -5. The time now is 12:12 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration