SSH ids são esquecidos no logout

Question

Estou com problemas para configurar a autenticação de chave pública SSH. Eu quero usar isso para fazer backup do meu servidor para um servidor de backup com SSH. Eu farei isso automaticamente com um cronjob, então não posso digitar a frase secreta ou algo assim.

O que eu fiz:

• Crie uma chave com ssh-keygen
• Copie a chave para o servidor de backup com ssh-copy-id
• Inicie o agente SSH com ssh-agent bash
• Adicione a chave ao agente com ssh-add
• Verifique isso com ssh-add -l - a chave foi adicionada
• Verifique tudo - funcionou

Eu fiz tudo isso usando root (via sudo -s ) no servidor principal e meu próprio usuário no servidor de backup.

No entanto, agora eu saí do sudo no servidor principal e entrei novamente (para root, com sudo). Quando eu tentei abrir uma conexão com a minha chave ( ssh -i the-key the-user@the-host ), eu tenho que digitar a senha novamente! Então eu corri ssh-add -l e consegui:

Could not open a connection to your authentication agent

Como posso configurá-lo dessa maneira para que eu nunca precise digitar novamente a frase secreta?

Aqui está o ssh -vvv the-user@the-host :

root@cs:/# ssh -vvv [email protected]
OpenSSH_6.1p1 Debian-4, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 62.234.74.186 [62.234.74.186] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug3: Incorrect RSA1 identifier
debug3: Could not load "/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /.ssh/id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "62.234.74.186" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /root/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],[email protected],[email protected],ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 24:60:36:95:d8:3f:04:b0:20:94:6b:a9:98:bf:22:1b
debug3: load_hostkeys: loading entries for host "62.234.74.186" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /root/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug1: Host '62.234.74.186' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_ecdsa_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: /.ssh/id_rsa (0x7f4a9ecf0810)
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: /.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp fe:2f:03:4a:68:c0:ce:b1:e9:b5:74:9c:c5:cb:f5:1f
debug3: sign_and_send_pubkey: RSA fe:2f:03:4a:68:c0:ce:b1:e9:b5:74:9c:c5:cb:f5:1f
debug1: key_parse_private_pem: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/.ssh/id_rsa':

E esta é a parte relevante de /var/log/auth.log no lado do servidor:

Jun 14 10:06:30 laptop-camil sshd[2265]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=vivisoft.nl  user=camilstaps
Jun 14 10:06:34 laptop-camil sshd[2265]: Connection closed by 164.138.27.37 [preauth]

Isso é o que recebo quando executo nohup ssh-agent bash & (veja os comentários):

root@cs:~# nohup ssh-agent bash &
[1] 1287
root@cs:~# nohup: ignoring input and appending output to ânohup.outâ
<here is an empty line with the cursor>

Por algum motivo, a saída de nohup é colocada na próxima linha e uma nova linha é adicionada.

    

Answer 1

Primeiro: o agente chave deve sair quando você efetua logout, por design. Devido a problemas de segurança, você não deseja que seu login seja aberto se você fizer logout por engano. Então, você realmente NÃO deve usar o agente de chaves ssh para isso, não é o modo de usá-lo.

Segundo: É possível ter um usuário muito restrito com poucos direitos, para armazenar / receber arquivos de backup em / srv / backup ou onde quer que tenha acesso. Para efetuar login nesse usuário, você tem um certificado ssh sem qualquer senha de certificado, para que possa efetuar login sem senha se o cliente tiver o certificado correto.
Você pode até mesmo restringir quais máquinas têm permissão para se conectar e quais programas executar em ~ / .ssh, procure no manual.

    

Answer 2

Quando você está logado como root (em sua saída detalhada acima mostra que você está) e você executa ssh , ele irá procurar por chaves no diretório .ssh do root; não é o diretório do usuário especificado na string de conexão ssh .

Não sei ao certo por que você está executando nada disso usando sudo ; Quando você cria e copia suas chaves, você precisa estar logado como o usuário que você pretende usar para ssh .

Estou um pouco confuso com a sua descrição do que você fez, mas como primeiro passo, sugiro que você tenha criado a chave no diretório .ssh do usuário correto e que, quando estiver executando ssh , esteja executando-o como o usuário correto para pegar o arquivo de chave.

A segunda parte da sua pergunta é sobre o uso de ssh-agent para armazenar a senha da sua chave. Há um bom guia para fazer isso aqui: link . Novamente, você precisa estar executando ssh-agent (no cliente, se isso não estiver claro) como o usuário correto. Observe que ssh-agent armazena apenas a frase secreta na memória. Por isso, se ela for encerrada e você iniciar um novo processo ssh-agent , ela não mais se lembrará da frase secreta. Em um servidor, isso não é um problema; você só precisa iniciar o agente uma vez e mantê-lo em execução em segundo plano. Há detalhes no link acima explicando como informar ao seu script onde encontrar o agente armazenando o local do soquete do agente em um arquivo temporário que seu script de backup possa ler.