Chave Ssh aceita pelo host mas desconexão do cliente

9

Helo

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

Quando não quero me conectar ao 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).

Eu posso me conectar ao meu host com putty no Windows usando a mesma chave privada e posso conectar com 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: posso me conectar com uma senha

    
por Preovaleo 10.11.2015 / 16:22

8 respostas

3

Em primeiro lugar, há numerosas documentações detalhadas, muito bem escritas, sobre como configurar ou configurar a autenticação baseada em chaves públicas, que estão disponíveis on-line. Por favor, dê uma olhada em um deles e veja se você seguiu tudo corretamente. Aqui é um deles. Então eu não vou repetir isso de novo.

O conceito básico é (copiado de aqui ):

Key-based authentication uses two keys, one "public" key that anyone is allowed to see, and another "private" key that only the owner is allowed to see. To securely communicate using key-based authentication, one needs to create a key pair, securely store the private key on the computer one wants to log in from, and store the public key on the computer one wants to log in to.

Agora, no registro de depuração que você postou:

  • Parece que há dois usuários diferentes envolvidos. /home/theo/.ssh/authorized_keys e /home/tbouge/.ssh/id_rsa . Você está tentando fazer o login como um usuário para o diretório pessoal de outro usuário?
  • O erro Postponed publickey for theo.. significa autenticação indesejada método foram tentados antes do método de chave pública. O SSH tentará cada método de autenticação ativado na configuração, um após o outro. No seu caso, você tem GSSAPIAuthentication yes ativado o que não está usando. Você pode desativá-lo com segurança fazendo GSSAPIAuthentication no .
  • debug2: we did not send a packet, disable method é muito provavelmente que 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 os seus estão configurados corretamente. Veja isto: link
  • Quanto ao terceiro erro: Permission denied (public key). , há algumas coisas a verificar.

    • Nome de usuário incorreto
    • Par de chaves incorreto
    • Host alvo incorreto

A parte seguinte é 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 percorrer o processo de autenticação passo a passo, conforme descrito aqui em digitalocean :

  1. O cliente começa enviando um ID para o par de chaves que gostaria de autenticar com o servidor.
  2. A verificação do servidor é o arquivo authorized_keys da conta na qual o cliente está tentando efetuar login para o ID da chave.
  3. Se uma chave pública com ID correspondente for encontrada no arquivo, o servidor gerará um número aleatório e usará 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, ele poderá descriptografar a mensagem usando essa chave, revelando o número original.
  6. O cliente combina o número descriptografado com a chave de 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 uma resposta à mensagem numérica criptografada.
  8. O servidor usa a mesma chave de sessão compartilhada e o número original enviado para o cliente para calcular o valor MD5 sozinho. Ele compara seu próprio cálculo com o que o cliente enviou de volta. Se esses dois valores corresponderem, isso prova que o cliente possuía a chave privada e o cliente está autenticado.

No seu caso, como você pode ver, o computador remoto aceitou somente o seu public key , criptografou o pacote com essa chave e o enviou de volta para o computador cliente. Agora o computador cliente precisa provar que tem o private key correto. Com apenas o direito private_key, ele 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 é finalizado sem sucesso.

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

    
por 23.11.2015 / 09:56
2

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

Pasta

.ssh - > 700

chave pública - > 644

chave privada - > 600

Além disso, verifique usuário & grupo

    
por 10.11.2015 / 16:47
2

o seu problema parece ser bastante comum e claro também.

 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ê tiver selinux runnin no modo forçado pls? se não me diga em que modo o selinux está sendo executado.

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

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

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

    
por 20.11.2015 / 15:12
1

Você diz que tem a mesma chave em uma máquina com Windows; Você tem certeza de que o arquivo de chave privada que você tem em sua máquina Linux está correto? Talvez a chave privada esteja em um formato de putty que o ssh não entende facilmente. Em qualquer caso, se eu colocar um arquivo de chave privada incorreto ou inválido, recebo exatamente o mesmo erro que você tem.

