Editing SSH:Authorized Keys

<h4>Passphrase or not?</h4>  

If you use a passphrase, the key will not be usable unless you type the passphrase to make it available. 

 

 

 

Unless you have good reason to do otherwise, allow the key generator to use its default (rsa for ssh-v2 connections).<h3>Creating the key</h3>You can create a private/public key pair (in the files <code>~/.ssh/filename</code> and <code>~/.ssh/filename.pub</code>) that has no passphrase protecting the private key, by doing the following:

The two files created (<code>filename</code> and <code>filename.pub</code>) can then be used as described below.

 

If on the other hand, you'd like to protect the private key file with a passphrase (which will be needed to be typed at any client that wants to use the key pair):

and you'll be prompted for a passphrase.  This has no limitation on length.  All the normal advice about non-guessable passwords may reasonably be applied to it, although it's possible that a suitably long passphrase consisting of dictionary-attackable words can be just as secure as a short passphrase of random characters.<h3>What the private/public key files are for</h3>The private key is the secret one, not surprisingly.  It needs to be kept secure (not world-readable).  Only a client with knowledge of the private key can correctly respond to a challenge issued by a server that is using the public key.

If the private key is not passphrase protected, then the file containing it is particularly sensitive; even temporary exposure of your account to a third party could allow it to be copied and then used inappropriately.

If the private key is passphrase protected, then its vulnerability is lower;  an attacker would need a copy of the private key file, and <em>also</em> to observe your keystrokes typing the passphrase to your client program (or to have inserted a trojan version of the client program, or ...).

The public key does not need to be kept secret; there is no practical way of guessing the private key that will match it.  It is put in your <code>~/.ssh/authorized_keys</code> file on the machine that you want to connect to.   

 

There may be good reasons to keep the <code>authorized_keys</code> file protected from world-readability (it may contain directives as to what machines may use a given key or what commands will be run in response to the use of a given key, which may be sensitive information) but protecting the public key is not one of them!

=== Setting up an authorized_keys file ===

Once you've created your key pair, you can insert the public half of it into your authorized_keys file on computer "X".  A client on computer "Y" that knows the private key can then authenticate to your account on computer "X".

 

So, on the machine you want to log into, you should add a line to your <code>~/.ssh/authorized_keys</code> file that contains exactly the single line that was created in the <code>filename.pub</code> file (for whatever choice of "filename" you made).

 

For example, we might wind up with a <code>.ssh/authorized_keys</code> file that looks like:

 

except that I have deliberately split the single long line to make it more readable.

 

On the machine you want to log in <em>from</em> you would run

 

</pre>

 

(for appropriate values of "filename" and "remotehost") thus telling slogin to look in the private key file.

 

The connection would then be made without any further authentication being necessary (although <code>slogin</code> would prompt for a passphrase if the private key were protected by one.

 

<h3>authorized_keys: restricting access</h3>

 

What we have described above allows any remote host where the private key is known to make any kind of ssh connection (login, remote command execution, port forwarding, etc.) to the computer on which the <code>authorized_keys</code>. There are a number of things that can be done in an authorized_keys to further restrict access.  These are all arranged by prefixing the line containing the public key by a single "phrase" of comma-separated options (see below for an example of what this winds up looking like)

 

 

If the options phrase at the beginning of a line contains the keyword <code>from="string"</code> this restricts the use of the key on that line to sessions that originate from hosts that match <code>"string"</code>. Examples might be

 

<pre>

</pre>

 

The hostname used will need to be the hostname reported when the IP (network) address of the connecting machine is looked up in the DNS. The <code>*</code> wildcard matches one or more characters, while the <code>?</code> wildcard matches a single character.  If the connecting hostname matches an entry prefixed by '!', then it will be rejected.

 

 

If the options phrase at the beginning of a line contains the keyword <code>command="string"</code>, then any ssh connection that authenticates using that particular key will <em>only</em> run the command specified, even if the command line it was given specified another command.

 

 

Various ssh facilities may be suppressed by adding the following options to the options phrase at the beginning of a line:

 

</pre>

 

When heavily restricting an ssh key in circumstances where entirely automated remote connections are desired, it is generally a good idea to apply all of these options unless the command being run actually needs one of these facilities.

 

 

This example file has two entries.  Note that there is no whitespace in the list of options; they are separated by commas, and strings are double-quoted (eg in the argument to <code>from=</code>).

 

</pre>

 

Note that in reality, such a file would only have two uncommented lines, both of them very long.

 

 

 

 

First, check that you really have put the matching public key in the <code>~/.ssh/authorized_keys</code> file on the machine you're trying to connect <em>to</em>, and that you're telling your ssh client about the correct private key using the <code>-i</code> argument.

 

 

The public key goes in the destination host's <code>~/.ssh/authorized_keys</code> file.

 

 

Some clients and servers are very picky about file permissions on their configuration files.  Among possible objections they may have are:

</ul>

 

 

 

Sometimes, however, they'll both decide to prefer v1.5 even though they both support v2.  In such cases, your ssh-rsa key (which is v2 compliant) won't work.

 

<em>Solution</em>:  Force v2 by using the <code>-2</code> flag to ssh or slogin

 

 

The client can be configured to request particular authentication mechanisms in a particular order.  A non-standard local configuration file can therefore potentially lead the client to prompt for a password before in a particular ordera successful keybased authentication can occur.

 

The following options passed to ssh or slogin should compel the client to only offer/try the key-based authentication mechanism only: