SSH: “Servidor recusou nossa chave” sem motivo

Question

Eu estava tentando configurar um script de backup simples para ser executado automaticamente, que copiava um arquivo de uma máquina Windows para um Linux, por meio de SSH.

Como muitos tutoriais on-line simples sugerem que usei pscp com uma chave privada gerada com puttygen e coloquei a chave pública correspondente (apresentada em forma de copiar / colar pelo próprio putty) no arquivo authorized_keys no Linux . Isso parece bastante simples, considerando que ele trabalhava em duas outras máquinas Windows para uma máquina Linux diferente, com a mesma configuração.

Não há problemas de conectividade AFAICS e o mesmo vale para o ssh, considerando que consigo fazer login como root na máquina Linux. O arquivo de configuração ( sshd_config ) tem o AuthorizedKeysFile definido como ~/.sshd/authorized_keys .

O erro "Servidor recusou nossa chave" continua aparecendo, não importa o que eu faça ... Os logs não mostram nenhum problema de autenticação ...

Estou planejando fazer mais testes e definindo o valor logLevel para VERBOSE ou DEBUG2 ou 3 , mas considerando a urgência do assunto e o fato de que, para realmente testá-lo na máquina Eu tenho que passar por um monte de problemas considerando que a máquina está em um lugar que é muito distante do meu local de trabalho real ...

Perguntas

• Alguém tem alguma ideia?
• Isso já aconteceu com alguém?

Parece que isso pode ser um problema relacionado a versões ssh ou algo do tipo ...

Eu também estava considerando a possibilidade de ter a chave pública inserida no arquivo authorized_keys dentro do diretório .ssh do usuário ( /user/.ssh/ ) além de tê-la na pasta raiz (não faz muito sentido porque do valor de AuthorizedKeysFile em sshd_config ).

Eu fiz alguns teting com o servidor% ssh LogLevel set o VERBOSE mas eu não consegui recuperar as informações (problemas de responsabilidade), então aqui vai um log de saída / depuração de outra fonte que parece ser exibindo o mesmo erro ...

Connection from 192.168.0.101 port 4288
debug1: Client protocol version 2.0; client software version OpenSSH_4.5
debug1: match: OpenSSH_4.5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.5
debug1: permanently_set_uid: 22/22
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user dcowsill service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for "dcowsill"
debug1: userauth-request for user dcowsill service ssh-connection method publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: PAM: setting PAM_RHOST to "192.168.0.101"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: temporarily_use_uid: 1052/105 (e=0/0)
debug1: trying public key file /testuser/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 1052/105 (e=0/0)
debug1: trying public key file /testuser/.ssh/authorized_keys
debug1: restore_uid: 0/0
Failed publickey for dcowsill from 192.168.0.101 port 4288 ssh2
debug1: userauth-request for user dcowsill service ssh-connection method publickey
debug1: attempt 2 failures 2
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 1052/105 (e=0/0)
debug1: trying public key file /testuser/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 1052/105 (e=0/0)
debug1: trying public key file /testuser/.ssh/authorized_keys
debug1: restore_uid: 0/0
Failed publickey for dcowsill from 192.168.0.101 port 4288 ssh2
Connection closed by 192.168.0.101

Parece que o programa está tentando abrir o arquivo authorized_keys com permissões do proprietário, mas não há mais informações sobre o que está gerando o problema. Uma última coisa, eu verifiquei e verifiquei novamente as permissões de arquivo e tolerante e elas estão todas ok.

    

Answer 1

Algumas das possíveis razões que conheço estão relacionadas às permissões de arquivo estes são na maior parte muito largos e Particularmente, posso lembrar duas razões

1. expondo o diretório / home / user para mais do que o proprietário
2. .ssh e / ou permissões do arquivo authorized_keys (configure-as para 700/600, respectivamente, se forem mais do que isso)

a razão exata da chave é recusada iniciando um servidor sshd adicional em outra porta com opções de depuração e não-daemon se você tiver acesso root no servidor, você pode executar:

sudo 'which sshd' -p 2020 -Dd

no servidor

Depois de deixar a execução, execute ssh:

ssh -p 2020 -i /path/to/refusedkey

A saída do servidor informará o motivo da recusa

    

Answer 2

alguma verificação óbvia

O formato

