Re: Can't get authorized_keys to work

["David Christensen" <dpchrist at holgerdanske dot com>]

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 at \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 <angle brackets>:

August 19, 2002

<editorial comment -- log in to SSH client machine>

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:
        <editorial comment -- fingerprint removed>

<editorial comment -- directory "~/.ssh" needs to exist on SSH server
 machine>

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

<editorial comment -- log in to SSH server>

3.  Locate and remove all r7320g entries in authorized_keys file on
    CVS server:

        dpchrist at r732g5:~/.ssh$ vi authorized_keys

<editorial comment -- check/correct line endings of your id_rsa.pub file
on the server at this point>

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/