it-swarm-pt.tech

Tentando fazer a autenticação ssh com arquivos de chave: servidor recusou nossa chave

Eu estou tentando configurar a autenticação ssh com arquivos de chave em vez de nome de usuário/senha. O cliente é uma caixa do Windows que executa o PuTTY e o servidor é um servidor Ubuntu 12.04 LTS.

Eu baixei puttygen.exe e tinha que gerar um par de chaves. Em /etc/ssh/sshd_config eu tenho esta linha:

AuthorizedKeysFile %h/.ssh/authorized_keys

e no arquivo de chave pública do meu cliente diz isto:

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "[email protected]"
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAr3Qo6T5XU06ZigGOd3eKvfBhFLhg5kWv8lz6
qJ2G9XCbexlPQGanPhh+vcPkhor6+7OmB+WSdHeNO652kTofnauTKcTCbHjsT7cJ
GNrO8WVURRh4fabknUHPmauerWQZ6TgRPGaz0aucU+2C+DUo2SKVFDir1vb+4u83
[email protected]
---- END SSH2 PUBLIC KEY ----

Copiei a parte de "ssh-rsa AAA" para "[email protected]" e coloquei no arquivo ~/.ssh/authorized_keys no meu servidor (na minha própria homefolder). No PuTTY, em Conexão> SSH> Auth, entrei o caminho para a chave privada que gerou no meu cliente e salvei as configurações da sessão.

Eu reiniciei o servidor ssh com

Sudo service ssh restart

Agora, se eu carregar o perfil no PuTTY (eu verifiquei a chave privada ainda está em Conexão> SSH> Auth e que o caminho está correto) e execute o perfil, diz

Server refused our key

Eu tentei colocar a chave pública em um arquivo sob o diretório ./ssh/authorized_keys/ mas isso não ajudou, então usei ./ssh/authorized_keys como arquivo, colando a chave nele. Também tentei gerar um par de chaves privada/pública no servidor, colocando a chave pública em ./ssh/authorized_files e carregando a privada em PuTTY no meu cliente. A reinicialização do servidor também não ajudou.

Descobri que o erro pode ser resolvido colocando a chave em um local fora da pasta inicial do usuário, mas isso só será útil se a pasta principal estiver criptografada, o que não é.

Também tentei gerar uma chave de 4096 bits, pensando que talvez 1024 fosse muito curto.

Como posso fazer isso funcionar? Obrigado!

EDITAR:

Ok, /var/log/auth.log disse:

sshd: Authentication refused: bad ownership or modes for directory /home/vorkbaard/.ssh

O Google me diz que ~/.ssh/ deveria ser 700 e ~/.ssh/authorized_keys deveria ser 600, então eu fiz isso. Agora /var/log/auth.log diz:

sshd: error: key_read: uudecode AAAAB3N [etc etc etc until about 3/4 of my public key]
51
Forkbeard

Ok, é fixo no entanto não vejo como isso é diferente do que eu já tentei.

O que eu fiz:

  • gerar um par de chaves com o puttygen.exe (tamanho: 1024 bits)
  • carregar a chave privada no perfil do PuTTY
  • insira a chave pública em ~/.ssh/authorized_keysem uma linha (precisa começar com ssh-rsa)
  • chmod 700 ~/.ssh
  • chmod 600 ~/.ssh/authorized_keys
  • chown $USER:$USER ~/.ssh -R
  • altere /etc/ssh/sshd_config para que contenha AuthorizedKeysFile %h/.ssh/authorized_keys
  • Sudo service ssh restart

Para solucionar problemas, faça # tail -f /var/log/auth.log.

Obrigado pela ajuda!

89
Forkbeard

Acabei de encontrar esse problema. Apesar de ter o config configurado corretamente como já foi mencionado neste thread (permissões em authorized_keys etc.), acontece que eu tinha a chave pública no formato errado. Foi na forma de:

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "imported-openssh-key"
AAAAB3NzaC1yc2EAAAADAQABAAABAQDUoj0N3vuLpeviGvZTasGQ...
... lPmTrOfVTxI9wjax2JvKcyE0fiNMzXO7qiHJsQM9G9ZB4Lkf71kT
---- END SSH2 PUBLIC KEY ----

O que não estava funcionando. Mas conseguiu que funcionasse na forma:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDU.....j0N3vuLpeviGvZTasGQa1rcJiPXQMW7v3uurb+n94B9MQaaWR0odsg5DJQL92TNenOda5BO1nd08y6+sdLQmHXExTz6X8FzgoVsAkEl3RscxcxHUksiKA9JfTo38vQvG/bPxIHMCuSumCQVA1laf3rO/uOrkcB7iMWhaoi1/z6AbFtPzeh7xjGfInMWwtBI0CsHSRF73VWIxT26w0P+KjafCjSn/7vDO1bT8QHujSQelU/GqaVEvbbvPl1a7POVjKgHLNekolwRKfNeVEewcnmZaoqfHgOKlPmTrOfVTxI9wjax2JvKcyE0fiNMzXO7qiHJsQM9G9ZB4Lkf71kT [email protected]
22
kuraara

