Chave ssh aceita pelo host, mas o cliente é desconectado

Olá,

Eu tenho um problema com o SSH após a instalação do fedora 23.

Quando não quero conectar ao meu host remoto com chave privada, meu host encontra a chave:

debug1: matching key found: file /home/theo/.ssh/authorized_keys, line 1 RSA {REDACTED}
debug1: restore_uid: 0/0
Postponed publickey for theo from {REDACTED} port 60351 ssh2 [preauth]
Connection closed by {REDACTED} [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed

Mas como você vê meu cliente desconectar por si mesmo

debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tbouge/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

Posso conectar-me ao meu host com massa no Windows usando a mesma chave privada e posso conectar-me ao meu telefone usando uma chave privada diferente.

Você tem alguma ideia ?

/ etc / ssh / ssh_conf

Host *
        GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
        ForwardX11Trusted yes
# Send locale-related environment variables
        SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
        SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
        SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
        SendEnv XMODIFIERS

Obrigado

Editar: eu posso conectar com uma senha

Antes de tudo, existem inúmeras documentações detalhadas, muito bem escritas, sobre como instalar ou configurar a autenticação baseada em chave pública . Dê uma olhada em um deles e veja se você seguiu tudo corretamente. Aqui está um. Então, eu não vou repetir isso de novo.

O conceito muito básico é (copiado daqui ):

A autenticação baseada em chave usa duas chaves, uma chave "pública" que qualquer pessoa pode ver e outra chave "privada" que somente o proprietário pode ver. Para se comunicar com segurança usando a autenticação baseada em chave, é necessário criar um par de chaves, armazenar com segurança a chave privada no computador em que deseja efetuar login e armazenar a chave pública no computador em que deseja efetuar login.

Agora, no log de depuração que você publicou:

• Parece que há dois usuários diferentes envolvidos. /home/theo/.ssh/authorized_keyse /home/tbouge/.ssh/id_rsa. Você está tentando fazer login como um usuário no diretório inicial de outro usuário?
• O erro Postponed publickey for theo..significa que o método de autenticação indesejado foi tentado antes do método da chave de publicação. O SSH tentará todos os métodos de autenticação ativados na configuração, um após o outro. No seu caso, você GSSAPIAuthentication yesativou o que não está usando. Você pode desativá-lo com segurança fazendo isso GSSAPIAuthentication no.
• debug2: we did not send a packet, disable methodprovavelmente não pode processar o arquivo de chave privada (permissão de arquivo ou problema de nome). O SSH é muito sensível às permissões de diretório e arquivo em computadores locais e remotos. ( chown user_name:user_group -R /home/user, chmod 700 /home/.ssh, chmod 600 /home/.ssh/authorized_keys). Portanto, verifique se o seu está definido corretamente. Veja isto: /unix/131886/ssh-public-key-wont-send-to-server

• Quanto ao terceiro erro:, Permission denied (public key).há algumas coisas para verificar.

  • Nome de usuário errado
  • Par de chaves incorreto

  • Host de destino errado

    • Aqui estão mais detalhes: /programming/18551556/permission-denied-publickey-when-ssh-access-to-amazon-ec2-instance .

A parte a seguir é um pouco confusa:

debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method

Para entender melhor, vamos seguir o processo de autenticação passo a passo, conforme descrito aqui no digitalocean :

1. O cliente começa enviando um ID para o par de chaves com o qual gostaria de se autenticar no servidor.
2. A verificação do servidor é o arquivo allowed_keys da conta na qual o cliente está tentando fazer login para obter o ID da chave.
3. Se uma chave pública com o ID correspondente for encontrada no arquivo, o servidor gera um número aleatório e usa a chave pública para criptografar o número.
4. O servidor envia ao cliente esta mensagem criptografada.
5. Se o cliente realmente tiver a chave privada associada, poderá descriptografar a mensagem usando essa chave, revelando o número original.
6. O cliente combina o número descriptografado com a chave da sessão compartilhada que está sendo usada para criptografar a comunicação e calcula o hash MD5 desse valor.
7. O cliente envia esse hash MD5 de volta ao servidor como resposta à mensagem do número criptografado.
8. O servidor usa a mesma chave de sessão compartilhada e o número original que enviou ao cliente para calcular o valor MD5 por conta própria. Ele compara seu próprio cálculo ao que o cliente enviou de volta. Se esses dois valores corresponderem, isso prova que o cliente possuía a chave privada e o cliente é autenticado.

No seu caso, como você pode ver, o computador remoto apenas aceitou o seu public key, criptografou o pacote com essa chave e o enviou de volta ao computador cliente. Agora, o computador cliente precisa provar que tem o direito private key. Com apenas a chave privada certa, ela pode descriptografar a mensagem recebida e enviar uma resposta de volta. Nesse caso, o cliente não está conseguindo fazer isso e o processo de autenticação é encerrado sem êxito.

Espero que isso ajude você a entender os problemas e resolvê-los.

Os privilégios em seus arquivos ssh estão corretos?

Pasta .ssh -> 700

chave pública -> 644

chave privada -> 600

Verifique também usuário e grupo

Você diz que tem a mesma chave em uma máquina Windows; tem certeza de que o arquivo de chave privada que você possui na sua máquina Linux está correto? Talvez a chave privada esteja em um formato de massa que o ssh não entenda facilmente. De qualquer forma, se eu colocar um arquivo de chave privada incorreto ou inválido, receberei exatamente o mesmo erro que você possui.

Para corrigir o problema, seria mais apropriado gerar uma nova chave na máquina Linux em vez de reutilizá-la de outra máquina. Você pode simplesmente adicionar a nova chave pública ao arquivo allowed_keys no host e, em seguida, pode usar a chave do Windows no Windows e a nova chave do Linux no Fedora.

seu problema parece ser bastante comum e claro, eu já disse.

 Permission denied (publickey).

isso significa alguma coisa para você? para mim, isso significa muito para mim.

você pode verificar no lado do servidor se você tem o selinux executando no modo imposto pls? caso contrário, diga-me para qual modo o selinux está sendo executado.

Além disso, se você puder fazer mais uma tentativa e capturar os logs de auditoria dessa tentativa e postar aqui, definitivamente nos informará o porquê:

  tail -f /var/log/audit/audit.log  (and try to attempt)

É um problema de permissão que é claro, mas não a permissão de arquivo :-)

