Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: "Stephen C. Biggs" To: cygwin AT cygwin DOT com Date: Sat, 3 Aug 2002 15:34:57 -0700 MIME-Version: 1.0 Subject: Son of SSH and Cygwin Message-ID: <3D4BF821.96.50E3B7D@localhost> Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body This is all related to my earlier post raising questions about SSH and Cygwin. I am running Win NT4 SP6a with the lastest cygwin updates. I am trying to login with another user to SSH. I am logged in as 'user1' which is also administrator on my NT box. I execute ssh -l user2 localhost. I connected user2 (with no password) and then generated the dsa key for user2 while connected to ssh so I could get the proper user. My .ssh directories now look like this: on the client side: -rw------- id_dsa (user2's private key) -rw-r--r-- id_dsa.pub (user2's public key) -rw-r--r-- authorized_keys2 (copy of id_dsa.pub) on the server side: -rw-r--r-- authorized_keys (copy of id_dsa.pub) -rw-r--r-- authorized_keys2 (copy of id_dsa.pub) Now, it seems to connect and authenticate just fine, but then the server dumps me right away without a reason why (at least I can't see it). I am running sshd with -ddd for the fullest debug (meaning I have to restart it everytime, since it doesn't become a daemon), and here is the output from the accepted authentication onward (I have obfuscated the keys, etc): debug2: userauth_pubkey: authenticated 1 pkalg ssh-dss Accepted publickey for user2 from 127.0.0.1 port ssh2 debug3: mm_send_keystate: Sending new keys: 0x 0x debug3: mm_newkeys_to_blob: converting 0x debug3: mm_newkeys_to_blob: converting 0x debug3: mm_send_keystate: New keys have been sent debug3: mm_send_keystate: Sending compression state debug3: mm_request_send entering: type 24 debug3: mm_send_keystate: Finished sending state debug3: mm_newkeys_from_blob: 0x debug2: mac_init: found debug3: mm_get_keystate: Waiting for second key debug3: mm_newkeys_from_blob: 0x debug2: mac_init: found debug3: mm_get_keystate: Getting compression state debug3: mm_get_keystate: Getting Network I/O buffers debug3: mm_share_sync: Share sync debug3: mm_share_sync: Share sync end debug1: newkeys: mode 0 debug1: newkeys: mode 1 debug1: Entering interactive session for SSH2. debug1: fd 3 setting O_NONBLOCK debug1: fd 7 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 0 request pty-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_pty_req: session 0 alloc /dev/tty2 debug3: tty_parse_modes: SSH2 n_bytes 246 debug3: tty_parse_modes: ospeed 38400 debug3: tty_parse_modes: ispeed 38400 debug3: tty_parse_modes: 1 3 debug3: tty_parse_modes: 2 28 debug3: tty_parse_modes: 3 8 debug3: tty_parse_modes: 4 21 debug3: tty_parse_modes: 5 4 debug3: tty_parse_modes: 6 0 debug3: tty_parse_modes: 7 0 debug3: tty_parse_modes: 8 17 debug3: tty_parse_modes: 9 19 debug3: tty_parse_modes: 10 26 debug3: tty_parse_modes: 12 18 debug3: tty_parse_modes: 13 23 debug3: tty_parse_modes: 14 22 debug3: tty_parse_modes: 18 15 debug3: tty_parse_modes: 30 0 debug3: tty_parse_modes: 31 0 debug3: tty_parse_modes: 32 0 debug3: tty_parse_modes: 33 0 debug3: tty_parse_modes: 34 0 debug3: tty_parse_modes: 35 0 debug3: tty_parse_modes: 36 1 debug3: tty_parse_modes: 37 0 debug3: tty_parse_modes: 38 1 debug3: tty_parse_modes: 39 0 debug3: tty_parse_modes: 40 0 debug3: tty_parse_modes: 41 0 debug3: tty_parse_modes: 50 1 debug3: tty_parse_modes: 51 1 debug3: tty_parse_modes: 53 1 debug3: tty_parse_modes: 54 0 debug3: tty_parse_modes: 55 0 debug3: tty_parse_modes: 56 0 debug3: tty_parse_modes: 57 0 debug3: tty_parse_modes: 58 0 debug3: tty_parse_modes: 59 1 debug3: tty_parse_modes: 60 0 debug3: tty_parse_modes: 61 0 debug3: tty_parse_modes: 70 1 debug3: tty_parse_modes: 71 0 debug3: tty_parse_modes: 72 1 debug3: tty_parse_modes: 73 0 debug3: tty_parse_modes: 74 0 debug3: tty_parse_modes: 75 0 debug3: tty_parse_modes: 90 1 debug3: tty_parse_modes: 91 1 debug3: tty_parse_modes: 92 0 debug3: tty_parse_modes: 93 0 debug1: server_input_channel_req: channel 0 request shell reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell debug1: fd 4 setting TCP_NODELAY debug1: channel 0: rfd 9 isatty debug1: fd 9 setting O_NONBLOCK debug1: fd 8 setting O_NONBLOCK Write failed: Cannot send after transport endpoint shutdown debug1: Calling cleanup 0x415dc4(0x44aaf0) debug1: session_pty_cleanup: session 0 release /dev/tty2 debug1: Calling cleanup 0x427360(0x0) debug1: channel_free: channel 0: server-session, nchannels 1 debug3: channel_free: status: The following connections are open: #0 server-session (t4 r0 i0/263 o0/0 fd 9/8) debug3: channel_close_fds: channel 0: r 9 w 8 e -1 debug1: Calling cleanup 0x41c9c0(0x0) Does anybody have clue as to why this could be happening? I see the failed write, but that seems to be happening after the connection is dumped, with no reason given. I can login to user2 just fine if I use a blank password. -- 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/