X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: =?ISO-8859-1?Q?Ren=E9_Berber?= <r DOT berber AT computer DOT org>
Subject:  Re: password authentication fails in cygwin openssh windows xp pro
Date:  Thu, 24 May 2007 20:52:14 -0500
Lines: 130
Message-ID: <f35fgh$6vt$1@sea.gmane.org>
References:  <4655A077 DOT 60407 AT gmail DOT com> <Pine DOT LNX DOT 4 DOT 58 DOT 0705241028510 DOT 18442 AT dargo DOT trilug DOT org> <4655A398 DOT 80504 AT u DOT washington DOT edu> <f354ln$t9h$1 AT sea DOT gmane DOT org> <4656341F DOT 2000603 AT u DOT washington DOT edu>
Mime-Version:  1.0
Content-Type:  text/plain; charset=ISO-8859-1
Content-Transfer-Encoding:  quoted-printable
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
In-Reply-To: <4656341F.2000603@u.washington.edu>
OpenPGP: url=hkp://wwwkeys.pgp.net
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Dan Miller wrote:

> After trying everything possible as described in my first e-mail I
> reset/uninstalled everything including cygwin, registry entries, path
> variables, cygwin variables etc. Then I reinstalled cygwin and openssh,
> ran ssh-host-config and emailed this list server. So you are right, I
> currently had not run ssh-user-config on this install. I also no longer
> have a sshdproc user with the rights I originally stated because I
> wanted to start from scratch. I wasn't sure how much I had done before
> was right or wrong. So, I now ran ssh-user-config and generated key
> files. they ended up in /home/dan/.ssh as you suggested. I cat'd them to
> authorized keys and still there is a login problem. It appears the key
> file format may be wrong. here is the output now of ssh -vvv localhost.
>=20
> Should I recreate the sshdproc user with appropriate rights before we
> continue?

No.  If the server, sshd, had any problem it would show.

Did you add the correct key to authorized servers?  It's only one of id_dsa=
.pub
or id_rsa.pub, and you say "them" which is wrong, also using private keys is
wrong... it's not clear what you did.

> OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
> debug1: Reading configuration data /etc/ssh_config
> debug2: ssh_connect: needpriv 0
> debug1: Connecting to localhost [127.0.0.1] port 22.
> debug1: Connection established.
> debug1: identity file /home/dan/.ssh/identity type -1
> debug3: Not a RSA1 key file /home/dan/.ssh/id_rsa.
> debug2: key_type_from_name: unknown key type '-----BEGIN'
> debug3: key_read: missing keytype
> debug2: key_type_from_name: unknown key type 'Proc-Type:'
> debug3: key_read: missing keytype
> debug2: key_type_from_name: unknown key type 'DEK-Info:'
> debug3: key_read: missing keytype
> debug3: key_read: missing whitespace
...
> debug2: key_type_from_name: unknown key type '-----END'
> debug3: key_read: missing keytype

All these "missing" are normal, that's the way things work.

> debug1: identity file /home/dan/.ssh/id_rsa type 1
> debug1: identity file /home/dan/.ssh/id_dsa type -1

This means the private rsa key is OK, the dsa key is not there (which is no
problem, only one is needed).

> debug1: Remote protocol version 1.99, remote software version OpenSSH_4.6

Weird, version should be 2.0 if you have the latest from Cygwin, which seem=
s to
be the case from the first line above... any chance you have another server
installed? doesn't look like it, since it is opening all the right files.

> debug1: match: OpenSSH_4.6 pat OpenSSH*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_4.6
> debug2: fd 3 setting O_NONBLOCK
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug2: kex_parse_kexinit:
...
> debug1: Host 'localhost' is known and matches the RSA host key.
> debug1: Found key in /home/dan/.ssh/known_hosts:1
> debug2: bits set: 514/1024
> debug1: ssh_rsa_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: SSH2_MSG_SERVICE_REQUEST sent
> debug2: service_accept: ssh-userauth
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug2: key: /home/dan/.ssh/identity (0x0)
> debug2: key: /home/dan/.ssh/id_rsa (0x6aa608)
> debug2: key: /home/dan/.ssh/id_dsa (0x0)
> debug1: Authentications that can continue: publickey,password
> debug3: start over, passed a different list publickey,password
> 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: Trying private key: /home/dan/.ssh/identity
> debug3: no such identity: /home/dan/.ssh/identity
> debug1: Offering public key: /home/dan/.ssh/id_rsa
> debug3: send_pubkey_test
> debug2: we sent a publickey packet, wait for reply

The key didn't work, as I said above: maybe you stored the wrong key.

> debug1: Authentications that can continue: publickey,password
> debug1: Trying private key: /home/dan/.ssh/id_dsa
> debug3: no such identity: /home/dan/.ssh/id_dsa
> debug2: we did not send a packet, disable method
> debug3: authmethod_lookup password
> debug3: remaining preferred: ,password
> debug3: authmethod_is_enabled password
> debug1: Next authentication method: password

Then it tries passwords again...

> debug3: packet_send2: adding 64 (len 48 padlen 16 extra_pad 64)
> debug2: we sent a password packet, wait for reply
> debug1: Authentications that can continue: publickey,password
> Permission denied, please try again.

translation: wrong password.

Have you checked Windows' Event Viewer? the server (sshd) must be logging
events, probably with the same information but perhaps with the real cause =
of
the problem.
--=20
Ren=E9 Berber


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