• da authorized_keys ssh-rsa AA...long_line_of_char comment putty gen em algum momento dá outra forma.

• autorização:

  • ~ user / .ssh / authorized_keys é -rw-r - r -
  • ~ user / .ssh / é drwx ------
  • ~ o usuário não é gravável pelo mundo.
A chave

• pode ser implantada como id ~ root ou em ~ usuário, dependendo do usuário ao qual você se conecta.

alguns menos óbvios:

• root não tem permissão para ser ssh'd para. ( PermitRootLogin no ou comentário)

• local padrão para authorized_keys AuthorizedKeysFile %h/.ssh/authorized_keys

  • que é .ssh no diretório inicial do usuário.

• exemplo de local personalizado para authorized_keys AuthorizedKeysFile /foo/bar/authorized_keys.%h

  • que são chaves, estão localizadas em /foo/bar dir.
  • no arquivo authorized_keys.root para raiz
  • no arquivo authorized_keys.user para o usuário, o arquivo é de propriedade do root

Answer 3

No meu caso, resolvi isso:

chmod 700 myuserdir/.ssh
chmod 600 myuserdir/.ssh/authorized_keys

Na caixa do windows, em vez de usar o puttygen para gerar a chave privada rsa, baixei o cygwin do cygwin.org. Oferece alguns pacotes por padrão. Eu modifiquei o pacote Net para instalar o OpenSSH. Isto instalou, entre outras coisas, o programa ssh-keygen. Então eu corri:

• ssh-keygen -t rsa e deixou a senha vazia
• Isso criou a chave privada chamada id_rsa in c:/cygwin/home/myusername/.ssh
• Eu iniciei o puttygen e selecione a opção de menu "Arquivo - > Carregar chave privada" e selecione seu id_rsa (não o público id_rsa.pub ).
• Salve no formato de massa clicando no botão "Salvar chave particular" (chamei de putty.ppk)
• Iniciar massa e selecione Conexão - > SSH - > Auth - > Chave privada para autenticação. Digite o putty.ppk gerado.
• Digite seu nome de usuário em massa: Conexão - > Dados - > Nome de usuário de login automático

Agora posso me conectar sem digitar nem usuário nem senha.

    

Answer 4

Executar:

sudo 'which sshd' -p 2020 -Dd

como root em uma sessão e em outra sessão executada:

ssh -p 2020 -i /path/to/refusedkey refusedkeyusername@hostname

Trabalhei para que eu entendesse o motivo. Minhas permissões de usuário não foram definidas para 700. Eu tenho o / p como abaixo

debug1: trying public key file /home/userid/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: **bad ownership** or modes for directory /home/sapadmin
debug1: restore_uid: 0/0
Failed publickey for userid from 172.31.2.12 port 27382 ssh2: RSA 
Connection closed by 172.31.2.12 [preauth]

    

Answer 5

ok! Uma razão é que o diretório home do usuário do arquivo passwd não é o diretório do qual você deseja copiar os arquivos. Apenas root pode copiar de todos os itens, os outros usuários não!

por exemplo, se você deseja copiar do diretório / backup, certifique-se de que o usuário que você deseja autenticar tenha o diretório home configurado para / backup (pertencente a ele), para que o scp encontre o caminho do corect para authorized_keys "/ backup / .ssh / authorized_key "

segundo: certifique-se de copiar para o arquivo authorized_keys exatamente o texto do Putty Key Generator com "ssh-rsa AA ...." para uma única linha. você pode remover qualquer comentário como "rsa-key-xxx .." do final. arquivo authorized_keys deve possuir usuário / grupo boa sorte!

    

Answer 6

No log do servidor de depuração que você compartilhou, parece que a chave que você especificou no lado do cliente simplesmente não corresponde a nenhuma das disponíveis em /testuser/.ssh/authorized_keys.

se /testuser/.ssh/authorized_keys for o local esperado, você deve verificar se existe uma linha de chave pública que corresponda à sua chave privada usada no lado do cliente - isto é, se você usar say, id_rsa no client check id_rsa.pub próximo a ele corresponde exatamente a uma linha em /testuser/.ssh/authorized_keys.

Se você tiver dúvidas sobre o arquivo authorized_keys do local no servidor, deverá descobrir se você especificou o nome de usuário correto no lado do cliente.