水曜日, 11月 29, 2006

crypto notes

To use cryptographic authentication, you must first generate a key pair for yourself, consisting of a private key (your digital identity that sits on the client machine) and a public key (that sits on the server machine). To do this, use the ssh-keygen program to produce either a DSA or RSA key. The OpenSSH version of ssh-keygen requires you to specify the key type with the -t option (there is no default):

$ ssh-keygen -t rsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/rfmonk/.ssh/id_rsa): press ENTER
Enter passphrase (empty for no passphrase): thanks2thebookbyoreillyonSSH
Enter same passphrase again: yadayadayada....
Your identification has been saved in /home/rfmonk/.ssh/id_rsa.
Your public key has been saved in /home/rfmonk/.ssh/id_rsa.pub.
The key fingerprint is:
13:ba:05:87:a7:87:ad:26:b4:ce:54:84:bc:61:39:17

Normally, ssh-keygen performs all necessary mathematics to generate a key, but on some operating systems you might be asked to assist it. Key generation requires some random numbers, and if your os doesn't supply a random-number generator, you may be asked to type some random text or wiggle your mouse around. ssh-keygen uses the timings of your keystrokes to initialize its internal random-number generator.

After creating the key pair on the local host, you must install your public key
in your account on the remote host. A remote account may have many public keys installed for
accessing it in various ways.

Create or edit the remote file ~/.ssh/authorized_keys and append your public key—i.e., the contents of the id_dsa.pub file you generated on the local machine. A typical authorized_keys file contains a list of public-key data, one key per line.

OpenSSH includes a program, ssh-copy-id, that installs a public key automatically on a remote server with a single command, placing it into ~/.ssh/authorized_keys:

ssh-copy-id -i key_file [user@]server_name
For example, to install the key mykey in the rfmonk account on orion.extremeboredom.net:

$ ssh-copy-id -i mykey rfmonk@orion.extremeboredom.net

You don't need to list the .pub extension of the key file; or more specifically, you can provide either the private or public-key file, and the public key is copied to the remote server. In order for the copy to take place, you'll need an account on the remote machine, and you'll need to authenticate somehow. If you've never set up public-key authentication on server.example.com before, you'll be prompted for your login password. ssh-copy-id is convenient, but it has some subtle issues: If you have no authorized_keys file on the remote machine, ssh-copy-id creates one containing your new key; otherwise, it appends the new key. If you do already have a remote authorized_keys file, and it does not end with a newline character, ssh-copy-id blindly
appends your new key onto the last public key in the file, with no newline between them. This effectively corrupts the last two keys in authorized_keys. Moral: always make sure authorized_keys ends with a newline. (This is easy to overlook, especially when running OpenSSH on Winblows. The syntax of ssh-copy-id is similar to that of scp, the secure copy program, but there's an important difference: scp follows the hostname of the remote machine with a colon. Don't use a colon with ssh-copy-id or you'll get an error message, "Name or service not known," as the hostname lookup fails.

Regardless of which SSH implementation you use, make sure your remote SSH directory and
associated files are writable only by your account
# OpenSSH
$ chmod 755 ~/.ssh
$ chmod 644 ~/.ssh/authorized_keys

Public-key authentication is more secure than password authentication because: It requires two secret components—the identity file on disk, and the passphrase in your head—so both must be captured in order for an adversary to access your account. Password authentication requires only one component, the password, which might be easier to steal. Neither the passphrase nor the key is sent to the remote host, just the authenticator discussed earlier. Therefore, no secret information is transmitted off the client machine. Machine-generated cryptographic keys are infeasible to guess. Human-generated passwords are routinely cracked by a dictionary attack. A dictionary attack may be mounted on the passphrase as well, but this requires stealing the private-key file first. A host's security can be greatly increased by disabling password authentication altogether and permitting only SSH connections by key.

0 Comments:

コメントを投稿

Links to this post:

リンクを作成

<< Home