o problema é que o windows usa uma nova linha diferente do que o linux, então ao copiar a chave do windows para o linux, existe um \ n no final da linha que você não pode ver no linux no editor.

Se você seguir o /var/log/auth.log e tentar entrar, o erro é como:

sshd: erro: key_read: uudecode AAAAB3N [....] ==\n

Se você mudar sua chave no windows para que fique em uma única linha sem uma nova linha no final e copie-a para o linux, ela deve funcionar (fez o truque para mim).

9
Mischa

Eu tive que mudar as permissões para o diretório home

chmod 700 ~
8
Michal Zmuda

Eu tive que mudar as permissões do diretório ~/.ssh de 770 para 700 e as permissões de arquivo ~/.ssh/authorized_keys de 660 para 600.

Por algum motivo, a remoção de permissões de grupo corrigiu esse problema para mim.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
6
dopple

O arquivo ~/.ssh/authorized_keys requer que as chaves estejam todas em uma linha. Se você adicionou em várias linhas como na pasta acima, tente unir as linhas.

5
Paul

para mim, o problema foi que eu criei ~/.ssh/authorized_keys usando root para que fosse root. Eu tive que chown sshuser:sshuser ~/.ssh/authorized_keys então começou a funcionar

1
PeanutPower

Eu também enfrentei esse erro e resolvi isso alterando as permissões do arquivo authorized_keys para 600.

chmod 600 ~/.ssh/authorized_keys
1
Kaleem

Às vezes pode ser um problema associado a ter a chave pública em uma linha, essa abordagem parece resolvê-lo

echo 'the content of the public key' > /root/.ssh/authorized_keys
1
dav

Além de todas as respostas acima, certifique-se de copiar e colar a chave de puttygen corretamente!

Se você clicar duas vezes na maior parte da string da chave para selecioná-la, talvez não receba a string inteira, porque a caixa de texto divide linhas em alguns caracteres, como +, de modo que você não selecione o texto após + caractere (que você não pode ver porque a caixa de texto é muito pequena). Certifique-se de selecionar a string inteira manualmente, do ssh-rsa até o final da caixa de texto.

1
Mark Lakata

Veja o que funcionou para mim:

Em puttygen, depois de gerar as chaves, certifique-se de copiar e colar as informações do campo superior para entrar no arquivo authorized_keys. Se você salvar sua chave pública em sua máquina cliente e, em seguida, abri-la, o texto será diferente do texto na parte superior da tela puttygen. Novamente, certifique-se de copiar e colar o texto do TOP da tela puttygen (depois de criar as chaves) no arquivo authorized_keys, que deve estar localizado em ~/.ssh.

1
zach

para depurar o ssh aberto, pode-se usar:

Sudo `which sshd` -p 2020 -Dd

ele executa o sshd em outra porta 2020. Ele executa o sshd como um programa atual, de modo que a saída vai para a tela. se fechado está fechado.

tente se conectar.

explicação:

  • `qual sshd` - localiza o endereço sshd, tente executar qual sshd vê o que ele imprime. Ao usar aspas, ele executa e retorna o resultado no lugar.
  • -p 2020 - especifica porta
  • -D - logar ao arquivo
  • -d - log na tela

https://www.attachmate.com/documentation/rsit-unix-802/rsit-unix-guide/data/sshd_options_ap.htm

0
Shimon Doodkin

Um erro comum é que as pessoas usam um editor de texto (como o Vim) e colam o texto copiado antes de ativar a "inserção" (pressione + i no Vim antes de colar)

0
hakabe

Eu estava criando os arquivos .ssh e authorized_keys enquanto estava logado como root, o que dava as permissões erradas. Ele também colocou todos os arquivos sob o diretório raiz. Eu acredito que é a raiz de muitos dos problemas com "servidor recusado chave".

Mudar a propriedade desses arquivos para o usuário que você deseja não será uma boa prática, então refiz meus passos e me certifiquei de que estava logado como o usuário com o qual eu queria utilizar o SSH e criei o .ssh e authorized_keys novamente. Erro.

Instruções para conectar o Win7 ao servidor Xubuntu 15.04: Como criar chaves SSH com o PuTTY para conectar-se a um VPS

0
Leo F

De fato, mudei a permissão do authorized_keys para 644, então o problema foi resolvido.

chmod 644 ~/.ssh/authorized_keys
0
Peter Liang