Об идентификаторах SSH забывают относительно выхода из системы
Я испытываю затруднения при установке аутентификации открытого ключа SSH. Я хочу использовать это для резервного копирования моего сервера к серверу резервного копирования с SSH. Я сделаю это автоматически с cronjob, таким образом, я не смогу ввести в пароле или около этого.
Что я сделал:
- Сделайте ключ с
ssh-keygen - Скопируйте ключ к серверу резервного копирования с
ssh-copy-id - Запустите агент SSH с
ssh-agent bash - Добавьте ключ к агенту с
ssh-add - Проверьте это с
ssh-add -l- ключ был добавлен - Проверьте все - это работало
Я сделал весь этот корень использования (через sudo -s) на основном сервере и моем собственном пользователе в сервере резервного копирования.
Однако теперь я зарегистрировался из sudo на основном сервере и вошел в (для укоренения с sudo). Когда я пытался открыть соединение со своим ключом (ssh -i the-key the-user@the-host), я должен ввести в пароле снова! Так я runned 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, он будет искать ключи в каталоге root .ssh; не каталог пользователя, указанного в строке соединения ssh.
Я не совсем уверен, почему вы выполняете все это, используя sudo; когда вы создаете и копируете свои ключи, вам необходимо войти в систему как пользователь, которого вы собираетесь использовать для ssh.
Меня немного смущает ваше описание того, что вы сделали, но в качестве первого шага я предлагаю вам убедиться, что вы создали ключ в правильном пользовательском каталоге .ssh и что при запуске ssh вы запустив его как правильный пользователь, чтобы подобрать этот ключевой файл.
Вторая часть вашего вопроса касается использования ssh-agent для хранения ключевой фразы вашего ключа. Для этого есть хорошее руководство: http://www.akadia.com/services/ssh_agent.html . Опять же, вам нужно запустить ssh-agent (на клиенте, если это не ясно) как правильный пользователь. Обратите внимание, что ssh-agent сохраняет только парольную фразу в памяти, поэтому, если она будет прервана и вы начнете новый процесс ssh-agent, она больше не будет помнить вашу парольную фразу. На сервере это не проблема; вам просто нужно запустить агент один раз и запустить его в фоновом режиме. В приведенной выше ссылке есть подробности, объясняющие, как указать сценарию, где найти агент, путем сохранения местоположения сокета агента во временном файле, который может прочитать ваш сценарий резервного копирования.