Jason --
Thanks for replying. I've attached the output of "cygcheck -s -v -r".
Frustratingly, it appears that after a reboot (required because my
company pushed some updates to my system), ssh to localhost no longer works.
If I stop the sshd service, start a command shell as "sshd_server",
start bash in that shell, and then run "/usr/sbin/sshd -d" I can see the
debug output from sshd. Here's what I believe is the pertinent bit of
that debug output:
Failed none for kasper from 127.0.0.1 port 4056 ssh2
debug1: userauth-request for user kasper service ssh-connection method
publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 1003/513 (e=1014/513)
seteuid 1003: Permission denied
debug1: do_cleanup
In the bash window from which I run ssh, I see this:
~ 506 $ ssh localhost
Connection closed by 127.0.0.1
It appears to be the failing "seteuid 1003" call that's the proximal
cause of the failure.
If, however, I run "/usr/sbin/sshd -d" in a command prompt + bash
session started as user "kasper", everything works:
~ 508 $ ssh localhost
Enter passphrase for key '/home/kasper/.ssh/id_rsa':
Warning: No xauth data; using fake authentication data for X11 forwarding.
Last login: Thu Dec 14 11:37:10 2006 from 127.0.0.1
Fanfare!!!
You are successfully logged in to this server!!!
debug1: permanently_set_uid: 1003/513
Environment:
[some environment vars snipped]
CYGWIN=binmode ntsec tty
USER=kasper
LOGNAME=kasper
HOME=/home/kasper
MAIL=/var/spool/mail/kasper
SHELL=/bin/bash
SSH_CLIENT=127.0.0.1 4083 22
SSH_CONNECTION=127.0.0.1 4083 127.0.0.1 22
SSH_TTY=/dev/tty3
TERM=ansi
Parsing .bash_profile .... Done.
~ 501 $
I used both ssh-host-config and ssh-user-config to set up sshd. I did
not use privilege separation, but I did configure sshd to run as a service.
The other problems I've been seeing are a Windows "Error 1062" message
when trying to start sshd and the "/bin/bash: permission denied" error I
mentioned in my previous post. I thought the "/bin/bash: permission
denied" error was resolved, but this failure also appears to involve
permissions.
I have a feeling most if not all the problems are caused by interactions
with the WinXP 2003 x64 security/permissions system, which I believe are
the same as those for WinXP Server 2003.
-Brian