Login de chave pública SSH: duas chaves diferentes e comportamento SSH_AUTH_SOCK

Question

Um usuário ( user1 ) em uma área de trabalho do Ubuntu 12.04 possui duas chaves SSH RSA configuradas: ~/.ssh/id_rsa e ~/.ssh/id_rsa1 (e .pub files). Ambas as chaves públicas são configuradas nas chaves autorizadas na conta do servidor ( user1@myserver ).

Quando conectado à máquina desktop (cliente), e usando um terminal Gnome, o login no servidor usando as duas teclas funciona bem:

• ssh user1@myserver implicitamente recebe /home/user1/.ssh/id_rsa
• ssh -f /home/user1/.ssh/id_rsa1 user1@myserver também funciona.

Se, em vez de fazer login pelo Gnome Desktop, eu fizer logon na máquina cliente via SSH a partir de outro host (ou mesmo localhost ) ou usar su , usar /home/user1/.ssh/id_rsa não funcionará mais.

Isso parece ter algo a ver com SSH_AUTH_SOCK (ausente originalmente no ambiente configurado com uma conexão SSH para o cliente). Se eu configurá-lo para ser o valor visível na sessão da área de trabalho /tmp/keyring-xxxxxxxxxxx/ssh , fazer login com id_rsa funciona bem novamente.

Se eu desativar o SSH_AUTH_SOCK (para fazer o log com id_rsa falhar novamente) e copiar id_rsa1 para id_rsa (e .pub files), agora ele também funciona com id_rsa .

O que pode explicar a diferença de comportamento entre esses dois pares de chaves e sua interação com SSH_AUTH_SOCK ?

Não consigo ver nada nos registros do servidor.

Aqui está o fragmento dos registros do cliente SSH, pouco antes de diferir:

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: /home/user1/.ssh/id_rsa (0x7f6b7059b260)
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/user1/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply

Seguido por isso, quando não funciona para esse usuário / chave:

debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method

    

Answer 1

Acontece que a chave que não funcionou não foi configurada corretamente no arquivo authorized_keys , afinal. Desculpe por isso ...

Eu presumi erroneamente que ssh -i /home/user1/.ssh/id_rsa user1@myserver foi uma indicação de que foi configurado corretamente, mas isso não é o caso. Faz uso de outras teclas também. Forçar ssh -i /home/user1/.ssh/id_rsa -oIdentitiesOnly=yes user1@myserver faz com que ele falhe com a configuração incorreta também.

Eu acho que o agente SSH configurado ao se conectar com o Gnome também pega outras chaves no diretório ~/.ssh/ , o que faz com que funcione com essa outra chave, mesmo que a chave errada seja especificada com -i .

    

Answer 2

Na verdade, eu não uso o gnome, mas é provável que ele esteja tentando se comunicar com um agente ssh (ou mesmo começando um para sua conveniência).

Você não mencionou se suas chaves não têm senha.

Outra coisa que pode ter dado errado na cópia é a permissões em a) user2's / home, b) seus .ssh ou c) arquivo authorized_keys.