Сбой SSH после отложенного открытого ключа и одной попытки

У меня есть рабочая настройка SSH, которая использует открытый ключ без каких-либо проблем. В частности, я использую SCP -i для копирования файлов на удаленный сервер, и это работает.

scp -i /var/www/key/id_rsa /var/www/backups/example.dat [email protected]:/var/www/backups

Это прекрасно работает в командной строке при входе в систему как root или living.

Вот пример РАБОТАЮЩЕЙ отладки из теста /usr/sbin/sshd -d:

Server listening on :: port 22.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from X.X.X.X port 33166 on Y.Y.Y.Y port 22
debug1: Client protocol version 2.0; client software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: SELinux support disabled [preauth]
debug1: permanently_set_uid: 74/74 [preauth]
debug1: list_hostkey_types: ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: client->server aes128-ctr [email protected] none [preauth]
debug1: kex: server->client aes128-ctr [email protected] none [preauth]
debug1: kex: [email protected] need=16 dh_need=16 [preauth]
debug1: kex: [email protected] need=16 dh_need=16 [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user living service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "living"
debug1: PAM: setting PAM_RHOST to "FQDN_redacted"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user living service ssh-connection method publickey [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: test whether pkalg/pkblob are acceptable [preauth]
debug1: temporarily_use_uid: 1001/1001 (e=0/0)
debug1: trying public key file /home/living/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Found matching RSA key: 5a:c2:98:38:bf:b3:01:13:55:b0:3d:74:61:3f:b1:f3
debug1: restore_uid: 0/0
Postponed publickey for living from X.X.X.X port 33166 ssh2 [preauth]
debug1: userauth-request for user living service ssh-connection method publickey [preauth]
debug1: attempt 2 failures 0 [preauth]
debug1: temporarily_use_uid: 1001/1001 (e=0/0)
debug1: trying public key file /home/living/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Found matching RSA key: 5a:c2:98:38:bf:b3:01:13:55:b0:3d:74:61:3f:b1:f3
debug1: restore_uid: 0/0
debug1: ssh_rsa_verify: signature correct
debug1: do_pam_account: called
Accepted publickey for living from X.X.X.X port 33166 ssh2: RSA 5a:c2:98:38:bf:b3:01:13:55:b0:3d:74:61:3f:b1:f3
debug1: monitor_child_preauth: living has been authenticated by privileged process
debug1: monitor_read_log: child log fd closed
debug1: temporarily_use_uid: 1001/1001 (e=0/0)
debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism
debug1: restore_uid: 0/0
debug1: SELinux support disabled
debug1: PAM: establishing credentials
User child is on pid 2320
debug1: PAM: establishing credentials
debug1: permanently_set_uid: 1001/1001
debug1: Entering interactive session for SSH2.

Моя проблема заключается в следующем: когда я запускаю ту же команду SCP в сценарии PERL в качестве команды bash с обратной кавычкой, происходит сбой со следующей отладкой.

$x=`scp -i /var/www/keys/living/id_rsa /var/www/$RS->[$x][3].dat living\@$a:/var/www/`;

Я думаю, что проблема может быть решена, если я смогу понять, почему команда SCP, запускаемая внутри PERL, пытается выполнить только один раз.

Вот пример НЕУДАЧИ отладки из теста /usr/sbin/sshd -d:

Server listening on :: port 22.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from X.X.X.X port 33208 on Y.Y.Y.Y port 22
debug1: Client protocol version 2.0; client software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: SELinux support disabled [preauth]
debug1: permanently_set_uid: 74/74 [preauth]
debug1: list_hostkey_types: ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: client->server aes128-ctr [email protected] none [preauth]
debug1: kex: server->client aes128-ctr [email protected] none [preauth]
debug1: kex: [email protected] need=16 dh_need=16 [preauth]
debug1: kex: [email protected] need=16 dh_need=16 [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user living service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "living"
debug1: PAM: setting PAM_RHOST to "FQDN_redacted"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user living service ssh-connection method publickey [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: test whether pkalg/pkblob are acceptable [preauth]
debug1: temporarily_use_uid: 1001/1001 (e=0/0)
debug1: trying public key file /home/living/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Found matching RSA key: 5a:c2:98:38:bf:b3:01:13:55:b0:3d:74:61:3f:b1:f3
debug1: restore_uid: 0/0
Postponed publickey for living from X.X.X.X port 33208 ssh2 [preauth]
Connection closed by X.X.X.X [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed
debug1: do_cleanup
debug1: PAM: cleanup
debug1: Killing privsep child 2409

person JasonFJ    schedule 02.10.2017    source источник
comment
Как выглядит ваш сценарий? Мои деньги были бы на проблеме интерполяции/экранирования/цитирования.   -  person Sobrique    schedule 02.10.2017
comment
Пожалуйста, отредактируйте это в своем посте.   -  person Sobrique    schedule 02.10.2017
comment
Добавлено в пост выше второй отладки.   -  person JasonFJ    schedule 02.10.2017
comment
Возможно, уместно добавить, что эта команда SCP с обратной галочкой работала в сценарии правильно. Единственное, что существенно изменилось, это то, что теперь он запускается как часть дочернего процесса, который разветвляется от родителя с $|=1; и $SIG{CHLD} = ИГНОРИРОВАТЬ; set (потому что мне нужно, чтобы родитель вышел из-за причин обновления пользовательского браузера).   -  person JasonFJ    schedule 02.10.2017
comment
После дальнейших размышлений я переместил код из дочернего форка обратно в основной код и... мне неловко говорить... я получил ужасную запись в error_log: Разрешения 0660 для... слишком открыты. Сделаю дополнительные анализы и вернусь с результатами. :(   -  person JasonFJ    schedule 02.10.2017


Ответы (1)


Решение этой проблемы заключалось в том, что разрешения закрытого ключа файла "id_rsa" были установлены на 0660 и должны были быть изменены на 0600.

Ошибка новичка, которая была скрыта, потому что команда SCP выполнялась в PERL обратные кавычки как дочерний элемент ветки PERL со следующими командами:

 $|=1;$SIG{CHLD} = "IGNORE";

Это приводит к тому, что отладка дочернего процесса не отображается в журнале ошибок Apache error_log, и никакая отладка не выявляет проблему ни на исходном, ни на целевом серверах.

person JasonFJ    schedule 02.10.2017