Не вдається ssh як користувач, що не містить tty

10

Я намагаюся запустити одну команду, викликаючи ssh (використовуючи автентифікацію ключа) від користувача, у якого немає tty (користувач мій сервер apache працює як) і продовжую отримувати наступний результат:

OpenSSH_5.9p1, OpenSSL 1.0.0g 18 Jan 2012
Pseudo-terminal will not be allocated because stdin is not a terminal.
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to localhost [::1] port 54367.
debug1: Connection established.
debug1: identity file nonpublic/id_rsa type 1
debug1: identity file nonpublic/id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9
debug1: match: OpenSSH_5.9 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
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 e3:c2:37:8e:8b:d4:77:63:7f:d2:ba:12:e5:e9:d1:9a
debug1: checking without port identifier
debug1: read_passphrase: can't open /dev/tty: No such device or address
Host key verification failed.

Прапор -t встановлюється при виклику ssh. У ключі немає парольної фрази, яка повинна пригнічувати потребу в будь-якому введенні, але, мабуть, це не так. Як я можу запобігти спробі ssh відкрити / dev / tty?

Редагувати: кодові теги не працюють?

Edit2: Повна команда ssh:

ssh -i nonpublic/id_rsa -l username -p 54367 -t -v username@localhost /home/username/minecraftserver/Scripts/start 2>&1

Я замінив своє ім’я користувача на "ім'я користувача".

Edit3: Я спробував ssh-ing за допомогою того ж ключа, що і root, і отримав такий результат:

OpenSSH_5.9p1, OpenSSL 1.0.0g 18 Jan 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to localhost [::1] port 54367.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /srv/http/nonpublic/id_rsa type 1
debug1: identity file /srv/http/nonpublic/id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9
debug1: match: OpenSSH_5.9 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
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 e3:c2:37:8e:8b:d4:77:63:7f:d2:ba:12:e5:e9:d1:9a
debug1: checking without port identifier
The authenticity of host '[localhost]:54367 ([::1]:54367)' can't be established.
ECDSA key fingerprint is e3:c2:37:8e:8b:d4:77:63:7f:d2:ba:12:e5:e9:d1:9a.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[localhost]:54367' (ECDSA) to the list of known hosts.
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /srv/http/nonpublic/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: key_parse_private_pem: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/srv/http/nonpublic/id_rsa':
debug1: No more authentication methods to try.
Permission denied (publickey).

Це пропонує мені ввести парольну фразу, навіть якщо вона не повинна бути потрібною. Крім того, я можу використовувати ключ для ssh при використанні PuTTY на машині Windows просто чудово, і це не підкаже мене для отримання парольної фрази.

Edit4: Я додав сервер до користувачів апаш-файлів known_hosts, і тепер я отримую це:

OpenSSH_5.9p1, OpenSSL 1.0.0g 18 Jan 2012
Pseudo-terminal will not be allocated because stdin is not a terminal.
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to localhost [::1] port 54367.
debug1: Connection established.
debug1: identity file nonpublic/id_rsa type 1
debug1: identity file nonpublic/id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9
debug1: match: OpenSSH_5.9 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
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 e3:c2:37:8e:8b:d4:77:63:7f:d2:ba:12:e5:e9:d1:9a
debug1: Host '[localhost]:54367' is known and matches the ECDSA host key.
debug1: Found key in /srv/http/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: nonpublic/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: key_parse_private_pem: PEM_read_PrivateKey failed
debug1: read PEM private key done: type
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug1: No more authentication methods to try.
Permission denied (publickey).`

Також це вміст відомих_хостів:

[localhost]:54367 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBILr7jLp5CeYfyrCroaDjkaWgDHXRrQD+G8Fz/CQOY1PcluUFTkrN447bXmC6R27LOClE+RPaveYb4MOlObpGGE=

Чому на ньому написано ecdsa? Це ключ rsa.

Правка5: Вирішено. Проблема полягала в тому, що пара ключів була створена PuTTY, який записує приватний ключ у форматі, несумісному з OpenSSH. Рішення, надане cjc у коментарі.

linux  ssh 
— Сурма
джерело
Re: код тегу. Ні, або об'ємний код із зворотною галочкою, або перед пробілом поставте 4 пробіли.
— cjc
Яка повна команда ssh?
— cjc
Чому ти проходиш -t?
— Зоредаче
@Zoredache Думав, що це допоможе. Деякий сайт запропонував це.
— Сурма
1
@Surma, ecdsa посилається на ключ сервера, а не на ключ клієнта.
— amcnabb

Відповіді:

11

Проблема насправді не полягає в тому, що вона намагається прочитати пароль - це лише попередження. Швидше, він намагається зробити перевірку ключа хоста, але не вдалося. Якщо ви дійсно хочете, щоб він ніколи не запитував про ключі хоста, подумайте про додавання наступних параметрів до командного рядка ssh:

-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o GlobalKnownHostsFile=/dev/null

Зауважте, що можуть бути наслідки для безпеки, тому обов'язково прочитайте про ці параметри на ssh_configсторінці "man".

EDIT: З огляду на оновлені повідомлення про помилку, схоже, у вас є пошкоджений файл посвідчення (або як зазначав cjc, він може бути у неправильному форматі). Спробуйте створити новий вручну за допомогою ssh-keygen та додайте його до дозволених_кеїв сервера.

— amcnabb
джерело
Ви начебто праві, я просто намагався використовувати ключ як корінь. Результат в ОП.
— Сурма
1
Насправді, замість використання StrictHostKeyChecking = ні, ви також можете отримати відкритий ключ сервера та вставити його у файл .ssh / known_host користувача. Або помістіть це у загальносистемний файл відомих_хостів.
— cjc
@cjc, я погоджуюся, що зазвичай краще рішення.
— amcnabb
@cjc Я скопіював відомі_хости з root (хто додав сервер до відомих хостів) і встановив правильні дозволи. Зараз я отримую різний вихід, перевірте ОП.
— Сурма
1
@amcnabb Ви згадали, що використовували ключ у PuTTY. Ви перетворили ключ у OpenSSH?
— cjc
0

Нецікаво те, що задано як середовище /etc/passwd- відсутність /bin/bash, ймовірно, буде вашим питанням.

— Бен Лессані - Сонассі
джерело
/ bin / false Я, мабуть, мав би зазначити, що цим керує php, який, очевидно, породжує оболонку, коли ви викликаєте shell_exec () (що я використовую для запуску цього).
— Сурма
1
Зрозумів. Тоді в такому випадку, чому ви просто не використовуєте pecl.php.net/package/ssh2 - а не злому зshell_exec()
— Бен Лессані - Сонассі
Це гарна ідея.
— Сурма
Звичайно, ви дійсно повинні пояснити у своєму запитанні, що ви намагаєтеся зробити це за допомогою PHP - так як відповідь, яку я надав, є більш точною для вирішення вашого питання.
— Бен Лессані - Сонассі
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.