Parece que o problema (no meu caso ...) foi causado pelo tipo de chave.

Acabei de resolvê-lo adicionando o seguinte ao ~/.ssh/configarquivo local (a máquina cliente do Fedora 23):

PubkeyAcceptedKeyTypes=+ssh-dss

Embora eu tenha adicionado essa linha ao servidor e ao arquivo de configuração do cliente, apenas o lado do cliente fez a diferença. Observe que as permissões precisam ser 600para que o arquivo de configuração seja lido.

Não sei se mais alguém ainda está tendo esse problema, mas finalmente o resolvi para minha única máquina (um laptop) que estava com o problema. Eu acredito que eu sei o que finalmente classificados para fora, e eu vou deixar a informação aqui na esperança de que ele vai ajudar qualquer outra pessoa que ainda pode estar encontrando isso - e também para que alguém possa espero que verificar a minha solução e confirmar que é realmente o que resolveu o problema.

O problema, como se vê, não era (para mim) com o SSH, mas com o modo como o PAM estava configurando minhas chaves. A configuração /etc/pam.destava desatualizada (embora estivesse funcionando corretamente através do Fedora 22) e, como resultado, as coisas corretas não estavam sendo feitas no login [mais] para pegar minhas chaves $HOME/.ssh/. Executando este comando:

# sudo authconfig --updateall

reconstruiu a configuração /etc/pam.d corretamente. Na próxima reinicialização, após o login, na primeira vez em que tentei ssh no servidor, uma caixa de diálogo solicitou que eu digite minha senha para minha chave ssh ( $HOME/.ssh/id_rsa). Fiz isso, marquei a caixa "Desbloquear automaticamente no login" e pronto! Minha capacidade de sair do laptop foi restaurada.

fundo

A pista que me levou a resolver isso veio quando eu importei uma chave RSA de uma fonte externa. (A chave USB I transportar, com a minha chave "acesso remoto" para minha rede doméstica. Desliguei PasswordAuth aos meus anos de servidores voltados para o exterior atrás, depois de uma intrusão.) Depois ssh-adding QUE chave RSA, ao contrário do sentado em $HOME/.ssh/id_rsa, foi aceito pelo servidor remoto sem problemas.

Então acabei fazendo o que deveria ter sido redundante ssh-add, para pegar $HOME/.ssh/id_rsa. Percebi que, depois de fazer isso, ssh-add -lcontinha duas entradas para a mesma chave:

% ssh-add -l
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX id_rsa (RSA)
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX me@host (RSA)
2048 SHA256:YYYYYYYYYYYYYYYYYYYYYY imported@usbkey (RSA)

Observe como uma das duas entradas não mostra o identificador da chave, apenas o nome do arquivo da chave privada que corresponde à sua assinatura pública. Como se a chave privada não tivesse sido realmente desbloqueada pelo gerente do chaveiro.

Acredito que isso é exatamente o que estava acontecendo, e o PAM estava passando "chaves ruins" para o agente SSH que não havia sido desbloqueado com a senha. Portanto, quando o ssh tentou se autenticar com a chave, ele realmente não tinha a metade privada (desbloqueada) do par de chaves e, portanto, a autenticação falhou.

Esse último bit é conjectura, mas, independentemente de alguém ter problemas com as chaves ssh não serem aceitas pelos hosts remotos (onde costumavam estar) após a atualização para o F23, vale a pena tentar reconstruir o /etc/pam.d/diretório usando authconfiguma solução.

Verifique as permissões do diretório inicial do usuário. É importante. Deve ser 755. 700 ou 770 não funcionarão.

Na sua ssh_config, tente descomentando e / ou adicionar / remover / acrescentar quer ao Cipher, Ciphersou MACslinha (s).

Parece-me que sshdestá procurando uma cifra específica de algum tipo que não está sendo incluída na solicitação, que pode ser adicionada configurando-a na sua ssh_config.

... e suponho que você não tenha PubkeyAuthenticationdefinido por acaso nono servidor remoto, porque isso definitivamente causaria a falha.