openssh authentification

openssh authentification

[Clayton Evans]

I have installed OpenSSH_5.9p1 on two machines, the host machine and the client machine.

The host machine is Windows 7 (64-bit) named jti031

The client machine is Windows XP (32-bit)

On the host machine ssh-host-config was run.  Testing with 'ssh localhost' resulted in the ssh prompt for a password, the windows domain password was accepted by ssh and ssh logged in.  Then ssh-user-config was run on the host.  Testing with 'ssh localhost' resulted in ssh logged in with no request for a password.  I conclude that all is well on the host.

On the client machine ssh-user-config was run.  Testing with 'ssh -vvv jti031' does not log in.  All the public keys do not work and the Windows domain password was not accepted.  I have probably made some rookie mistake with the keys, but why password authentication does not work baffles me.

$ ssh -vvv jti031
OpenSSH_5.9p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to jti031 [192.168.58.29] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/cevans/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/cevans/.ssh/id_rsa type 1
debug1: identity file /home/cevans/.ssh/id_rsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/cevans/.ssh/id_dsa" as a RSA1 public key
debug1: identity file /home/cevans/.ssh/id_dsa type 2
debug1: identity file /home/cevans/.ssh/id_dsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/cevans/.ssh/id_ecdsa" as a RSA1 public key
debug1: identity file /home/cevans/.ssh/id_ecdsa type 3
debug1: identity file /home/cevans/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9
debug1: match: OpenSSH_5.9 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "jti031" from file "/home/cevans/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/cevans/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 42:04:0a:2f:7e:07:06:86:79:bf:e8:28:8a:eb:6c:21
debug3: load_hostkeys: loading entries for host "jti031" from file "/home/cevans/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/cevans/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "192.168.58.29" from file "/home/cevans/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/cevans/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'jti031' is known and matches the ECDSA host key.
debug1: Found key in /home/cevans/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/cevans/.ssh/id_rsa (0x4f7468)
debug2: key: /home/cevans/.ssh/id_dsa (0x4f9be8)
debug2: key: /home/cevans/.ssh/id_ecdsa (0x4fb328)
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/cevans/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering DSA public key: /home/cevans/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering ECDSA public key: /home/cevans/.ssh/id_ecdsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: userauth_kbdint: disable: no info_req_seen
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred:
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
cevans@jti031's password:
debug3: packet_send2: adding 64 (len 59 padlen 5 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Permission denied, please try again.
cevans@jti031's password:
debug3: packet_send2: adding 64 (len 59 padlen 5 extra_pad 64)
debug2: we sent a password packet, wait for reply
Received disconnect from 192.168.58.29: 2: Too many authentication failures for cevans

Clayton Evans

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: openssh authentification

[Andrew Schulman]

> debug1: Next authentication method: publickey
> debug1: Offering RSA public key: /home/cevans/.ssh/id_rsa
> debug3: send_pubkey_test
> debug2: we sent a publickey packet, wait for reply
> debug1: Authentications that can continue: publickey,password,keyboard-interactive
> debug1: Offering DSA public key: /home/cevans/.ssh/id_dsa
> debug3: send_pubkey_test
> debug2: we sent a publickey packet, wait for reply
> debug1: Authentications that can continue: publickey,password,keyboard-interactive
> debug1: Offering ECDSA public key: /home/cevans/.ssh/id_ecdsa
> debug3: send_pubkey_test
> debug2: we sent a publickey packet, wait for reply
> debug1: Authentications that can continue: publickey,password,keyboard-interactive
> debug2: we did not send a packet, disable method

So all three of those keys were offered, but none were accepted.  Are the
public keys for those in your ~/.ssh/authorized_keys file on the server?

Do you by chance have any "from" restrictions on the keys in
authorized_keys?  For example,

from="localhost" ssh-rsa AAAAB3NzaC1yc...

That could cause the server to reject the keys.

> debug1: Next authentication method: password
> cevans@jti031's password:
> debug3: packet_send2: adding 64 (len 59 padlen 5 extra_pad 64)
> debug2: we sent a password packet, wait for reply
> debug1: Authentications that can continue: publickey,password,keyboard-interactive
> Permission denied, please try again.

Not sure what would cause that.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: openssh authentification

[Clayton Evans]

> > debug1: Next authentication method: publickey
> > debug1: Offering RSA public key: /home/cevans/.ssh/id_rsa
> > debug3: send_pubkey_test
> > debug2: we sent a publickey packet, wait for reply
> > debug1: Authentications that can continue: 
> > publickey,password,keyboard-interactive
> > debug1: Offering DSA public key: /home/cevans/.ssh/id_dsa
> > debug3: send_pubkey_test
> > debug2: we sent a publickey packet, wait for reply
> > debug1: Authentications that can continue: 
> > publickey,password,keyboard-interactive
> > debug1: Offering ECDSA public key: /home/cevans/.ssh/id_ecdsa
> > debug3: send_pubkey_test
> > debug2: we sent a publickey packet, wait for reply
> > debug1: Authentications that can continue: 
> > publickey,password,keyboard-interactive
> > debug2: we did not send a packet, disable method
>
> So all three of those keys were offered, but none were accepted.  Are the public keys for those in your ~/.ssh/authorized_keys file on the > server?
>
> Do you by chance have any "from" restrictions on the keys in authorized_keys?  For example,
>
> from="localhost" ssh-rsa AAAAB3NzaC1yc...
>
> That could cause the server to reject the keys.
>
> > debug1: Next authentication method: password cevans@jti031's password:
> > debug3: packet_send2: adding 64 (len 59 padlen 5 extra_pad 64)
> > debug2: we sent a password packet, wait for reply
> > debug1: Authentications that can continue: 
> > publickey,password,keyboard-interactive
> > Permission denied, please try again.
>
> Not sure what would cause that.
> 
> 

I copied the .ssh/authorized_keys file from the client to the host before the ssh -vvv jti031 was done.

I have not intentionally added any "from" restrictions on the keys.  From your question I infer that this would be in the authorized_keys file.  The lines in the authorized_keys file begin with ssh-rsa ..., ssh-dss ..., ecdsa-sha2-nistp256 ....  The lines all end with a white space and <userid>@<clientname>, where <userid> and <clientname> have my user id and client machine name, jti023.

Permissions in .ssh on the client are:
$ ls -l
total 19
-rw-r--r-- 1 cevans Administrators 1816 Oct 13 15:24 authorized_keys
-rw------- 1 cevans Administrators  668 Oct 13 15:24 id_dsa
-rw-r--r-- 1 cevans Administrators  603 Oct 13 15:24 id_dsa.pub
-rw------- 1 cevans Administrators  227 Oct 13 15:24 id_ecdsa
-rw-r--r-- 1 cevans Administrators  175 Oct 13 15:24 id_ecdsa.pub
-rw------- 1 cevans Administrators 1679 Oct 13 15:24 id_rsa
-rw-r--r-- 1 cevans Administrators  395 Oct 13 15:24 id_rsa.pub
-rw------- 1 cevans Administrators  978 Oct 13 15:24 identity
-rw-r--r-- 1 cevans Administrators  643 Oct 13 15:24 identity.pub
-rw-r--r-- 1 cevans Administrators  182 Oct 13 15:43 known_hosts

$ ls -ld .ssh
drwx------+ 1 cevans Administrators 0 Oct 14 09:23 .ssh

Permissions on the host are:
-rw-------+ 1 CEvans Administrators 1679 Oct  3 15:13 id_rsa
-rw-r--r--+ 1 CEvans Administrators  395 Oct  3 15:13 id_rsa.pub
-rw-r--r--+ 1 CEvans Administrators  603 Oct  3 15:13 id_dsa.pub
-rw-------+ 1 CEvans Administrators  668 Oct  3 15:13 id_dsa
-rw-r--r--+ 1 CEvans Administrators  175 Oct  3 15:14 id_ecdsa.pub
-rw-------+ 1 CEvans Administrators  227 Oct  3 15:14 id_ecdsa
-rw-------+ 1 CEvans Administrators  978 Oct  3 15:14 identity
-rw-r--r--+ 1 CEvans Administrators  643 Oct  3 15:14 identity.pub
-rw-r--r--+ 1 CEvans Administrators   48 Oct  4 16:36 authorization
-rw-------+ 1 CEvans Administrators 1816 Oct 13 15:24 authorized_keys

drwxr-xr-x+ 1 CEvans Administrators 0 Oct 14 09:46 /cygdrive/d/home/cevans/.ssh

Clayton Evans

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: openssh authentification

[Andrew Schulman]

> > > debug1: Next authentication method: publickey
> > > debug1: Offering RSA public key: /home/cevans/.ssh/id_rsa
> > > debug3: send_pubkey_test
> > > debug2: we sent a publickey packet, wait for reply
> > > debug1: Authentications that can continue: 
> > > publickey,password,keyboard-interactive
> > > debug1: Offering DSA public key: /home/cevans/.ssh/id_dsa
> > > debug3: send_pubkey_test
> > > debug2: we sent a publickey packet, wait for reply
> > > debug1: Authentications that can continue: 
> > > publickey,password,keyboard-interactive
> > > debug1: Offering ECDSA public key: /home/cevans/.ssh/id_ecdsa
> > > debug3: send_pubkey_test
> > > debug2: we sent a publickey packet, wait for reply
> > > debug1: Authentications that can continue: 
> > > publickey,password,keyboard-interactive
> > > debug2: we did not send a packet, disable method
> >
> > So all three of those keys were offered, but none were accepted.  Are the public keys for those in your ~/.ssh/authorized_keys file on the > server?
> 
> I copied the .ssh/authorized_keys file from the client to the host before the ssh -vvv jti031 was done.

OK, but that's not exactly what I asked.  The question is, is one of those
public keys (/home/cevans/.ssh/id_rsa.pub, /home/cevans/.ssh/id_dsa.pub, or
/home/cevans/.ssh/id_ecdsa.pub from the client) in ~/.ssh/authorized_keys
on the server?

> > Do you by chance have any "from" restrictions on the keys in authorized_keys?  For example,
> >
> > from="localhost" ssh-rsa AAAAB3NzaC1yc...
> >
> > That could cause the server to reject the keys.
> 
> I have not intentionally added any "from" restrictions on the keys.  From
> your question I infer that this would be in the authorized_keys file.

Correct, see AUTHORIZED_KEYS FILE FORMAT in sshd(8).

> The lines in the authorized_keys file begin with ssh-rsa ..., ssh-dss ..., 
> ecdsa-sha2-nistp256 ....  The lines all end with a white space and 
> <userid>@<clientname>, where <userid> and <clientname> have my user id and 
> client machine name, jti023.

OK, so the answer to that is no.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: openssh authentification

[Clayton Evans]

> > > > debug1: Next authentication method: publickey
> > > > debug1: Offering RSA public key: /home/cevans/.ssh/id_rsa
> > > > debug3: send_pubkey_test
> > > > debug2: we sent a publickey packet, wait for reply
> > > > debug1: Authentications that can continue: 
> > > > publickey,password,keyboard-interactive
> > > > debug1: Offering DSA public key: /home/cevans/.ssh/id_dsa
> > > > debug3: send_pubkey_test
> > > > debug2: we sent a publickey packet, wait for reply
> > > > debug1: Authentications that can continue: 
> > > > publickey,password,keyboard-interactive
> > > > debug1: Offering ECDSA public key: /home/cevans/.ssh/id_ecdsa
> > > > debug3: send_pubkey_test
> > > > debug2: we sent a publickey packet, wait for reply
> > > > debug1: Authentications that can continue: 
> > > > publickey,password,keyboard-interactive
> > > > debug2: we did not send a packet, disable method
> > >
> > > So all three of those keys were offered, but none were accepted.  Are the public keys for those in your ~/.ssh/authorized_keys file on the > server?
> > 
> > I copied the .ssh/authorized_keys file from the client to the host before the ssh -vvv jti031 was done.
>
> OK, but that's not exactly what I asked.  The question is, is one of those public keys (/home/cevans/.ssh/id_rsa.pub, /home/cevans/.ssh/id_dsa.pub, or /home/cevans/.ssh/id_ecdsa.pub from the client) in ~/.ssh/authorized_keys on the server?

No, the id_*.pub files were not copied.   

I have now copied all three id_*.pub files from the client to the host.  I have rerun 'ssh -vvv jti031' with identical results. (At least diff finds the results to be identical.)

> > Do you by chance have any "from" restrictions on the keys in 
> > authorized_keys?  For example,
> >
> > from="localhost" ssh-rsa AAAAB3NzaC1yc...
> >
> > That could cause the server to reject the keys.
> 
> I have not intentionally added any "from" restrictions on the keys.  
> From your question I infer that this would be in the authorized_keys file.

Correct, see AUTHORIZED_KEYS FILE FORMAT in sshd(8).

> The lines in the authorized_keys file begin with ssh-rsa ..., ssh-dss 
> ...,
> ecdsa-sha2-nistp256 ....  The lines all end with a white space and 
> <userid>@<clientname>, where <userid> and <clientname> have my user id 
> and client machine name, jti023.

OK, so the answer to that is no.



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: openssh authentification

[David Sastre]

[-- Attachment #1: Type: text/plain, Size: 2026 bytes --]

On Fri, Oct 14, 2011 at 01:43:57PM -0500, Clayton Evans wrote:
> > > > > debug1: Next authentication method: publickey
> > > > > debug1: Offering RSA public key: /home/cevans/.ssh/id_rsa
> > > > > debug3: send_pubkey_test
> > > > > debug2: we sent a publickey packet, wait for reply
> > > > > debug1: Authentications that can continue: 
> > > > > publickey,password,keyboard-interactive
> > > > > debug1: Offering DSA public key: /home/cevans/.ssh/id_dsa
> > > > > debug3: send_pubkey_test
> > > > > debug2: we sent a publickey packet, wait for reply
> > > > > debug1: Authentications that can continue: 
> > > > > publickey,password,keyboard-interactive
> > > > > debug1: Offering ECDSA public key: /home/cevans/.ssh/id_ecdsa
> > > > > debug3: send_pubkey_test
> > > > > debug2: we sent a publickey packet, wait for reply
> > > > > debug1: Authentications that can continue: 
> > > > > publickey,password,keyboard-interactive
> > > > > debug2: we did not send a packet, disable method
> > > >
> > > > So all three of those keys were offered, but none were accepted.  Are the public keys for those in your ~/.ssh/authorized_keys file on the > server?
> > > 
> > > I copied the .ssh/authorized_keys file from the client to the host before the ssh -vvv jti031 was done.
> >
> > OK, but that's not exactly what I asked.  The question is, is one of those public keys (/home/cevans/.ssh/id_rsa.pub, /home/cevans/.ssh/id_dsa.pub, or /home/cevans/.ssh/id_ecdsa.pub from the client) in ~/.ssh/authorized_keys on the server?
> 
> No, the id_*.pub files were not copied.   
> 
> I have now copied all three id_*.pub files from the client to the host.  I have rerun 'ssh -vvv jti031' with identical results. (At least diff finds the results to be identical.)

I'd double-check StrictModes and PubkeyAuthentication in sshd_config.
Also, there's no need to copy around your pub keys manually, use
ssh-copy-id(1) for that.

-- 
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179  60E7 F79B AB04 5299 EC56

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

RE: openssh authentification

[Clayton Evans]

> > > > > > debug1: Next authentication method: publickey
> > > > > > debug1: Offering RSA public key: /home/cevans/.ssh/id_rsa
> > > > > > debug3: send_pubkey_test
> > > > > > debug2: we sent a publickey packet, wait for reply
> > > > > > debug1: Authentications that can continue: 
> > > > > > publickey,password,keyboard-interactive
> > > > > > debug1: Offering DSA public key: /home/cevans/.ssh/id_dsa
> > > > > > debug3: send_pubkey_test
> > > > > > debug2: we sent a publickey packet, wait for reply
> > > > > > debug1: Authentications that can continue: 
> > > > > > publickey,password,keyboard-interactive
> > > > > > debug1: Offering ECDSA public key: /home/cevans/.ssh/id_ecdsa
> > > > > > debug3: send_pubkey_test
> > > > > > debug2: we sent a publickey packet, wait for reply
> > > > > > debug1: Authentications that can continue: 
> > > > > publickey,password,keyboard-interactive
> > > > > > debug2: we did not send a packet, disable method
> > > > >
> > > > > So all three of those keys were offered, but none were accepted.  Are the public keys for those in your ~/.ssh/authorized_keys file on the server?
> > > > 
> > > > I copied the .ssh/authorized_keys file from the client to the host before the ssh -vvv jti031 was done.
> > >
> > > OK, but that's not exactly what I asked.  The question is, is one of those public keys (/home/cevans/.ssh/id_rsa.pub, /home/cevans/.ssh/id_dsa.pub, or /home/cevans/.ssh/id_ecdsa.pub from the client) in ~/.ssh/authorized_keys on the server?
> > 
> > No, the id_*.pub files were not copied.   
> > 
> > I have now copied all three id_*.pub files from the client to the host.  I have rerun 'ssh -vvv jti031' with identical results. (At least diff finds the results to be identical.)
>
> I'd double-check StrictModes and PubkeyAuthentication in sshd_config.
> Also, there's no need to copy around your pub keys manually, use
> ssh-copy-id(1) for that.

ssh-copy-id requires that password authentication is working, which is not happening, so I tried manual moving of the files

Clayton Evans

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: openssh authentification

[David Sastre]

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

On Fri, Oct 14, 2011 at 03:28:14PM -0500, Clayton Evans wrote:
> > I'd double-check StrictModes and PubkeyAuthentication in sshd_config.
 
> ssh-copy-id requires that password authentication is working, which is not happening, so I tried manual moving of the files

Sorry, I obviously overlooked that.
I assume sshd_config is properly configured to allow public key
authentication.

Have you checked your /etc/passwd and /etc/group files?

Does the user guide¹ help?

¹http://cygwin.com/cygwin-ug-net/ntsec.html

-- 
Huella de clave primaria: AD8F BDC0 5A2C FD5F A179  60E7 F79B AB04 5299 EC56

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

RE: openssh authentification

[Clayton Evans]

> > ssh-copy-id requires that password authentication is working, which is 
> > not happening, so I tried manual moving of the files
> 
> Sorry, I obviously overlooked that.
> I assume sshd_config is properly configured to allow public key authentication.
> 
> Have you checked your /etc/passwd and /etc/group files?
> 
> Does the user guide¹ help?
> 
> ¹http://cygwin.com/cygwin-ug-net/ntsec.html

I have the default sshd_config.  Doing a ssh localhost on host works, both with password authentication and with public key authentication after running ssh-user-config on the host.  So I would say that yes sshd_config is configured to do public key authentication.

I have looked at /etc/passwd and /etc/group on the host and client machines.  The Sid match for the group and userid that I am using.  Other portions of Cygwin act correctly for my domain userid on both the host and the client machines.  So I think that /etc/passwd and /etc/group are OK.  Is there anything specific I should be checking in these files?

I am off on vacation for a week now, so I will not be able to progress this problem until 24 October 2011.

Clayton Evans


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple