LINUX.ORG.RU
решено ФорумAdmin

подключение ssh по ключам

 , ,


0

1

Добрый день!

У нас есть два сервера 10.10.10.4 и 10.10.10.21 Хочу настроить запуск в кроме скрипта по бэкапу веб-сервера:

rsync -avzPX --update --exclude 'www/bitrix/backup' --exclude 'www/bitrix/managed_cache' --exclude 'www/bitrix/cache' --exclude 'www/bitrix/stack_cache' -e 'ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null' /home/bitrix/ backup@10.10.10.21:/home/bitrix/

Для этого пробую настроить авторизацию по ssh с помощью rsa ключей, на 10.10.10.4 под рутом делаю:

   ssh-keygen -t rsa
   ssh-copy-id -i ~/.ssh/id_rsa.pub backup@10.10.10.21
Но всё равно при подключении по ssh он запрашивает пароль.

ssh backup@10.10.10.21
backup@10.10.10.21's password:

Подскажите, что я делаю не так?


/etc/ssh/sshd_config AuthorizedKeysFile .ssh/authorized_keys

screamager
()

Но всё равно при подключении по ssh он запрашивает пароль.

А подключаешься ты тоже от рута?

theNamelessOne ★★★★★
()
Ответ на: комментарий от Pinkbyte

Я в 100500ый раз скажу, эта команда — говно, которое не помогает в 99% случаев. Надо включать дебаг на сервере.

Могу погадать: у ТС права на ~/.ssh слишком открытые

futurama ★★★★★
()
Ответ на: комментарий от futurama

эта команда — говно, которое не помогает в 99% случае

Эта команда - очень даже норм, она помогает понять когда жопа на клиенте. А вот когда уже видно, что на клиенте жопы нет, всё читается, только сервер кладёт болт - идем на сервер и читаем логи там.

Можно конечно наоборот, спору нет. Только один хрен если мы клиентом тыкаться будем - хорошо бы сразу дебаг собрать на всякий случай.

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

Какие ты знаешь проблемы на клиенте, которые покажет -vvv ???

Серьезно, ты же опытный пользователь/админ/тыжпрограммист/... наверное сходу можешь сказать

futurama ★★★★★
()
Ответ на: комментарий от Pinkbyte
[backup@bitrix ~]$ ssh -vvv backup@10.10.10.21
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 10.10.10.21 [10.10.10.21] port 22.
debug1: Connection established.
debug1: identity file /home/backup/.ssh/identity type -1
debug1: identity file /home/backup/.ssh/identity-cert type -1
debug3: Not a RSA1 key file /home/backup/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/backup/.ssh/id_rsa type 1
debug1: identity file /home/backup/.ssh/id_rsa-cert type -1
debug1: identity file /home/backup/.ssh/id_dsa type -1
debug1: identity file /home/backup/.ssh/id_dsa-cert type -1
debug1: identity file /home/backup/.ssh/id_ecdsa type -1
debug1: identity file /home/backup/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug3: Wrote 960 bytes for a total of 981
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: 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: 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
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
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: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug3: Wrote 24 bytes for a total of 1005
debug2: dh_gen_key: priv key bits set: 125/256
debug2: bits set: 489/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: Wrote 144 bytes for a total of 1149
debug3: check_host_in_hostfile: host 10.10.10.21 filename /home/backup/.ssh/known_hosts
debug3: check_host_in_hostfile: host 10.10.10.21 filename /home/backup/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host '10.10.10.21' is known and matches the RSA host key.
debug1: Found key in /home/backup/.ssh/known_hosts:1
debug2: bits set: 525/1024
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
debug3: Wrote 16 bytes for a total of 1165
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug3: Wrote 48 bytes for a total of 1213
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/backup/.ssh/identity ((nil))
debug2: key: /home/backup/.ssh/id_rsa (0x7f5964b21f40)
debug2: key: /home/backup/.ssh/id_dsa ((nil))
debug2: key: /home/backup/.ssh/id_ecdsa ((nil))
debug3: Wrote 64 bytes for a total of 1277
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug3: Trying to reverse map address 10.10.10.21.
debug1: Unspecified GSS failure.  Minor code may provide more information
Cannot determine realm for numeric host address

debug1: Unspecified GSS failure.  Minor code may provide more information
Cannot determine realm for numeric host address

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
Cannot determine realm for numeric host address

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/backup/.ssh/identity
debug3: no such identity: /home/backup/.ssh/identity
debug1: Offering public key: /home/backup/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 368 bytes for a total of 1645
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/backup/.ssh/id_dsa
debug3: no such identity: /home/backup/.ssh/id_dsa
debug1: Trying private key: /home/backup/.ssh/id_ecdsa
debug3: no such identity: /home/backup/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
backup@10.10.10.21's password:
r1sh
() автор топика
Ответ на: комментарий от futurama

На сервере:

[root@bitrix2 home]# tail -10 /var/log/secure
Aug  9 10:19:59 bitrix2 sshd[14294]: Authentication refused: bad ownership or modes for directory /home/backup
Aug  9 10:24:13 bitrix2 sshd[14401]: Authentication refused: bad ownership or modes for directory /home/backup
Aug  9 10:24:13 bitrix2 sshd[14401]: Authentication refused: bad ownership or modes for directory /home/backup
Aug  9 10:24:14 bitrix2 sshd[14402]: Connection closed by 10.10.10.4
Aug  9 10:27:31 bitrix2 sshd[14454]: Authentication refused: bad ownership or modes for directory /home/backup
Aug  9 10:27:31 bitrix2 sshd[14454]: Authentication refused: bad ownership or modes for directory /home/backup
Aug  9 10:29:08 bitrix2 sshd[14455]: Connection closed by 10.10.10.4
Aug  9 10:29:12 bitrix2 sshd[14490]: Authentication refused: bad ownership or modes for directory /home/backup
Aug  9 10:29:12 bitrix2 sshd[14490]: Authentication refused: bad ownership or modes for directory /home/backup
Aug  9 10:31:13 bitrix2 su: pam_unix(su:session): session closed for user backup

