Brent <brentley@xxxxxxxxxxxx> Date: Tue, 11 Nov 2003 16:59:00 -0600 To: redhat-list@xxxxxxxxxx
On Tue, 2003-11-11 at 16:48, L. Christopher Luther wrote:
I'm trying to use PuTTY to connect to a RH 8 box using SSH and a
password-less private key file. I have no trouble using PuTTY to connect to
this same server using SSH and password authentication -- it's only when I
use private/public key files.
I used the puttygen program to generate an RSA public and private key (I
also tried DSA keys), and put the resulting public key file in the RH user's
~/.ssh/authorized_keys file.
The ~/.ssh directory has mode 700 and authorized_keys has mode 644 (I also
tried mode 640). These modes were chosen because I searched the redhat-list
archives and discovered that someone else was receiving "Authentication
refused: bad ownership or modes for ..." messages.
These messages are now gone, but PuTTY now displays the following messages:
Using username "user".
Server refused our key
user@myserver's password:
I launch putty specifying the user name (-l username), private key file (-i private.ppk), and saved session (-load myserver). Any suggestions or ideas?
Sincerely,
L. Christopher Luther
I no longer use MS, so I have forgotten the details for PuTTY, but here are some things to keep in mind:
RSA keys are only used for ssh1. If you want ssh2, then use dsa keys only.
your ~/.ssh/authorized_keys file must have one key per line... watch out for line wrapping.
your ~/.ssh/authorized_keys file must have 600 permission.
Working from memory and without a net:
Apart from everything else, PuTTY generates keys in a different form from OpenSSH. Both RSA and DSA keys are available in SSH, in both PuTTY and OpenSSH, AFAIR.
I ended up going the other way. Create the key(s) you want in linux, using the appropriate ssh commands. These will be created in ~/.ssh. Copy the public key(s) into ~/.ssh/authorized_keys (SSH1 RSA) or ~/.ssh/authorized_keys2 (SSH2 RSA or DSA). The RSA1 keys are created by default as identity(.pub) and the RSA2 keys as id_rsa(.pub) and id_dsa(.pub). The files (except the .pub files) and the directory must have no group or other access permissions. I think this may apply to the authorized_keys* files as well. The authorized_keys* files are only necessary if you plan to connect to the machine containing them. If you are connecting from Windows to Linux, they need only be in the Linux user's .ssh directory.
Use Samba (or some other method to copy the keys over to the Windows machine. I was using XP, so they went into the user's directory under 'Documents and Settings'. I may have created a .ssh directory in there (using DOS commands) but it doesn't matter.
Import the ssh private keys into PuTTY. Here's where things get a little fuzzy. I *think* that the importing of the keys happens in puttygen. Save the files with a name that makes it easy for you to distinguish 1) the key type and 2) the fact that they are the imported keys.
It is very good idea to create a named PuTTY session with all of the required values (including the term parameters you want to use on the linux end). Use this session to verify connection with your keys. It will also be useful if you decide to use pageant to make life easier for the users by reducing the security of the system (which is what I understand you to want to do.)
Once you have this working, you can set up a desktop icon to run the named PuTTY session. I forget the details.
Set up a pageant desktop icon to run pageant, specifying the key or keys you want to cache in the command line. Try it out. It should ask you for the passphrase(s) for the key(s) you are caching. Once it is running, try the remote login PuTTY session icon. You should get in without having to re-type the passphrase.
Move the pageant icon to the startup directory, and you will be asked for the passphrases(s) on startup, and anyone who walks up to your unattended PC will be able to login to the Linux server as you.
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
-- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
