SSH and Windows
Most security-conscious organizations have replaced telnet with ssh for remote access to Unix machines. While the security benefits are well-known and well-understood, there are several other very good reasons to use ssh instead of telnet, such as the use of ssh keys for authentication instead of passwords.
Background
ssh allows for many forms of authentication, such as traditional password authenication, host-based authentication, and public key authentication. Password authentication under ssh is the same as it is under telnet or console logins: You provide the remote host with your password, and it authenticates you (or not) based its internal password-checking routines. The important point is that the remote system checks your password, which means your password needs to travel over the connection to the server. With ssh, by the time you’re entering your password, you already have an encrypted connection with the server, so this is secure. Hosever, you still need to manually enter your password, which makes this unsuitable for automated processes and lazy people. You are also trusting the remote system not to retain or log your password.
Key-based authentication works differently. It is a public key system, which means that you generate a keypair, consisting of a public portion and a private portion. The public key is distributed to every host you want to connect to, but the private part is kept private (on a secure machine, such as a laptop, or on a floppy or
removable USB device). In public key cryptography, data encrypted to a public key can only be decrypted by the accompanying private key.
Private keys are stored encrypted, and protected by a passphrase. This passphrase is specified when the key is initially created, and it is the only way to decrypt a private key for use.
When authenticating with a keypair, the remote ssh server will encrypt unique session data with your public key, which can then only be decrypted with your private key, and sends it to your ssh client. After decrypting this session data, the client re-encrypts with to the server’s host key, and sends it back. The server knows that if this encrypted packet contains the same data that it sent out, the process on the other side has the private portion of the key that is being used for authentication. It is very important to note that the decryption happens on the client side, by the ssh client, not the server side, which is what happens with password authentication. Neither the private key nor the passphase used to encrypt it ever leave the local machine.
It is easy to confuse the local passphrase prompt for the remote password prompt, but there is a very important difference: The passphrase prompt is coming from the local ssh client, and is never sent over the wire, while the password prompt comes from the remote server. The decrypted private key is used to decrypt the session data from the server, which is then re-encrypted to the server’s public key (which was retrieved during the initial connection) and sent back to the server.
From the average user’s point of view, this may seem like silly details. However, ssh takes this a step further, and adds the concept of a key manager or agent: a process that exists to handle key requests. If you are running an agent, your ssh client will consult it first for decrypted private keys before prompting you for a passphrase. If the agent has the necessary key, then the user is not prompted at all, and authentication is transparent, but no less secure.
The agent only stores decrypted copies of keys that you specifically add to it, and it can be told to forget keys and configured to time them out. The agent should only be run on a secure, trusted machine, such as a laptop or dedicated single-user workstation.
Finally, ssh supports the concept of agent forwarding. This means that not only can you use the agent on your local workstation to authenticate connects from your machine to another, you can use this same agent to authenticate connections from that machine to another. With agent forwarding turned on, any number of hops is possible, and they will all be authenticated against the local agent, which you control. This means that by distributing a single public key, you can have secure single-sign on for all of your ssh needs, while still maintaining control over your keys.
Making agent-enabled public-key authentication work with PuTTY
There are three necessary components: puttygen, pagent, and
putty. puttygen is needed only for the initial key generation. Each can be downloaded from Simon Tatham’s web site.
pagent is the agent itself. Once pagent is running, you can add keys to it. Remember that the agent itself is useless without keys, so it is safe to start up pagent when you logon by putting it your Startup folder. When started, pagent adds an icon to the system tray; right clicking on this icon produces a menu with key management options, including options to add, view, and remove keys. (We’ll see more about this in a moment.)
Once the agent is up and running, putty will try to use it by default, so no extra configuration is required.
Key Management
There are two aspects to key management: Management of the private keys and management of the public keys.
Creating a keypair
Run puttygen.exe to create a new keypair. In the key generation form, select SSH1 or SSH2, depending on what the server supports. SSH1 is older and has broader support, but has some weaknesses in the protocol are addressed by SSH2. Ultimately, the types of keys you need will depend on the remote machine, and what protocols it supports. You are not limited to one key, so you can create one or several of both SSH1 and SSH2 keys.
For most of the options, you can simply use the defaults provided, as they are sane. For the comment field, I like to use my email address, but this is an unnecessary affectation, as ssh mostly ignores it.
Key generation can take a little while; be patient, especially if you have an older machine. The generation process needs a lot of entropy, so you might be asked to move the mouse or do something else equally as random.
Once the key is generated, save it somewhere secure. I recommend that you store the keypair on a removable device, such as a floppy or USB drive, that you can take with you when you get up, or on a machine that only you have access to, such as a laptop.
To extract the public portion of your shiny new key, open puttygen and load the keypair into it. The public portion of the key will be displayed in XXX, which you can copy and paste wherever you need it.
Public Key Management
Managing public keys is fairly straightforward. On your destination machine, create a ~/.ssh directory (if it doesn’t already exist), and it in, create a file called authorized_keys. This file should contain the public portions of all the public keys that are allowed to connect to that machine, one per line. For example:
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAgEAx38VpomJPPwivveJ/m3+J53NlNN4cIc 3PS/w5YUNXaZwd+Tgipz6XWcb2c0bbfqg9fAFzLe3YLb18muzceJK8t5RboPVhNUvhD gjb9TE5Y9xZIIgREBp2LQvDZX4HVC4s2/QJkWkBVwOm6yymnzxoljEIp/afge8NbIkJ 0eww3eYEsXkFgKUFa7mImoUttvjfST95I1ns9oiwaXUFPztkKnKXPrwgKM8uSX6sAQJ k2bQJPwrtOjaW+vPzUGU5ctL45zhtP83aHw3+oFlfRMj0m4ZV96RMc7b85nMPqmaNCH tAvnUJBclPaVozuIV572MB7ETH9cRZT4z2i+zvPlkIGzEEGj7K7wN39K3rl4ptW/PGJ XJsERrokXFBWbbX1wc8hO+gTdIkrcyVCYE+ThB/cvqoXJm5Ka2FJTDGb67Eu2v9I/IK pljjuGsuOeFHurJaqNZN3Keog7GUtuHWDxY0ATmI+U5jqmo3ZCnVVmlKjJ2rWcCUvmY 5oLRtsJea7asOwnVMlrImpIg8TxKEl9iayD8Azkq1cC8+dXaExHAezEtLNEspVlwDZM yF+z/1JSnFVJlk9pGFztTSwOGMCyLK29xnmsq3wkMyyNgGN290hgEeyAJg0FxPMcA6U 20fxOjk6BmiZ0O2xB11Pqh00tSFvxqeu7YN8D4YAwUjCFiyF0= dlc@sevenroot.org
The real key file has no newlines, since newlines are used to separate keys in the authorized_keys file. The permissions on this directory and file are important; if either is group or world writable, sshd will not consider the keys trusted, and won’t use them. Additionally, the parent directory should also be writable only by the owner. To ensure that the permissions are set correctly, run:
chmod g-w,o-w ~ chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys
When connecting to the remote machine initially, before your keys are in place, you’ll have to use your password to authenticate.
You can have any number of keys in the authorized_keys file, one per line. sshd will try them one at a time, from top to bottom, until it finds the matching key.
Private Key Management
Managing private keys is a little harder than managing public keys, because of the requirement of secrecy. Even though the private key is encrypted and protected with a passphrase, if a malicious attacker were able to get a copy of your private key, he could do a brute force attack on the encryption, and possibly figure out the passphrase protecting the key. If this happens, he would be able to connect as you to any machine that has the corresponding public key. Of course, this is no different from password authentication, where anyone with the right password can log in as anyone else. Using ssh keys is more secure because in order to use someone else’s account, an attacker would need both the passphrase and the private key that it goes to.
When you add a key to your agent, you will be prompted for the passphrase for the key. This is used to decrypt the key, and the decrypted key is stored in the agent.
Once the agent holds your keys, simply connect to the target host as usual. If everything is set up correctly, you will connected without a password prompt. If PuTTY uses a key for authentication, a message is printed to the terminal window indicating which key was used.
Darren's Bowl Of Foo 