Eu tenho um script PoSh em um servidor Windows (2019) que quero iniciar a partir de um aplicativo web simples (um botão) em um servidor web linux, então habilitei o OpenSSH e o restringi a apenas uma conta genérica e sem privilégios.
No teste manual com autenticação de nome de usuário/senha, a conta é autenticada e o script funciona bem.
Quando estabeleci um par de chaves pública/privada, a conta se conecta, mas o script falha. A falha ocorre quando o script tenta ler os resultados (nulos) de uma consulta ADSI necessária. Eu pensei que uma das razões para usar pares de chaves era evitar a necessidade de senhas codificadas em scripts.
A única coisa que posso imaginar é que a autenticação baseada em chave não está realmente "logando" e que precisa haver algum tipo de tíquete gerado que possa ser passado para o AD quando as credenciais forem necessárias para verificações de acesso de segurança. Eu acho que uma advertência como essa seria explicada em algum lugar em toda a documentação sobre como configurar/usar SSH no Windows.
Se meu palpite for verdade, qual é a melhor maneira de resolver isso? Existe alguma configuração no OpenSSH para que a autenticação baseada em chave gere um ticket sem uma senha? Eu realmente preciso colocar a senha no código?
Obrigado
As credenciais são sempre necessárias para acessar o AD. Em logins normais, ADSI (assim como RSAT, compartilhamento de arquivos SMB, etc) usa automaticamente suas credenciais "padrão" que o Windows armazenou como parte do processo de login - para o Active Directory, ele obtém um tíquete inicial Kerberos do AD DC (como bem como armazenar seu hash de senha NTLM para serviços não integrados ao AD). Você pode correr
klistpara ver o ticket "krbtgt/" que concede acesso a todos os serviços do AD.Geralmente não, a máquina não pode gerar tickets do nada – ela precisa obtê -los no AD DC e, para isso, precisa de suas credenciais em um formato aceitável para o AD. Isso geralmente significa sua senha (ou tecnicamente seu certificado PKI se o AD estiver configurado para isso - mas isso não funcionará através do OpenSSH).
Com a autenticação de chave pública, o OpenSSH no servidor não possui nenhuma credencial que possa ser usada para obter um tíquete Kerberos em seu nome.
Uma exceção a isso é a delegação restrita usando a extensão "S4U2Proxy" do Kerberos, onde o sistema pode usar suas próprias credenciais de 'máquina' para gerar tíquetes representando você. Esta não seria uma configuração OpenSSH no entanto (S4U2Proxy não pode ser usado para criar tickets krbtgt "iniciais" até onde eu sei); uma vez que as permissões para delegação restrita são concedidas à máquina, é provável que o ADSI precise solicitar que o Windows faça isso para a conexão LDAP real.
É provável que seja "já conhecido" do PowerShell Remoting via WinRM, onde é conhecido como o "problema do segundo salto" desde que o recurso existiu.
Das opções oferecidas, o transporte SSH suporta delegação Kerberos irrestrita, mas não CredSSP (embora eu não consiga ver por que o artigo afirma que o último é mais seguro - ambos transferem suas credenciais, portanto, ambos são igualmente arriscados).
Este não é um problema exclusivo do Windows – também é visto em sites Unix, por exemplo, universidades que executam sistemas onde os usuários têm diretórios pessoais baseados em NFS ou AFS acham impossível usar autenticação de chave pública pelo mesmo motivo.
Claro que não - você pode colocá-lo em um arquivo de configuração separado.
(Há pouca diferença entre ter um arquivo com uma chave privada nele, e um arquivo com uma senha nele... protegidos na mesma medida. São os outros recursos dos pares de chaves que os fazem valer a pena usá-los.)
Outra opção seria reescrever seu script para rodar no Linux, acessando o Active Directory através do LDAP (por exemplo, python-ldap ou perl Net::LDAP). Dessa forma, em vez de armazenar uma senha, ele poderia usar um arquivo keytab do Kerberos para autenticação – que ainda precisa da mesma proteção no disco, mas tem a vantagem de usar o Kerberos em geral.