Re: openssh authentification
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 B3NzaC1yc... 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
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 B3NzaC1yc... 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
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 B3NzaC1yc... 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
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 B3NzaC1yc... 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
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 signature.asc Description: Digital signature
RE: openssh authentification
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
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 signature.asc Description: Digital signature
RE: openssh authentification
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
openssh authentification
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-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@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-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-dss-cert-...@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-...@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-...@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,z...@openssh.com,zlib debug2: kex_parse_kexinit: none,z...@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-...@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-...@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit:
