Erudite Relics of Loc Huu Ho

Original Document Here

WHM

Step one was to login to Web Host Manager (the server management front-end for cPanel), and run their configuration wizard. The only things that required non-default action were:

• setting the hostname
• added a resolver (DNS) server ip

After the wizard was complete, these additional settings were performed manually:

• Server Contact E-Mail
• Turned on awstats web stats reporting tool
• Changed hostname. (Even though the wizard set it, this was an additional, different place.)
• Changed system mail preferences to send root email to an admin alias.
• Changed root password.
• Set Nameservers

Also ran Update Server Software and Update System Software within WHM to update as many components as reasonable.

Linux Kernel

The original configuration as delivered by the server farm:

WHM 10.1.0 cPanel 10.2.0-R82
RedHat Enterprise 3 i686 – WHM X v3.1.0
Linux kernel version: 2.4.21-27.ELsmp

Since that’s not the latest kernel at the time of delivery, and cPanel will not update the kernel automatically, I was advised to update. I upgraded the kernel to 2.4.21-32.0.1.ELsmp, which went smoothly.

Remote Access

One of the areas for almost immediate security tweaking is remote access. If you’ve ever examined a server’s logs, you know that they’re regularly probed with various types of attacks. There are several modifications to render those attacks pointless, as well as secure remote access in general.

SSH

SSH, or secure shell, is the remote command-line access mechanism of choice. It’s single biggest claim to fame is simply that everything is encrypted, though it includes many more features as well.

I first created a couple of non-root login accounts, and installed RSA public keys for eventual RSA/public key-only logins. (Also created end-user instructions for creating, and using, SSH key pairs.)

I then made the following changes to /etc/ssh/sshd_config:

• Protocol 2 – this disables protocol version 1, which is known to have security issues.
• PermitRootLogin without-password – this disables root login, unless a public key is used.
• PasswordAuthentication set to no – this disables the ability to login with just a username and password. A username and public key are required.

Telnet

I disabled telnet, as it allows passwords to be transmitted in the clear, and is a known security risk.

FTP

Normally at this point I would also disable the FTP service for the same reasons as Telnet – it’s a known security risk. For reasons I didn’t bother to investigate further, cPanel either complained repeatedly via email if the service was stopped, or it would restart it, depending on the technique I was attempting to use. I gave up on this and left the FTP service running, but blocked at the firewall, discussed below.

TMP

The /tmp directory is an interesting and apparently common place for hackers to exploit to breech a system. One approach to securing it without breaking its functionality is to create it as a new partition that disallows program execution. Where in the past a hacker could use an exploit to place a file in /tmp and then execute it, the ability to execute is now removed by creating a secure /tmp partition.

Firewall

Installed APF which is, essentially, an intelligent front end to the built in Linux firewall, iptables. I found a good how-to, though I did not yet configure the antidos (denial of service) component. The one change that I did make to the default configuration is that I disabled or blocked all ports that we know are not explicitly used for something specific. For example, this is where I blocked all FTP access. I also whitelisted my own static IP address, and that of the client.

Logging

Logwatch is a server log summary tool that emails a report to the server admins nightly. An older version was installed. I updated to latest, and increased the reporting level to “medium”.

Rootkit Checks

Installed nightly backup script, which includes nightly reporting of both rkhunter and chkrootkit runs.

Apache

Installed mod_security, which guards against exploits via the Apache web server, using a basic ruleset. This how to was helpful in setting that up.

General

A few additional tweaks and settings …

• Installed LES – “LES is intended as a facility to quickly & easily secure Redhat/RPM based environments (i.e: turbo Linux, open Linux). It does such by enforcing root-only permissions on system binaries (binaries that have no place being executed by normal users), enforcing root-only path traversal on system paths, enforcing immutable bit on essential rpm package contents (i.e: coreutils), and enforcing immutable bit on shell profile scripts.”
• Added a mail line to /etc/rc.d/rc.local, to automatically notify on reboots.
• Removed the cpbackup cron job, since we don’t use cPanel’s backup approach.
• Modified reverse-DNS to be correct.

---

Ongoing Maintenance

Even with all the tools and updates in place, there’s still on-going work and vigilance required.

• Monitor the nightly logs and reports generated for anomalies.
• Manually install updates as reported available by up2date.
• Monitor Redhat for kernel updates, and install as appropriate.
• Monitor chkrootkit for updates, and install as appropriate.

---

Still More Options

I haven’t implemented these, but they’ve been recommended, and they’re on the list to evaluate at some point.

• mod_doevasive. “mod_dosevasive is an evasive maneuvers module for Apache to provide evasive action in the event of an HTTP DoS or DDoS attack or brute force attack. It is also designed to be a detection and network management tool, and can be easily configured to talk to ipchains, firewalls, routers, and etcetera. mod_dosevasive presently reports abuses via email and syslog facilities.” How To
• Evaluate BFD. “BFD is a modular shell script for parsing applicable logs and checking for authentication failures.”

This saved me a couple of hours trying to figure out it myself.

Original Document Here

So you’re trying to set up ssh keys on your windows box with putty and you keep getting “Server refused our key”. Read on, I’ve got your solution… but first lets take a look at what you’ve done so far.

Chances are you have done some/none/all of the following:

• opened up puttygen.exe
• generated a key after wiggling your mouse
• entered a strong passphrase
• saved the public key to something like

  pubkey

• saved the private key to something like

  privatekey.ppk

• moved your public key up to the server
• (maybe even) converted the format of the key from putty to openssh with something like

  ssh-keygen -if pubkey > pubkey_openssh_format

• changed some permissions like

  chmod 700 .ssh

• added your pubkey to the authorized_keys file with something like

  cat pubkey >> .ssh/authorized_keys

• changed some more permissions like

  chmod 600 authorized_keys

• changed your putty settings under “connection > SSH > auth” to use

  privatekey.ppk

• tried to connect and…

“Server refused our key”

Well – from what I have read that’s supposed to work… but it didn’t work for you did it?

Your problem has nothing to do with how well you followed these well documented procedures for getting ssh keys to work.
The solution to the problem is…
(brace yourself, its really simple) to try generating the keys on the server (unix, linix, bsd etc.) instead of the client (i.e. in windows).

Try the following:

• ssh to your server using good old user name and password
• do check permissions on your ~/.ssh folder and make sure to

  chmod 700 .ssh

  if they are wrong

• do check permissions on your ~/.ssh/authorized_keys file and make sure to

  chmod 600 authorized_keys

  if they are wrong

