Não é possível fazer login ou ssh para usuários não-admin do Cygwin este mês, mas poderia no mês passado e ainda pode para outro usuário não administrador

Question

Eu li o que parece quase todos os links do Google sobre a variação deste problema, mas nenhum deles parece se aplicar e isso está me desconcertando.

Além das minhas muitas máquinas Linux, tenho um laptop Windows 10 com Cygwin instalado, completamente atualizado com atualizações do Windows e atualizações do Cygwin por meio de seu arquivo de configuração. Ele tem um usuário administrador (estritamente para manutenção) e duas contas de usuário não administrativas atribuídas ao grupo Usuário (e membro de nenhum outro grupo) para operação diária. Todas as três contas funcionaram perfeitamente durante anos, com o Cygwin sendo capaz de lançar seu respectivo terminal cygwin e / ou efetuar login no localhost via SSH. Este mês, por algum motivo desconhecido, a conta User1 parou de poder iniciar o terminal Cygwin. Em vez disso, sempre é solicitada uma senha administrativa. Se você selecionar NO, o terminal Cygwin nunca será aberto. Se você clicar em YES e fornecer a senha de administrador, não será realmente logado como User1 e isso é um problema porque o User1 NÃO precisa ser Admin E precisa acessar seus próprios arquivos git, repos, etc. para enviar / receber suas atualizações .

Se o Admin executar "ssh User1 @ localhost", ele passará a autenticação de senha, mas será imediatamente expulso com esse tipo de mensagem:

Last login: Sat Apr  1 21:57:31 2017 from ::1
Connection to localhost closed.

Observe que o último login confirma que o login foi bem-sucedido, mas sempre há um pontapé inicial imediato. Não há problema em executar o mesmo comando com User2, confirmando que o sshd está funcionando bem.

Executando "login User1" a partir do terminal cygwin através dos resultados da conta do Administrador, será solicitada a senha do Usuário1 e, após entrar com sucesso, será expulso novamente com esta mensagem:

Password:
Switching to user User1 failed!

O User2 não tem absolutamente nenhum problema em fazer nada disso. E lembre-se, o User1 costumava ser capaz de fazer tudo isso no mês passado e nos últimos anos.

Eu reinstalei o sshd (até o atualizei através do arquivo de configuração do Cygwin) e executei novamente o ssh-host-config, mas nada parece ajudar. (E ssh funciona para Admin e User2.) Aqui está o que eu já verifiquei.

• O usuário1 não está em nenhuma lista negra em / etc. Confirmei verificando arquivos reportados via

 find /etc -type f -exec grep -il User1 {} \;

• Eu recriou os arquivos passwd e group muitas vezes.

mkpasswd -l > /etc/passwd
mkgroup -l > /etc/group

• O shell do User1 é / bin / bash (e não / bin / false ou qualquer variação)

User1:*:197609:197121:U-Jack-VAIO\User1,S-1-5-21-2974605114-333831212-2175464639-1001:/home/User1:/bin/bash
User2:*:197610:197121:U-Jack-VAIO\User2,S-1-5-21-2974605114-333831212-2175464639-1002:/home/User2:/bin/bash

• O usuário1 pode entrar no Windows sem problemas. (Não desativado nem senha expirada em compmgmt.msc > Usuários.)

• Eu deletei o / etc / passwd e o / etc / group, pois eles são não é mais necessário no Cygwin atual .

• Confirmei em "Usuários e grupos locais" que a descrição do User1 está em branco (o que é aceitável e o local alternativo para o Cygwin procurar por campos / etc / passwd quando o / etc / passwd não existir) .

• O atalho 'Cygwin Terminal.lnk' é EXATAMENTE o mesmo atalho que o Usuário2 usa sem problemas. Vive em / cygdrive / c / Users / Public / Desktop. (Ele não tem a caixa de seleção "Executar como administrador" marcada. No entanto, o Usuário1 é solicitado a fornecer a senha do administrador.)

• Não há nada em .bashrc ou .bash_profile no User1 para fazer com que saia. (Veja o próximo item).

• As permissões / home / User1 do User1 são idênticas às do User2. De fato, eu até tentei mover / home / User1 para outro nome, criando um novo / home / User1 com NADA nele (mesmo resultado) e então copiando / etc / skel e alterando as permissões para chown -R User1 : Nenhum (mesmo resultado).

drwxr-xr-x+ 1 Admin   None 0 Apr  1 22:07 Admin
drwxr-xr-x+ 1 User1    None 0 Apr  1 21:52 User1
drwxr-xr-x+ 1 User1    None 0 Apr  1 21:56 User1.001
drwxr-xr-x+ 1 User1    None 0 Apr  1 18:05 User1.old
drwxr-xr-x+ 1 User2    None 0 Oct 21 09:36 User2

