Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <009801c2fec2$1f31c0a0$0b01a8c0@w2k30g> From: "David Christensen" To: "Neil Aggarwal" Cc: References: Subject: Re: Can't get authorized_keys to work Date: Wed, 9 Apr 2003 11:01:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Neil wrote: > [neil AT www .ssh]$ file * > authorized_keys: ASCII text Okay -- the server seems to have the right line endings. I suggested it because I remember going around in circles trying to get SSH keys working, and that line endings was the stupid issue causing all the grief. What about the client -- Cygwin line ending configuration (DOS or Unix) and line endings of files in ~/.ssh ? Have you tried using a different SSH client and/or SSH server to isolate the issue? One possible client for Win32 is putty: http://www.chiark.greenend.org.uk/~sgtatham/putty/ I was running Cygwin SSH 3.5p1, so I upgraded to 3.6.1p1 to match yours. Here is a debug session: dpchrist AT w2k30g:~$ ssh -v 192.168.254.2 OpenSSH_3.6p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: Connecting to 192.168.254.2 [192.168.254.2] port 22. debug1: Connection established. debug1: identity file /home/dpchrist/.ssh/identity type -1 debug1: identity file /home/dpchrist/.ssh/id_rsa type 1 debug1: identity file /home/dpchrist/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.1p1 debug1: match: OpenSSH_3.1p1 pat OpenSSH_2.*,OpenSSH_3.0*,OpenSSH_3.1* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.6p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host '192.168.254.2' is known and matches the RSA host key. debug1: Found key in /home/dpchrist/.ssh/known_hosts:4 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Trying private key: /home/dpchrist/.ssh/identity debug1: Offering public key: /home/dpchrist/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 149 lastkey 0x100f90d8 hint 1 debug1: read PEM private key done: type RSA debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: channel 0: request pty-req debug1: channel 0: request shell debug1: channel 0: open confirm rwindow 0 rmax 32768 Last login: Wed Apr 9 10:03:28 2003 from 192.168.1.11 dpchrist AT r7310g:~$ Things diverge when my client says: debug1: Offering public key: /home/dpchrist/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 149 lastkey 0x100f90d8 hint 1 And yours says: debug1: Offering public key: /home/Neil Aggarwal/.ssh/id_rsa debug1: Authentications that can continue: publickey,password,keyboard-interactive It looks like your client is offering the RSA public key and your server is rejecting it. At this point, I'd start over again and would be completely anal about the process. First, change your prompts on Cygwin and your server as follows so that you know for sure which account, host, and working directory you're in: dpchrist AT r7310g:~$ grep PS1 .bash_profile export PS1='\u@\h:\w$ ' See the following commented log file from one of my boxes for a suggested process. As you do your work, cut and paste every single command and it's output into a log file. If it works, save the log file for the next time around. If it doesn't, post the log here and maybe someone will spot the error. HTH, David p.s. -- Here is a log from when I set up a RH7.3 Linux SSH client (account root AT r7320g) to connect to a RH7.3 Linux SSH server (account dpchrist AT r732g5). Note the editorial comments in : August 19, 2002 1. Generate SSH keypair: [root AT r7320g root]# ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: 2. Copy public key to CVS server: [root AT r7320g root]# scp .ssh/id_rsa.pub dpchrist AT 192 DOT 168 DOT 1 DOT 1:.ss h/root-r7320g-id_rsa.pub dpchrist AT 192 DOT 168 DOT 1 DOT 1's password: id_rsa.pub 100% |*****************************| 233 00:00 3. Locate and remove all r7320g entries in authorized_keys file on CVS server: dpchrist AT r732g5:~/.ssh$ vi authorized_keys 4. Append root AT 7320g public key to authorized_keys on CVS server: dpchrist AT r732g5:~/.ssh$ cat root-r7320g-id_rsa.pub >> authorized _keys p.p.s. -- Also note the following comment from a previous attempt. I think the above instructions in step (4) were my solution to the problem described: June 13, 2002 You need to add the contents of root-r7320g-id_rsa.pub to authorized_keys. I have variously tried cp, cat, and vi. No one method works consistently. For some unknown reason, authorized_keys ends up two bytes longer than root-r7320g-id_rsa.pub. Save your authorized_keys first. Then try one method. Log out and log in again. If a password is required, the method failed. Try another one. Keep trying until you can login without a password. p.p.p.s. -- Here is a log entry regarding an SSH server tuning issue that you might want to look at: October 27, 2002 1. sshd is doing DNS lookups for LAN hosts. This causes delays/ timeouts, especially when DNS is unavailable. sshd has /etc/rc.d control scripts, specifically /etc/rc.d/init.d/sshd. This file reads and sources /etc/sysconfig/sshd, if it exists, to pull in Bash variables such as OPTIONS. RH7.3 didn't seem to install the later file, so create it with the following contents: # Additional options for sshd OPTIONS="-u0" Restart sshd: root AT r7310g:~$ service sshd restart Stopping sshd: [ OK ] Starting sshd: [ OK ] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/