Como usar a autenticação ssh de chave pública


5

Eu tenho 2 servidores ubuntu 12.04 (beta) (nó1 e nó2) e quero estabelecer acesso raiz sem senha entre eles. Outros usuários não devem ter acesso a outras caixas. Observe também que a porta padrão ssh foi alterada para 220.

Aqui está o que eu fiz:

sudo -i
cd /root/.ssh
ssh-keygen -t rsa # with default name and empty password
cat id_rsa.pub > authorized_keys

depois copiou id_rsa & id_rsa.pub para o node2 e adicionou id_rsa.pub para as autorizadas_chave. Ambos os hosts têm o mesmo arquivo /root/.ssh/config:

Host node1
Hostname 1.2.3.4
Port 220
IdentityFile /root/.ssh/id_rsa

Host node2
Hostname 5.6.7.8
Port 220
IdentityFile /root/.ssh/id_rsa

Agora, o problema é que, quando digito ssh node2, solicita a senha. Qual pode ser o problema?

Atualizar:

Informações de depuração no cliente:

debug1: Server host key: RSA ***
debug1: Host '[*.*.*.*]:220' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:6
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/id_rsa ((nil))
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: read PEM private key done: type RSA
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug1: Next authentication method: password

Informações de depuração no servidor:

debug1: userauth-request for user root service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "root"
debug1: PAM: setting PAM_RHOST to "*.*.*.*"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user root service ssh-connection method publickey [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: test whether pkalg/pkblob are acceptable [preauth]
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /root/.ssh/authorized_keys, line 2
Found matching RSA key: ****
debug1: restore_uid: 0/0
debug3: mm_answer_keyallowed: key 0x7f0647b0c1b0 is allowed
debug3: mm_request_send entering: type 22
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth]
Postponed publickey for root from *.*.*.* port 38887 ssh2 [preauth]

Permissões:

drwx------ 2 root root   4096 Mar 26 15:34 .ssh

-rw------- 1 root root  840 Mar 26 14:50 authorized_keys
-rw-r--r-- 1 root root  225 Mar 26 15:34 config
-rw------- 1 root root 1679 Mar 26 14:47 id_rsa
-rw-r--r-- 1 root root 2652 Mar 26 14:39 known_hosts

Algumas linhas dos arquivos de configuração:

PermitRootLogin without-password
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  %h/.ssh/authorized_keys
UsePAM no # also tried yes

Você já passou por todas as outras perguntas sobre isso primeiro? Há muitas sugestões de como solucionar este problema, e geralmente se resume a permissões em .ssh / * e / etc / sshd_config
Paul

@ Paulo Yep Eu li aqueles (não tudo para ser honesto) e não encontrou nada útil
Poma

Isso é depuração do lado do cliente? Você pode ativar a depuração no lado do servidor e ver do que não gosta?
Paul

11
Qual é a permissão para / root em si? Seria uma prática recomendada ter pares de chaves e adicionar a chave pública às teclas_autorizadas do lado remoto, em vez de copiar as chaves privadas.
276 Bruno Bruno

@ Paul acrescentou servidor informações de depuração à minha pergunta
Poma

Respostas:


3

O diretório inicial do root é criptografado (talvez por ecryptfs)?

Eu estava tendo um problema semelhante em que a autenticação de chave pública não funcionava, a menos que o usuário já tivesse uma sessão ativa. Ao ler esta pergunta , percebi que, ao optar por criptografar o diretório inicial do usuário, estava impedindo o sshd de ler ~ / .ssh / allowed_keys, a menos que o usuário já estivesse logado em outra sessão (que então descriptografaria automaticamente o diretório inicial).

Resolvi o problema mudando para diretórios pessoais não criptografados, após o qual a autenticação de chave pública começou a funcionar.


+1: obrigado, estava com um problema .Xauthoritye achei que estava relacionado. Parece que esta é a primeira vez que tento acessar sshmeu outro PC sem estar logado ...
Avio

1

O ssh vem com um comando para copiar a chave pública no servidor remoto ssh-copy-id,. Ele cuida de todas as permissões necessárias e vários outros problemas de "pegadinha".

Exemplo:

ssh-copy-id -i $HOME/.ssh/id_dsa user@server.example.com

Depois de copiar, ssh-copy-idvocê não deve mais ser solicitado uma senha quando você ssh.


0

Algumas sugestões:

  • Verifique as permissões do seu /root/.ssh (e seu conteúdo
  • Verifique se o ssh permite login de root e / ou autenticação de chave pública (/ etc / ssh / sshd_config iirc)
  • use ssh -v -v para ver mais resultados de depuração

Eu já verifiquei isso. Tudo parece bem para mim. Atualizei minha resposta com mais informações.
Poma

0

Use LogLevel DEBUGem /etc/ssh/sshd_configdepurar. Uma possível pegadinha é ter o .sshdiretório /home/someuser/como deveria estar /root/.


0

Eu encontrei isso, porque eu tinha um usuário criptografado no meu sistema. Isso leva o sshd à suposição de que todos os diretórios de usuários são criptografados e o arquivo allowed_keys está localizado em/etc/ssh/username/authorized_keys

Para mim, funcionou, depois que mudei a chave autorizada para /etc/ssh/username/e depois chown -R username:username /etc/ssh/username/. Engraçado o suficiente, que eu tinha que fazer isso para todos os usuários, mesmo os não criptografados!

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.