OpenSSH no Windows - permitindo a autenticação baseada em chave

Question

Estou tentando configurar a autenticação baseada em chave em um servidor OpenSSH em execução no Windows. Infelizmente, o servidor não parece estar aceitando a chave que estou fornecendo, mas não consigo ver nenhuma mensagem de erro específica ou motivo para o erro. Aqui estão os passos que tentei até agora:

Configuração geral

1. Configure uma conta de domínio específica para acessar o servidor. Nesse caso, configuramos uma conta de serviço que pode acessar o servidor e geramos arquivos group e passwd usando mkgroup e mkpasswd.
2. Confirme que a autenticação baseada em senha funciona corretamente.
3. Modificado o arquivo passwd para alterar o diretório inicial dos usuários para uma pasta especificada na unidade D: usando "/ cygdrive / d / share"

Configuração da chave

1. Modificado ssh_config para incluir as duas linhas seguintes:

   RSAAutenticação sim

   PubkeyAuthentication yes

2. Executou o ssh-keygen para gerar uma chave pública e privada para o usuário.
3. Copiou o conteúdo da chave pública para D: \ Share \ .ssh \ authorized_keys

4. Executei o seguinte para testar a conexão com o servidor SSH:

   ssh -v -l CRMETLSFTP -i id_crmftp SERVERNAME

Tanto quanto eu posso dizer, estes devem ser os passos necessários. Quando eu me conecto com PuTTy remotamente (depois de converter a chave privada), recebo "Servidor recusou nossa chave". Testando uma conexão localmente com -v, recebo a seguinte saída:

C:\Program Files (x86)\OpenSSH>ssh -v -l CRMETLSFTP -i id_crmftp DEVCRMETL01
OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to DEVCRMETL01 [172.17.8.151] port 22.
debug1: Connection established.
debug1: identity file id_crmftp type 1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.8.1p1
debug1: match: OpenSSH_3.8.1p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
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
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'devcrmetl01' is known and matches the RSA host key.
debug1: Found key in /home/rbrunner/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey,password,keyboard-interacti
ve
debug1: Next authentication method: publickey
debug1: Offering public key: id_crmftp
debug1: Authentications that can continue: publickey,password,keyboard-interacti
ve
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interacti
ve
debug1: Next authentication method: password
CRMETLSFTP@devcrmetl01's password:

Tanto quanto eu posso ver, está tentando enviar a chave corretamente. Presumo que as chaves autorizadas não estejam a funcionar corretamente, mas não sei por onde começar a procurar.

    

Answer 1

É um pouco tarde para uma resposta, talvez, mas apenas no caso de alguém se deparar com essa pergunta, eu tentaria o seguinte.

• Copie authorized_keys para authorized_keys2.
• Execute ssh-user-config para garantir que as permissões e essas informações estejam corretas.
• Inicie o sshd com os parâmetros -d , -dd e -ddd para não bifurcar e imprimir informações de depuração em primeiro plano durante o teste. Isso geralmente é mais útil do que aumentar as informações de depuração ( -vvv ) no cliente.