drwxr-xr-x+ 1 User1  None    0 Apr  1 21:52 .
drwxrwxrwt+ 1 Admin None    0 Apr  2 06:48 ..
-rw-r--r--  1 User1  None 1494 Jan 16 15:07 .bash_profile
-rw-r--r--  1 User1  None 6054 Jan 16 15:07 .bashrc
-rw-r--r--  1 User1  None 1919 Jan 16 15:07 .inputrc
-rw-r--r--  1 User1  None 1236 Jan 16 15:07 .profile

• Eu posso criar um novo User3 não administrador em compmgmt.msc > Usuários e grupos, defina uma senha e, em seguida, com êxito ssh para ele apenas como User2. O Cygwin auto-cria a home do User3 a partir de / etc / skel. Se eu remover o diretório / User / home1 do User1, ele não será recriado automaticamente após o login via SSH e, é claro, será expulso do shell do Admin.

Aqui está o que é o ssh -vvv User1 @ localhost vs User2. Estou incluindo apenas a parte depois que ambos autenticam com sucesso, para que você possa ver a diferença.

Utilizador1:

debug1: Next authentication method: password
User1@localhost's password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 52
debug1: Authentication succeeded (password).
Authenticated to localhost ([::1]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug3: receive packet: type 91
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IPV6_TCLASS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Sun Apr  2 06:43:18 2017 from ::1
debug3: receive packet: type 96
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
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug3: receive packet: type 98
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
debug3: receive packet: type 97
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
debug3: send packet: type 97
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 cc -1)

debug3: send packet: type 1
Connection to localhost closed.
Transferred: sent 2248, received 2868 bytes, in 0.1 seconds
Bytes per second: sent 15979.1, received 20386.1
debug1: Exit status 255

Admin@Jack-VAIO ~
$

Utilizador2:

debug1: Next authentication method: password
User2@localhost's password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 52
debug1: Authentication succeeded (password).
Authenticated to localhost ([::1]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug3: receive packet: type 91
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IPV6_TCLASS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Sat Apr  1 20:56:04 2017 from ::1

User2@Jack-VAIO ~
$

• UPDATE: Nas últimas reinstalações do SSHD com log ativado, estou vendo esta mensagem específica quando tento ssh como User1:

setreuid 197609: Operation not permitted
setresuid 197609: Operation not permitted

Então você tem isso. Estou completamente perplexo. Uma coisa a notar, excluindo User1 do Windows e recriando não é uma opção como eu tenho muitos anos de configurações já configuradas e não estou recriando que, especialmente quando tudo funciona tão normal para o usuário1 e usuário2. O usuário1 não pode mais acessar sua própria conta do Cygwin.

Alguma idéia do que mais deve checar, porque eu sou novo deles.

P.S. Obrigado por ler isso agora.

    

Answer 1

Depois de mais pesquisas ( aqui e aqui ) Estou inclinado a pensar que o problema não é com Cygwin mas sim com o Windows 10. Uma lâmpada acendeu na minha cabeça quando eu estava na conta do Windows User2 ontem e notei que eu poderia iniciar o Gerenciador de Tarefas sem um prompt do UAC - algo que eu sabia User1 sempre foi solicitado para postar Atualização do Windows 10 do Windows 8 (apesar da atualização ter ocorrido há quase um ano, durante a atualização gratuita para a promoção do Win 10). Eu percebi que era uma coisa do Windows 10 e nunca pensei duas vezes. Quando percebi que estava acontecendo de imediato para o User2 e pesquisei o Google para o User1, descobri que poderia usar a mesma solução alternativa para o problema Cygwin do User1. Ele ainda não responde como a conta do User1 ficou confusa, nem como corrigi-la corretamente, mas estou satisfeito com essa solução alternativa, já que agora posso fazer minhas alterações no git para o User1. / p>

TL; DR

WORK-AROUND:

• Abra a linha de comando (CMD.EXE) e configure essa variável para parar de obter o prompt pop-up do UAC:

set __compat_layer=runasinvoker

• No mesmo terminal em que a variável de ambiente foi configurada, inicie o Cygwin:

c:\cygwin64\bin\mintty.exe

• Para tornar isso permanente para esse usuário (e fazer o ícone da área de trabalho funcionar novamente)

setx __compat_layer "runasinvoker"

• Para torná-lo permanente para todos os usuários em toda a máquina, abra a linha de comando do administrador e, em seguida:

setx /m __compat_layer "runasinvoker"

• E, finalmente, para acessar o git sem consertar o Cygwin, instale o "Git Bash".

Ressalva: Com a conta User1 ainda tecnicamente quebrada, ainda não consigo usar o ssh para fazer o login, mas posso pelo menos chegar ao Terminal Cygwin local como User1. Além disso, essa solução não corrige a capacidade de modificar as variáveis do User Environment Windows User via sysdm.cpl GUI (ainda obtém o prompt do UAC e depois mostra apenas o ENV vars do Admin em vez do User1), mas isso é algo para o fórum do Stack Exchange relacionado ao Windows agora que eu sei que este é um problema de conta do Windows e não do Cygwin. E o SETX permite alterar o usuário e a máquina ENV vars da linha de comando.