[root@bitrix2 home]# ls -la
итого 40
drwxr-xr-x   7 bitrix bitrix 4096 Авг  9 03:07 .
dr-xr-xr-x  22 root   root   4096 Авг  8 23:08 ..
drwxr-xr-x   2 adm_1  root   4096 Июл 25 11:13 adm_1
drwxrwxr--   4 backup backup 4096 Авг  9 10:09 backup
-rwxr-xr-x   1 adm_1  bitrix   18 Июл 18  2013 .bash_logout
-rwxr-xr-x   1 adm_1  bitrix  176 Июл 18  2013 .bash_profile
-rwxr-xr-x   1 bitrix bitrix  124 Июл 18  2013 .bashrc
drwxr-xr-x.  7 bitrix bitrix 4096 Ноя  2  2015 bitrix
drwxr-xr-x   2 adm_1  bitrix 4096 Ноя 12  2010 .gnome2
drwxr-xr-x   4 adm_1  bitrix 4096 Мар 26  2014 .mozilla
r1sh
() автор топика
Ответ на: комментарий от r1sh

bad ownership or modes for directory /home/backup

Как я и угадал на счет неправильных прав доступа, так и log sshd сразу диагностировал проблему, a -vvv только мусор на экран выдал

futurama ★★★★★
()
Ответ на: комментарий от futurama

Какие ты знаешь проблемы на клиенте, которые покажет -vvv ???

Кривые права на ~/.ssh на клиенте, например. Сюрприз, да, жопа с правами может быть не только на сервере

Pinkbyte ★★★★★
()
Ответ на: комментарий от futurama

a -vvv только мусор на экран выдал

Нет, не только. Он как раз показал что на клиенте всё окей, курить надо сервер.

debug1: Offering public key: /home/backup/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 368 bytes for a total of 1645
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/backup/.ssh/id_dsa
debug3: no such identity: /home/backup/.ssh/id_dsa
debug1: Trying private key: /home/backup/.ssh/id_ecdsa
debug3: no such identity: /home/backup/.ssh/id_ecdsa
debug2: we did not send a packet, disable method

То есть мы успешно попробовали авторизацию по ключу, но сервер нас послал.

Тот факт, что ты не умеешь читать выхлоп ssh -vvv не значит что он бесполезен :-)

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

Тот факт, что ты не умеешь читать выхлоп ssh -vvv не значит что он бесполезен :-)

Смелое заявление, однако.

Я могу читать желтую прессу, но она бесполезна в деле. Так и здесь -vvv бесполезен в 99%

За мои 15 лет на ЛОРе был только один случай проблем на клиенте и это было видно по -vvv (проблема была в kerberos)

futurama ★★★★★
()
Ответ на: комментарий от Pinkbyte

Кривые права на ~/.ssh на клиенте, например. Сюрприз, да, жопа с правами может быть не только на сервере

Например???

$ ssh root@lnx33
Last login: ... 2016 from mydebian
[root@lnx33 ~]#

$ ls -ld .ssh
drwx------ 2 me me 141 Aug  3 22:45 .ssh

$ chmod 777 .ssh

$ ssh root@lnx33
Last login: ... 2016 from mydebian
[root@lnx33 ~]# 

$ chmod 700 .ssh
futurama ★★★★★
()
Ответ на: комментарий от futurama

Пожалуйста(всё сообщение не влезло, вырезал верх где идет чтение и разбор known_hosts):

pinkbyte@oas1 ~ $ ssh -vvv virt1
<поскипано>
debug1: Found key in /home/pinkbyte/.ssh/known_hosts:155
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/pinkbyte/.ssh/id_rsa (0x558151f9e7e0)
debug2: key: /home/pinkbyte/.ssh/id_dsa ((nil))
debug2: key: /home/pinkbyte/.ssh/id_ecdsa ((nil))
debug2: key: /home/pinkbyte/.ssh/id_ed25519 ((nil))
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,keyboard-interactive
debug3: start over, passed a different list publickey,keyboard-interactive
debug3: preferred 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/pinkbyte/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '/home/pinkbyte/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/home/pinkbyte/.ssh/id_rsa": bad permissions
debug1: Trying private key: /home/pinkbyte/.ssh/id_dsa
debug3: no such identity: /home/pinkbyte/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/pinkbyte/.ssh/id_ecdsa
debug3: no such identity: /home/pinkbyte/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/pinkbyte/.ssh/id_ed25519
debug3: no such identity: /home/pinkbyte/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug3: send packet: type 50
debug2: we sent a keyboard-interactive packet, wait for reply
debug3: receive packet: type 60
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:
Pinkbyte ★★★★★
()
Ответ на: комментарий от futurama

Версии/патчи разные скорее всего. У меня гента, OpenSSH 7.2_p2. На более старых такой проверки возможно нет(я просто смотрю у тебя вроде дебиан, там вряд ли гонятся за новыми версиями, если конечно не sid), смотреть в исходники лень :-)

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от r1sh

Так и не понял, кто и зачем права на файлы ключей такие поставил. Сколько не запускал ssh-copy-id, никогда проблем не было, на всяких разных ЦентОсах.

Не понял зачем руту ключи, обычно обычному пользователю делаю, а если вдруг надо какой-то скрипт от рута запускать, то у ssh есть опция identityfile=, куда прописываю полный путь к ключу.

lvi ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.