Para corrigir o problema, seria mais apropriado gerar uma nova chave na máquina Linux em vez de reutilizar uma chave de outra máquina. Você pode simplesmente adicionar a nova chave pública ao arquivo authorized_keys no host, e então você pode usar tanto a chave do Windows do Windows quanto a nova chave do Linux do Fedora.

    
por 10.11.2015 / 19:24
1

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

Acabei de resolver o problema adicionando o seguinte ao arquivo local ~/.ssh/config (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 600 para o arquivo de configuração ser lido.

    
por 16.11.2015 / 20:29
1

Não sei se alguém ainda está tendo esse problema, mas finalmente resolvi isso para a minha máquina (um laptop) que estava passando por esse problema. Eu acredito Eu sei o que eventualmente resolveu, e eu vou deixar a informação aqui na esperança de que isso ajude alguém que ainda possa estar encontrando isso - e também para que alguém possa checar meu solução e confirmar que é realmente o que resolveu o problema.

A questão, como se constatou, não era (para mim) com o SSH, mas com a forma como o PAM estava configurando minhas chaves. A configuração em /etc/pam.d estava desatualizada (apesar de estar funcionando corretamente através do Fedora 22), e como resultado as coisas corretas não estavam sendo feitas no login [anymore] para pegar minhas chaves de $HOME/.ssh/ . Executando este comando:

# sudo authconfig --updateall

reconstruiu a configuração de /etc/pam.d corretamente. Na próxima reinicialização, depois que eu entrei na primeira vez que tentei enviar o ssh para o meu servidor, uma caixa de diálogo me pediu para inserir minha senha para a minha chave ssh ( $HOME/.ssh/id_rsa ). Eu fiz isso, marquei a caixa "Desbloquear automaticamente no login" e voila! Minha capacidade de sair do laptop foi restaurada.

Antecedentes

A pista que me levou a resolver isso ocorreu quando importei uma chave RSA de uma fonte externa. (Uma chave USB que carrego consigo, com a minha chave de "acesso remoto" para minha rede doméstica. Eu desliguei PasswordAuth no meu servidor externo anos atrás depois de uma invasão.) Depois de ssh-add -ing THAT Chave RSA, diferente da que está em $HOME/.ssh/id_rsa , foi aceita pelo servidor remoto sem problemas.

Então acabei fazendo o que deveria ter sido um ssh-add redundante, para pegar $HOME/.ssh/id_rsa . Percebi que depois de fazer isso, ssh-add -l continha 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 de chave, apenas o nome da chave privada que corresponde à sua assinatura pública. Como se a chave privada não fosse realmente desbloqueada pelo gerenciador de chaves.

Eu acredito que é exatamente isso que estava acontecendo, e o PAM estava passando "chaves ruins" para o agente SSH que não tinha sido desbloqueado com a frase secreta. Então, quando o ssh tentou autenticar com a chave, na verdade ele não tinha a metade privada (desbloqueada) do par de chaves e, portanto, a autenticação falhou.

Esse último bit é conjectura, mas independentemente se alguém está tendo problemas com chaves ssh não sendo aceitas por hosts remotos (onde costumavam estar) após a atualização para F23, vale a pena tentar reconstruir o diretório /etc/pam.d/ usando authconfig como uma solução.

    
por 20.02.2016 / 19:40
0

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

    
por 18.11.2015 / 07:59
0

No seu ssh_config , tente remover o comentário e / ou adicionar / remover / anexar as linhas Cipher , Ciphers ou MACs .

Parece-me que sshd está procurando por uma determinada cifra de algum tipo que não esteja sendo incluída na solicitação, que pode ser adicionada configurando-a em ssh_config .

... e suponho que você não tenha, por acaso, PubkeyAuthentication definido como no no servidor remoto, porque isso definitivamente causaria falha.

    
por 21.11.2015 / 10:33