• generate the keys on the server with something like

  ssh-keygen -t dsa

  (or rsa – read the man pages if your don’t know how to use ssh-keygen

• accept the file names it wants to use
• enter a strong passphrase
• add the pub key to the authorized_keys file with something like

  cat id_dsa.pub >> .ssh/authorized_keys

• copy the private key (id_dsa) to your local windows machine (use winscp or sftp or some such tool)
• NOW open puttygen.exe
• under actions select “load” and load the id_dsa file
• enter the passphrase you set when you generated the key on the server. Puttygen will now convert the key to something that putty will understand
• save that file to something like

  pivatekey.ppk

• NOW change your putty settings under “connection > SSH > auth” to use

  privatekey.ppk

• NOW try and connect
• enter the passphrase when prompted
• pat yourself on the back. You’re connected to the server (I hope)

Now all you have to do is figure out a way to not have to always enter that passphrase. Well that will require setting up puttyagent. But, I’ll let you figure that out for yourself.

I really hope this helped you out. I wasted too much of my life figuring this out this evening and I hope I saved you hours of aggravation.

Original Document Here

SSH (Secure Shell) and SFTP (Secure FTP) support a very strong security model that can be used instead of the normal username and password authentication scheme we’ve all come to know and love. It uses public key cryptography to create a different, and more secure approach to authenticating your identity and rights to access a server or resource.

In a nutshell, you will generate a public and private key pair. The public key will be placed on the server by your system administrator, giving you access. You will keep the file containing the private key in a safe place. You’ll login by simply by providing that private key file to your SSH or SFTP supporting client.

It really is that simple.

•

The private key is just that – private. You may put a password on it, but you don’t have to. Without a password, all you need is the file in order to login. Or, to put it more clearly, all anyone needs is that file to login as you. Obviously if you password protect the file, then you’ll need both the file, and the password to unlock it. In that case, logging in is very similar to what you do today: specify a user name, and a password to unlock your key file.

Instructions are included here for the following tools, which are known to work with this technique:

SSH Clients	SFTP Clients
PuTTY SecureCRT	PSFTP Webdrive WS_FTP

Instructions for these tools are not provided here, but they either claim or have been confirmed to have the appropriate support:

SSH Clients	SFTP Clients
Tera Term Pro	CuteFTP Professional (not Home) WinSCP

Other tools may also work. The key terminology to look for is “SSH” or “SFTP” and “Public Key Authentication”.

Generating Your Keys

In general it’s best to create your own key. That way you control what happens to your private key, and no one else ever has to see it.

PuTTYgen

PuTTY is a free SSH client that includes a tool for generating keys, called PuTTYgen. The tool can also be downloaded separately, but why bother … get the whole thing. PuTTY is my recommended SSH client.

When you run PuTTYgen, you’ll get a dialog with a “Generate” button on it.

Push da button.

It will ask you to move the mouse around to generate randomness. (Randomness is a key component of public key cryptography). Once that’s happened enough, you should do the following:

• Specify a passphrase. Technically this is optional, but if you omit the passphrase, then anyone who happens to get ahold of your private key file can login as you. You may have enough security in place where this is not an issue. If you do specify a passphrase, you’ll need to enter it when you login, pretty much as a normal login.
• Press the Save Public Key button to save the public key. I recommend saving as your name “.pub”. For example I would save “leo.pub”.
• Press the Save Private Key button to save your private key. This saves the private key in PuTTY’s own format, a “.ppk” file. So, “name.ppk” might be appropriate.
• I also recommend hitting the Conversions menu, and then Export Openssh key, and saving that to “name.key”. This format will allow you to use your private key with other applications besides PuTTY.

SecureCRT

SecureCRT is a stand-alone SSH client.

To create a public key with SecureCRT, hit the Tools menu, Create Public Key… option to begin the wizard.

Select RSA as the key type. Enter (or not) an appropriate passphrase to protect your private key. A default key length of 1024 is sufficient. Allow SecureCRT to save the key, noting the location thereof. It may ask if you want to use this as your global Public Key, and you can safely say “yes”.

WS_FTP

As far as I can tell, WS_FTP cannot import key pairs for use, or will it export its private key. This means that even if you use one of the other SSH clients and generate key pairs for their use, you’ll still need generate a separate key pair for use within WS_FTP. That’s not a problem from the servers perspective – you can authenticate with as many different keys as you like.

In WS_FTP, hit Tools, Options, and then click on SSH, Client Keys:

Press Create, and step through the wizard. The key type should be RSA, and the default size of 1024 is sufficient.

Once the key has been created and shows up in the list, click on it, and then click on Export, to export your public key. Send the resulting .pub file to your system administrator.

Once you have your keys…

Send your public key to your system administrator. (Either the “.pub” file as an attachment, or the text within it, in email.) It will be put in “all the right places” to allow you to log in to all the account(s) you might need to.

Keep your private key in a safe place. You’ll need it each time you want to login. If they are lost, you will lose access until the key generation and installation process can be repeated. If they or the computer they’re on are stolen, tell your system admin immediately.

Using Your Keys – SSH

Once your keys are generated, and the public key installed on the server, you’ll need to specify the private key to your SSH client in order to log in.

PuTTY

There are (at least) two approaches to using Public/Private keys with PuTTY. When you fire up PuTTY without any arguments, you get its standard configuration dialog, into which you can enter the name of the server you want to connect to:

On the left hand side is a tree view of various options. Underneath Connection, SSH, click on Auth and the dialog will include a field “Private key file for authentication“:

Specify the location of the “.ppk” file that you generated with PuTTYgen. When you connect, if your private key is passphrase protected, you’ll be asked for the passphrase.

The other approach, and the one that I use, is to simply create shortcuts for the various servers I connect to regularly, and specify the location of the private key on the command line. For example:

C:\path\PUTTY.EXE -i c:\otherpath\leo.ppk leo@server.com

That, as a desktop shortcut, or item on a Windows menu, connects to the named server using the specified account name “leo”, and uses the private key found in “c:\otherpath\leo.ppk” to authenticate.

SecureCRT

SecureCRT has several paths to a connection dialog, but we’ll use “Quick Connect” for our example. Press the Quick Connect Icon, and you should get something like this:

Make sure that protocol is set to SSH2, and enter your host and username. In Authentication, UNcheck everything except PublicKey. Then click on that, and click Properties. You should see this:

Typically you need do nothing, but this dialog specifies the location of your identity file (aka Private Key).

Assuming that your public key has been placed on the server for your account, you should now be able to connect.

Using Your Keys – SFTP

Secure FTP, or FTP, is really just using SSH technology to provide FTP-like functionality. Since it’s using SSH, the keys you’ve generated and are using for your SSH authentication work with many SFTP applications as well.

WebDrive

Webdrive is an FTP/SFTP service for Windows that allows you to treat an FTP or SFTP connection like another drive mounted on your system. Uploading and downloading then become simple Windows file copy operations.

In Webdrive, you’ll need to load your private key, and then specify it in the configuration for a specific SFTP connection.

The Certificates tab of Webdrive’s Settings dialog, has a Hostkey Managemet button:

Push that, and you’ll get the host key management dialog, and on that you’ll find an Import button. Press that to import your public and private keys:

Specify the “.pub” key for the public key you generated earlier. The private key should also be specified, and would be the “.key” file. If you passphrase protected your key file, you can specify that here as well. Give it a recognizable name.

The second step, then, takes us back to the Webdrive main window:

Click on a connection (or create a new one). In the Properties for that connection, on the SFTP tab will be a setting Enable client hostkey support for this site:

Here you’ll find a dropdown list of the keys you imported above, and a place to enter the password, if any, to access that key.

Once completed, Webdrive should now be able to connect to your public key authenticated site.

WS_FTP

Having created a key pair already in WS_FTP, using it is simply a matter of defining your connection to use it.

When you create a site, specify its connection type as SFTP/SSH. Specify a user name, but leave your password blank. At the end of the wizard, click on the Advanced button, this will allow you to edit the connection, and is the equivalent to editing an existing connection.

Click on the SSH item on the left, and the dropdown list that results should allow you to select the key pair that you created earlier.

Assuming that the public key you exported and sent to your system administrator has been installed on the server, you should now be able to connect.

psftp

PSFTP is command line FTP program that is distributed with PuTTY. More importantly, it supports public key SFTP by using the “.ppk” file that you created for PuTTY above. Connecting using a public key is simply a different set of comment line options:

psftp -l username -2 -i keys.ppk remotehost

-l username specifies your username on the remote host; -2 indicates that PSFTP should use SSH protocol version 2; -i keys.ppk specifies the location of your private key as created with PuTTYgen; remotehost is the name of the remote host you’re connecting to.

Original Document Here

8.1 Public key authentication – an introduction

Public key authentication is an alternative means of identifying yourself to a login server, instead of typing a password. It is more secure and more flexible, but more difficult to set up.

In conventional password authentication, you prove you are who you claim to be by proving that you know the correct password. The only way to prove you know the password is to tell the server what you think the password is. This means that if the server has been hacked, or spoofed (see section 2.2), an attacker can learn your password.

Public key authentication solves this problem. You generate a key pair, consisting of a public key (which everybody is allowed to know) and a private key (which you keep secret and do not give to anybody). The private key is able to generate signatures. A signature created using your private key cannot be forged by anybody who does not have that key; but anybody who has your public key can verify that a particular signature is genuine.

So you generate a key pair on your own computer, and you copy the public key to the server. Then, when the server asks you to prove who you are, PuTTY can generate a signature using your private key. The server can verify that signature (since it has your public key) and allow you to log in. Now if the server is hacked or spoofed, the attacker does not gain your private key or password; they only gain one signature. And signatures cannot be re-used, so they have gained nothing.

There is a problem with this: if your private key is stored unprotected on your own computer, then anybody who gains access to that will be able to generate signatures as if they were you. So they will be able to log in to your server under your account. For this reason, your private key is usually encrypted when it is stored on your local machine, using a passphrase of your choice. In order to generate a signature, PuTTY must decrypt the key, so you have to type your passphrase.

This can make public-key authentication less convenient than password authentication: every time you log in to the server, instead of typing a short password, you have to type a longer passphrase. One solution to this is to use an authentication agent, a separate program which holds decrypted private keys and generates signatures on request. PuTTY’s authentication agent is called Pageant. When you begin a Windows session, you start Pageant and load your private key into it (typing your passphrase once). For the rest of your session, you can start PuTTY any number of times and Pageant will automatically generate signatures without you having to do anything. When you close your Windows session, Pageant shuts down, without ever having stored your decrypted private key on disk. Many people feel this is a good compromise between security and convenience. See chapter 9 for further details.

There is more than one public-key algorithm available. The most common is RSA, but others exist, notably DSA (otherwise known as DSS), the USA’s federal Digital Signature Standard. The key types supported by PuTTY are described in section 8.2.2.

8.2 Using PuTTYgen, the PuTTY key generator

PuTTYgen is a key generator. It generates pairs of public and private keys to be used with PuTTY, PSCP, and Plink, as well as the PuTTY authentication agent, Pageant (see chapter 9). PuTTYgen generates RSA and DSA keys.

When you run PuTTYgen you will see a window where you have two choices: ‘Generate’, to generate a new public/private key pair, or ‘Load’ to load in an existing private key.

8.2.1 Generating a new key

This is a general outline of the procedure for generating a new key pair. The following sections describe the process in more detail.

• First, you need to select which type of key you want to generate, and also select the strength of the key. This is described in more detail in section 8.2.2 and section 8.2.3.
• Then press the ‘Generate’ button, to actually generate the key. Section 8.2.4 describes this step.
• Once you have generated the key, select a comment field (section 8.2.6) and a passphrase (section 8.2.7).
• Now you’re ready to save the private key to disk; press the ‘Save private key’ button. (See section 8.2.8).

Your key pair is now ready for use. You may also want to copy the public key to your server, either by copying it out of the ‘Public key for pasting into authorized_keys file’ box (see section 8.2.10), or by using the ‘Save public key’ button (section 8.2.9). However, you don’t need to do this immediately; if you want, you can load the private key back into PuTTYgen later (see section 8.2.11) and the public key will be available for copying and pasting again.

section 8.3 describes the typical process of configuring PuTTY to attempt public-key authentication, and configuring your SSH server to accept it.

8.2.2 Selecting the type of key

Before generating a key pair using PuTTYgen, you need to select which type of key you need. PuTTYgen currently supports three types of key:

• An RSA key for use with the SSH 1 protocol.
• An RSA key for use with the SSH 2 protocol.
• A DSA key for use with the SSH 2 protocol.

The SSH 1 protocol only supports RSA keys; if you will be connecting using the SSH 1 protocol, you must select the first key type or your key will be completely useless.

The SSH 2 protocol supports more than one key type. The two types supported by PuTTY are RSA and DSA.

The PuTTY developers strongly recommend you use RSA. DSA has an intrinsic weakness which makes it very easy to create a signature which contains enough information to give away the private key! This would allow an attacker to pretend to be you for any number of future sessions. PuTTY’s implementation has taken very careful precautions to avoid this weakness, but we cannot be 100% certain we have managed it, and if you have the choice we strongly recommend using RSA keys instead.

If you really need to connect to an SSH server which only supports DSA, then you probably have no choice but to use DSA. If you do use DSA, we recommend you do not use the same key to authenticate with more than one server.

8.2.3 Selecting the size (strength) of the key

The ‘Number of bits’ input box allows you to choose the strength of the key PuTTYgen will generate.

Currently 1024 bits should be sufficient for most purposes.

Note that an RSA key is generated by finding two primes of half the length requested, and then multiplying them together. For example, if you ask PuTTYgen for a 1024-bit RSA key, it will create two 512-bit primes and multiply them. The result of this multiplication might be 1024 bits long, or it might be only 1023; so you may not get the exact length of key you asked for. This is perfectly normal, and you do not need to worry. The lengths should only ever differ by one, and there is no perceptible drop in security as a result.

DSA keys are not created by multiplying primes together, so they should always be exactly the length you asked for.

8.2.4 The ‘Generate’ button

Once you have chosen the type of key you want, and the strength of the key, press the ‘Generate’ button and PuTTYgen will begin the process of actually generating the key.

First, a progress bar will appear and PuTTYgen will ask you to move the mouse around to generate randomness. Wave the mouse in circles over the blank area in the PuTTYgen window, and the progress bar will gradually fill up as PuTTYgen collects enough randomness. You don’t need to wave the mouse in particularly imaginative patterns (although it can’t hurt); PuTTYgen will collect enough randomness just from the fine detail of exactly how far the mouse has moved each time Windows samples its position.

When the progress bar reaches the end, PuTTYgen will begin creating the key. The progress bar will reset to the start, and gradually move up again to track the progress of the key generation. It will not move evenly, and may occasionally slow down to a stop; this is unfortunately unavoidable, because key generation is a random process and it is impossible to reliably predict how long it will take.

When the key generation is complete, a new set of controls will appear in the window to indicate this.

8.2.5 The ‘Key fingerprint’ box

The ‘Key fingerprint’ box shows you a fingerprint value for the generated key. This is derived cryptographically from the public key value, so it doesn’t need to be kept secret.

The fingerprint value is intended to be cryptographically secure, in the sense that it is computationally infeasible for someone to invent a second key with the same fingerprint, or to find a key with a particular fingerprint. So some utilities, such as the Pageant key list box (see section 9.2.1) and the Unix ssh-add utility, will list key fingerprints rather than the whole public key.

8.2.6 Setting a comment for your key

If you have more than one key and use them for different purposes, you don’t need to memorise the key fingerprints in order to tell them apart. PuTTY allows you to enter a comment for your key, which will be displayed whenever PuTTY or Pageant asks you for the passphrase.

The default comment format, if you don’t specify one, contains the key type and the date of generation, such as rsa-key-20011212. Another commonly used approach is to use your name and the name of the computer the key will be used on, such as simon@simons-pc.

To alter the key comment, just type your comment text into the ‘Key comment’ box before saving the private key. If you want to change the comment later, you can load the private key back into PuTTYgen, change the comment, and save it again.

8.2.7 Setting a passphrase for your key

The ‘Key passphrase’ and ‘Confirm passphrase’ boxes allow you to choose a passphrase for your key. The passphrase will be used to encrypt the key on disk, so you will not be able to use the key without first entering the passphrase.

When you save the key, PuTTY will check that the ‘Key passphrase’ and ‘Confirm passphrase’ boxes both contain exactly the same passphrase, and will refuse to save the key otherwise.

If you leave the passphrase fields blank, the key will be saved unencrypted. You should not do this without good reason; if you do, your private key file on disk will be all an attacker needs to gain access to any machine configured to accept that key. If you want to be able to log in without having to type a passphrase every time, you should consider using Pageant (chapter 9) so that your decrypted key is only held in memory rather than on disk.

Under special circumstances you may genuinely need to use a key with no passphrase; for example, if you need to run an automated batch script that needs to make an SSH connection, you can’t be there to type the passphrase. In this case we recommend you generate a special key for each specific batch script (or whatever) that needs one, and on the server side you should arrange that each key is restricted so that it can only be used for that specific purpose. The documentation for your SSH server should explain how to do this (it will probably vary between servers).

Choosing a good passphrase is difficult. Just as you shouldn’t use a dictionary word as a password because it’s easy for an attacker to run through a whole dictionary, you should not use a song lyric, quotation or other well-known sentence as a passphrase. DiceWare (www.diceware.com) recommends using at least five words each generated randomly by rolling five dice, which gives over 2^64 possible passphrases and is probably not a bad scheme. If you want your passphrase to make grammatical sense, this cuts down the possibilities a lot and you should use a longer one as a result.

Do not forget your passphrase. There is no way to recover it.

8.2.8 Saving your private key to a disk file

Once you have generated a key, set a comment field and set a passphrase, you are ready to save your private key to disk.

Press the ‘Save private key’ button. PuTTYgen will put up a dialog box asking you where to save the file. Select a directory, type in a file name, and press ‘Save’.

This file is in PuTTY’s native format (*.PPK); it is the one you will need to tell PuTTY to use for authentication (see section 4.18.5) or tell Pageant to load (see section 9.2.2).

8.2.9 Saving your public key to a disk file

The SSH 2 protocol drafts specify a standard format for storing public keys on disk. Some SSH servers (such as ssh.com‘s) require a public key in this format in order to accept authentication with the corresponding private key. (Others, such as OpenSSH, use a different format; see section 8.2.10.)

To save your public key in the SSH 2 standard format, press the ‘Save public key’ button in PuTTYgen. PuTTYgen will put up a dialog box asking you where to save the file. Select a directory, type in a file name, and press ‘Save’.

You will then probably want to copy the public key file to your SSH server machine. See section 8.3 for general instructions on configuring public-key authentication once you have generated a key.

If you use this option with an SSH 1 key, the file PuTTYgen saves will contain exactly the same text that appears in the ‘Public key for pasting’ box. This is the only existing standard for SSH 1 public keys.

8.2.10 ‘Public key for pasting into authorized_keys file’

All SSH 1 servers require your public key to be given to it in a one-line format before it will accept authentication with your private key. The OpenSSH server also requires this for SSH 2.

The ‘Public key for pasting into authorized_keys file’ gives the public-key data in the correct one-line format. Typically you will want to select the entire contents of the box using the mouse, press Ctrl+C to copy it to the clipboard, and then paste the data into a PuTTY session which is already connected to the server.

See section 8.3 for general instructions on configuring public-key authentication once you have generated a key.

8.2.11 Reloading a private key

PuTTYgen allows you to load an existing private key file into memory. If you do this, you can then change the passphrase and comment before saving it again; you can also make extra copies of the public key.

To load an existing key, press the ‘Load’ button. PuTTYgen will put up a dialog box where you can browse around the file system and find your key file. Once you select the file, PuTTYgen will ask you for a passphrase (if necessary) and will then display the key details in the same way as if it had just generated the key.

If you use the Load command to load a foreign key format, it will work, but you will see a message box warning you that the key you have loaded is not a PuTTY native key. See section 8.2.12 for information about importing foreign key formats.

8.2.12 Dealing with private keys in other formats

Most SSH1 clients use a standard format for storing private keys on disk. PuTTY uses this format as well; so if you have generated an SSH1 private key using OpenSSH or ssh.com‘s client, you can use it with PuTTY, and vice versa.

However, SSH2 private keys have no standard format. OpenSSH and ssh.com have different formats, and PuTTY’s is different again. So a key generated with one client cannot immediately be used with another.

Using the ‘Import’ command from the ‘Conversions’ menu, PuTTYgen can load SSH2 private keys in OpenSSH’s format and ssh.com‘s format. Once you have loaded one of these key types, you can then save it back out as a PuTTY-format key (*.PPK) so that you can use it with the PuTTY suite. The passphrase will be unchanged by this process (unless you deliberately change it). You may want to change the key comment before you save the key, since OpenSSH’s SSH2 key format contains no space for a comment and ssh.com‘s default comment format is long and verbose.

PuTTYgen can also export private keys in OpenSSH format and in ssh.com format. To do so, select one of the ‘Export’ options from the ‘Conversions’ menu. Exporting a key works exactly like saving it (see section 8.2.8) – you need to have typed your passphrase in beforehand, and you will be warned if you are about to save a key without a passphrase.

Note that since only SSH2 keys come in different formats, the export options are not available if you have generated an SSH1 key.

8.3 Getting ready for public key authentication

Connect to your SSH server using PuTTY with the SSH protocol. When the connection succeeds you will be prompted for your user name and password to login. Once logged in, you must configure the server to accept your public key for authentication:

• If your server is using the SSH 1 protocol, you should change into the .ssh directory and open the file authorized_keys with your favourite editor. (You may have to create this file if this is the first key you have put in it). Then switch to the PuTTYgen window, select all of the text in the ‘Public key for pasting into authorized_keys file’ box (see section 8.2.10), and copy it to the clipboard (Ctrl+C). Then, switch back to the PuTTY window and insert the data into the open file, making sure it ends up all on one line. Save the file.
• If your server is OpenSSH and is using the SSH 2 protocol, you should follow the same instructions, except that in earlier versions of OpenSSH 2 the file might be called authorized_keys2. (In modern versions the same authorized_keys file is used for both SSH 1 and SSH 2 keys.)
• If your server is ssh.com‘s SSH 2 product, you need to save a public key file from PuTTYgen (see section 8.2.9), and copy that into the .ssh2 directory on the server. Then you should go into that .ssh2 directory, and edit (or create) a file called authorization. In this file you should put a line like Key mykey.pub, with mykey.pub replaced by the name of your key file.
• For other SSH server software, you should refer to the manual for that server.

You may also need to ensure that your home directory, your .ssh directory, and any other files involved (such as authorized_keys, authorized_keys2 or authorization) are not group-writable or world-writable. You can typically do this by using a command such as

chmod go-w $HOME $HOME/.ssh $HOME/.ssh/authorized_keys

Your server should now be configured to accept authentication using your private key. Now you need to configure PuTTY to attempt authentication using your private key. You can do this in any of three ways:

• Select the private key in PuTTY’s configuration. See section 4.18.5 for details.
• Specify the key file on the command line with the -i option. See section 3.7.3.14 for details.
• Load the private key into Pageant (see chapter 9). In this case PuTTY will automatically try to use it for authentication if it can.