Tuesday, May 10, 2005
SSH
The "known hosts" list contains the public keys of host machines that you "trust" when using ssh or scp.
Automatic login
With any of the installations covered so far we can only establish an SSH connection provided we supply a password each time. It is possible to automate SSH connections by generating "passphrase-less" secure keys and modifying our connection settings to use the new keys. In general, I would only recommend this procedure if you have a specific requirement for automating file transfers, and you clearly understand the security implications.
Keys can be generated on the Windows client-side, using PuTTYGen, or on the server-side, using ssh-keygen. Either program will generate a public key file and a private key file. Different key file combinations can be generated for different SSH protocol versions. If you specify a blank "passphrase", then only the key files will be required to authenticate the connection, thereby allowing unattended connections. (If you include a passphrase you will benefit from a "doubly-secure" authentication, based on both the key and the passphrase.)
To use the keys, save the key files in a secure location on the client machine. Then copy the contents of the public key file into the file $HOME/.ssh/authorized_keys, (SSH protocol version 1), or $HOME/.ssh/authorized_keys2, (SSH protocol version 2), on the server machine. Finally, modify the PuTTY, WinSCP or TTSSH session details so that it uses the saved private key file, (making sure it also uses the correct protocol for the specified key). You will find the option to specify the Private Key File under the SSH settings.
Assuming you've got the right files in the right places, and the correct session settings, when you attempt to connect you should find that you can connect without supplying a password or passphrase.
If you are using Cygwin and the command-line ssh/scp versions, you can check the man pages for ssh to determine where you need to save your key files so that the ssh and scp commands will connect without requiring a password/passphrase.
This "passphrase-less" approach is reasonably secure, provided access to the client machine is restricted. However, if someone manages to steal your private key file, (which might not be that difficult on most Windows machines), your server account will be fully compromised.
How passwordless works
Using keys, together with a program called an authentication agent, SSH can authenticate you to all your computer accounts securely without requiring you to memorize many passwords or enter them repeatedly. It works like this:
In advance (and only once), place special files called public key files into your remote computer accounts. These enable your SSH clients (ssh, scp) to access your remote accounts.
On your local machine, invoke the ssh-agent program, which runs in the background.
Choose the key (or keys) you will need during your login session.
Load the keys into the agent with the ssh-add program. This requires knowledge of each key's secret passphrase.
At this point, you have an ssh-agent program running on your local machine, holding your secret keys in memory.
To install a public key into the "pat" account on shell.isp.com: This is done by editing a file in the SSH configuration directory: ~/.ssh/authorized_keys for SSH1 and OpenSSH or ~/.ssh2/authorization for SSH2.
For SSH1 or OpenSSH, create or edit the file ~/.ssh/authorized_keys and append your public key, i.e., the contents of the identity.pub file you generated on the local machine. A typical authorized_keys file contains a list of public key data, one key per line. The example contains only two public keys, each on its own line of the file, but they are too long to fit on this page. The line breaks inside the long numbers are printing artifact; if they were actually in the file, it would be incorrectly formatted and wouldn't work:
1024 35 8697511247987525784866526224505474204292260357215616159982327587956883143
362147028876494426516682677550219425827002174890309672203219700937187777979705864
107549106608811204142046600066790196940691100768682518506600601481676686828742807
11088849408310989234142475694298520575977312478025518391 my personal key
1024 37 1140868200916227508775331982659387253607752793422843620910258618820621996
941824516069319525136671585267698112659690736259150374130846896838697083490981532
877352706061107257845462743793679411866715467672826112629198483320167783914580965
674001731023872042965273839192998250061795483568436433123392629 my work key
These are RSA public keys: the first number in each entry is the number of bits in the key, while the second and third are RSA-specific parameters called the public exponent and modulus. After these comes an arbitrary amount of text treated as a comment.
For SSH2, you need to edit two files, one on the client machine and one on the server machine. On the client machine, create or edit the file ~/.ssh2/identification and insert a line to identify your private key file:
IdKey id_dsa_1024_a
On the server machine, create or edit the file ~/.ssh2/authorization, which contains information about public keys, one per line. But unlike SSH1's authorized_keys file, which contains copies of the public keys, the authorization file lists only the filename of the key:
Key id_dsa_1024_a.pub
Finally, copy id_dsa_1024_a.pub from your local machine to the remote SSH2 server machine, placing it in ~/.ssh2.
Regardless of which SSH implementation you use, make sure your remote SSH directory and associated files are writable only by your account:
(We make files world-readable and directories world-searchable, to avoid NFS problems. )
# SSH1, OpenSSH
$ chmod 755 ~/.ssh
$ chmod 644 ~/.ssh/authorized_keys
# OpenSSH only
$ chmod 644 ~/.ssh/authorized_keys2
# SSH2 only
$ chmod 755 ~/.ssh2
$ chmod 644 ~/.ssh2/id_dsa_1024_a.pub
$ chmod 644 ~/.ssh2/authorization
The SSH server is picky about file and directory permissions and may refuse authentication if the remote account's SSH configuration files have insecure permissions. [Section 5.4.2.1, "Acceptable permissions for user files"]
You are now ready to use your new key to access the "pat" account:
# SSH1, SSH2, OpenSSH; output shown is for SSH1
$ ssh -l pat shell.isp.com
Enter passphrase for RSA key 'Your Name': ************
Last login: Mon May 24 19:44:21 1999 from quincunx.nefertiti.org
You have new mail.
shell.isp.com>
Automatic login
With any of the installations covered so far we can only establish an SSH connection provided we supply a password each time. It is possible to automate SSH connections by generating "passphrase-less" secure keys and modifying our connection settings to use the new keys. In general, I would only recommend this procedure if you have a specific requirement for automating file transfers, and you clearly understand the security implications.
Keys can be generated on the Windows client-side, using PuTTYGen, or on the server-side, using ssh-keygen. Either program will generate a public key file and a private key file. Different key file combinations can be generated for different SSH protocol versions. If you specify a blank "passphrase", then only the key files will be required to authenticate the connection, thereby allowing unattended connections. (If you include a passphrase you will benefit from a "doubly-secure" authentication, based on both the key and the passphrase.)
To use the keys, save the key files in a secure location on the client machine. Then copy the contents of the public key file into the file $HOME/.ssh/authorized_keys, (SSH protocol version 1), or $HOME/.ssh/authorized_keys2, (SSH protocol version 2), on the server machine. Finally, modify the PuTTY, WinSCP or TTSSH session details so that it uses the saved private key file, (making sure it also uses the correct protocol for the specified key). You will find the option to specify the Private Key File under the SSH settings.
Assuming you've got the right files in the right places, and the correct session settings, when you attempt to connect you should find that you can connect without supplying a password or passphrase.
If you are using Cygwin and the command-line ssh/scp versions, you can check the man pages for ssh to determine where you need to save your key files so that the ssh and scp commands will connect without requiring a password/passphrase.
This "passphrase-less" approach is reasonably secure, provided access to the client machine is restricted. However, if someone manages to steal your private key file, (which might not be that difficult on most Windows machines), your server account will be fully compromised.
How passwordless works
Using keys, together with a program called an authentication agent, SSH can authenticate you to all your computer accounts securely without requiring you to memorize many passwords or enter them repeatedly. It works like this:
In advance (and only once), place special files called public key files into your remote computer accounts. These enable your SSH clients (ssh, scp) to access your remote accounts.
On your local machine, invoke the ssh-agent program, which runs in the background.
Choose the key (or keys) you will need during your login session.
Load the keys into the agent with the ssh-add program. This requires knowledge of each key's secret passphrase.
At this point, you have an ssh-agent program running on your local machine, holding your secret keys in memory.
To install a public key into the "pat" account on shell.isp.com: This is done by editing a file in the SSH configuration directory: ~/.ssh/authorized_keys for SSH1 and OpenSSH or ~/.ssh2/authorization for SSH2.
For SSH1 or OpenSSH, create or edit the file ~/.ssh/authorized_keys and append your public key, i.e., the contents of the identity.pub file you generated on the local machine. A typical authorized_keys file contains a list of public key data, one key per line. The example contains only two public keys, each on its own line of the file, but they are too long to fit on this page. The line breaks inside the long numbers are printing artifact; if they were actually in the file, it would be incorrectly formatted and wouldn't work:
1024 35 8697511247987525784866526224505474204292260357215616159982327587956883143
362147028876494426516682677550219425827002174890309672203219700937187777979705864
107549106608811204142046600066790196940691100768682518506600601481676686828742807
11088849408310989234142475694298520575977312478025518391 my personal key
1024 37 1140868200916227508775331982659387253607752793422843620910258618820621996
941824516069319525136671585267698112659690736259150374130846896838697083490981532
877352706061107257845462743793679411866715467672826112629198483320167783914580965
674001731023872042965273839192998250061795483568436433123392629 my work key
These are RSA public keys: the first number in each entry is the number of bits in the key, while the second and third are RSA-specific parameters called the public exponent and modulus. After these comes an arbitrary amount of text treated as a comment.
For SSH2, you need to edit two files, one on the client machine and one on the server machine. On the client machine, create or edit the file ~/.ssh2/identification and insert a line to identify your private key file:
IdKey id_dsa_1024_a
On the server machine, create or edit the file ~/.ssh2/authorization, which contains information about public keys, one per line. But unlike SSH1's authorized_keys file, which contains copies of the public keys, the authorization file lists only the filename of the key:
Key id_dsa_1024_a.pub
Finally, copy id_dsa_1024_a.pub from your local machine to the remote SSH2 server machine, placing it in ~/.ssh2.
Regardless of which SSH implementation you use, make sure your remote SSH directory and associated files are writable only by your account:
(We make files world-readable and directories world-searchable, to avoid NFS problems. )
# SSH1, OpenSSH
$ chmod 755 ~/.ssh
$ chmod 644 ~/.ssh/authorized_keys
# OpenSSH only
$ chmod 644 ~/.ssh/authorized_keys2
# SSH2 only
$ chmod 755 ~/.ssh2
$ chmod 644 ~/.ssh2/id_dsa_1024_a.pub
$ chmod 644 ~/.ssh2/authorization
The SSH server is picky about file and directory permissions and may refuse authentication if the remote account's SSH configuration files have insecure permissions. [Section 5.4.2.1, "Acceptable permissions for user files"]
You are now ready to use your new key to access the "pat" account:
# SSH1, SSH2, OpenSSH; output shown is for SSH1
$ ssh -l pat shell.isp.com
Enter passphrase for RSA key 'Your Name
Last login: Mon May 24 19:44:21 1999 from quincunx.nefertiti.org
You have new mail.
shell.isp.com>
# posted by Ryan : 9:28 AM
