cygwin SSHD auto fecha a conexão na conexão

Question

Eu corro o cygwin / sshd no Windows Vista. Eu costumava ser capaz de usar o ssh para se conectar ao meu computador, até recentemente ele começou a não funcionar (eu acho que instalei e removi alguns outros pacotes do cygwin)

Por exemplo, eu correria

ssh localhost -l kizzx2

depois de digitar a senha, eu estaria vendo isso

Last login: Sat Dec  5 02:44:11 2009 from 127.0.0.1
Connection to localhost closed.

O estranho problema é que, se eu me conectar usando outra conta, eu seria capaz de logar-se bem! O que significa:

ssh localhost -l Administrator

Isso me colocaria em uma concha interativa!

Parece que algumas configurações de perfil ou ambiente do perfil do meu usuário estão quebradas ou algo assim, mas não quero recriar meu perfil de usuário do zero criando uma nova conta.

Alguma idéia?

Atualização : Apenas por informações, eu tentei substituir ~/.ssh por clean (deixe um ssh compilar um a partir do zero). Não parece fazer o truque.

Este é o despejo completo da execução de ssh com -vvv :

$ ssh localhost -p 22 -vvv
OpenSSH_5.1p1, OpenSSL 0.9.8l 5 Nov 2009
debug1: Reading configuration data /cygdrive/k/.ssh/config
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 /cygdrive/k/.ssh/identity type -1
debug3: Not a RSA1 key file /cygdrive/k/.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
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /cygdrive/k/.ssh/id_rsa type 1
debug1: identity file /cygdrive/k/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1
debug1: match: OpenSSH_5.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: 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
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],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: 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
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
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-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 123/256
debug2: bits set: 516/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: put_host_port: [127.0.0.1]:22
debug3: put_host_port: [localhost]:22
debug3: check_host_in_hostfile: filename /cygdrive/k/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 12
debug1: Host '[localhost]:22' is known and matches the RSA host key.
debug1: Found key in /cygdrive/k/.ssh/known_hosts:12
debug2: bits set: 521/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: /cygdrive/k/.ssh/identity (0x0)
debug2: key: /cygdrive/k/.ssh/id_rsa (0x1052b88)
debug2: key: /cygdrive/k/.ssh/id_dsa (0x0)
debug1: Authentications that can continue: password,keyboard-interactive
debug3: start over, passed a different list password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
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: 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
kizzx2@localhost's password: 
debug3: packet_send2: adding 64 (len 58 padlen 6 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: tty_make_modes: ospeed 38400
debug3: tty_make_modes: ispeed 38400
debug2: channel 0: request shell confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Sat Dec  5 02:44:11 2009 from 127.0.0.1
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)

debug3: channel 0: close_fds r -1 w -1 e 6 c -1
Connection to localhost closed.
Transferred: sent 1712, received 2104 bytes, in 0.2 seconds
Bytes per second: sent 6875.5, received 8449.8
debug1: Exit status 0

    

Answer 1

Eu finalmente consegui trabalhar:

Eu estava tentando obter uma saída de depuração melhor do que ssh -vvv , então tentei executar

/usr/sbin/sshd -d

para capturar a saída na tela. Para minha surpresa, quando eu corri sshd desse jeito (não como um serviço como normalmente faria com net start sshd ), eu poderia logar como qualquer usuário.

Isso me levou a acreditar que o problema estava na forma como o serviço foi criado. Então eu apaguei o serviço e executei novamente o script de configuração. Bam! Está pronto!

cygrunsrv -R sshd
ssh-host-config
# it's fixed!

Editar : parece que o motivo é que o usuário de separação de privilégios não pode ser desativado no Windows. Costumava ser bom para mim desativar esse usuário de separação de privilégio e ainda fazê-lo funcionar, mas tudo bem.

    

Answer 2

Esse é um efeito típico de executar o script ssh-host-config uma vez, usando as seleções padrão típicas. O que acontece é que duas novas contas de usuário do Cygwin são criadas, mas suas configurações em / etc / passwd (e possivelmente / etc / groups) parecem temporárias. Depois da primeira execução, você tem o SHELL configurado como / bin / false e, se comparar isso com mkpasswd -l -u cyg_server , verá / bin / bash. Então, faça logoff e logon como e execute o Cygwin como admin, ou apenas faça a mudança em / etc / passwd e reinicie o serviço sshd.

    

Answer 3

no caminho do cygwin, como é o seu usuário no etc / passwd? É possível que um caminho de shell ausente / incorreto ou nenhum acesso ao seu diretório inicial cause esse comportamento. Verifique as permissões na sua pasta cygwin path home / kizzx2 também.