SSH идентификаторы забыты при выходе
У меня проблемы с настройкой аутентификации с открытым ключом SSH. Я хочу использовать это для резервного копирования моего сервера на резервный сервер с SSH. Я сделаю это автоматически с помощью cronjob, поэтому я не могу набрать парольную фразу или около того.
Что я сделал:
- Сделай ключ с
ssh-keygen - Скопируйте ключ на сервер резервного копирования с помощью
ssh-copy-id - Запустите агент SSH с
ssh-agent bash - Добавьте ключ к агенту с помощью
ssh-add - Проверьте это с помощью
ssh-add -l- ключ был добавлен - Проверьте все - это сработало
Я сделал все это с помощью рута (через sudo -s) на главном сервере и мой собственный пользователь на резервном сервере.
Тем не менее, теперь я вышел из sudo на главном сервере и снова вошел (root, с помощью sudo). Когда я попытался открыть соединение с моим ключом (ssh -i the-key the-user@the-host), Я должен снова ввести фразу-пароль! Итак, я побежал ssh-add -l и получил:
Could not open a connection to your authentication agent
Как я могу настроить его так, чтобы мне больше никогда не приходилось вводить парольную фразу?
Вот ssh -vvv the-user@the-host:
root@cs:/# ssh -vvv camilstaps@62.234.74.186
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: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,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: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,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,rijndael-cbc@lysator.liu.se
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,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,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,rijndael-cbc@lysator.liu.se
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,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
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':
И это соответствующая часть /var/log/auth.log на стороне сервера:
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]
Это то, что я получаю, когда бегу nohup ssh-agent bash & (см. комментарии):
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>
По какой-то причине выход nohup ставится на следующую строку, и добавляется новая строка.
2 ответа
Первое. Предполагается, что ключевой агент завершает работу при выходе из системы. Из-за проблем безопасности вы не хотите, чтобы ваш логин был открыт, если вы вышли из системы по ошибке. Таким образом, вы действительно не должны использовать ssh key agent для этого, это не способ использовать его.
Второе: возможно иметь очень ограниченного пользователя с ограниченными правами, для хранения / получения файлов резервных копий в /srv/backup или там, где у него есть доступ. Для входа в систему этого пользователя у вас есть сертификат ssh без пароля сертификата, поэтому вы можете войти без пароля, если у клиента есть правильный сертификат.
Затем вы можете даже ограничить, какие машины разрешено подключать и какие программы запускать в ~/.ssh, посмотрите это в руководстве.
Когда вы вошли в систему как root (в вашем подробном выводе выше это показывает, что вы есть), и вы запускаете ssh, он будет искать ключи в корневом каталоге.ssh; не каталог пользователя, указанного в ssh Строка подключения.
Я не совсем уверен, почему вы используете это с помощью sudo; когда вы создаете и копируете ключи, вы должны войти в систему как пользователь, для которого вы собираетесь использовать ssh,
Меня немного смущает ваше описание того, что вы сделали, но в качестве первого шага я предлагаю вам убедиться, что вы создали ключ в правильном пользовательском каталоге.ssh и что при запуске ssh вы используете его как правильный пользователь, чтобы подобрать этот ключевой файл.
Вторая часть вашего вопроса об использовании ssh-agent сохранить пароль вашего ключа. Для этого есть хорошее руководство: http://www.akadia.com/services/ssh_agent.html. Опять же, вам нужно бежать ssh-agent (на клиенте, если это не ясно) как правильный пользователь. Обратите внимание, что ssh-agent хранит только парольную фразу в памяти, поэтому, если она завершена, и вы начинаете новый ssh-agent обрабатывать его больше не будет помнить вашу фразу-пароль. На сервере это не проблема; вам просто нужно запустить агент один раз и запустить его в фоновом режиме. В приведенной выше ссылке есть подробности, объясняющие, как указать сценарию, где найти агент, путем сохранения местоположения сокета агента во временном файле, который может прочитать ваш сценарий резервного копирования.