No se puede usar como usuario sin tty


10

Estoy tratando de ejecutar un solo comando invocando ssh (usando la autenticación de clave) de un usuario que no tiene un tty (el usuario con el que se ejecuta mi servidor apache) y sigo obteniendo el siguiente resultado:

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.

El indicador -t se establece al invocar ssh. La clave no tiene una frase de contraseña, lo que debería suprimir la necesidad de cualquier entrada, pero aparentemente no la tiene. ¿Cómo puedo evitar que ssh intente abrir / dev / tty?

Editar: ¿las etiquetas de código no funcionan?

Edit2: comando ssh completo:

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

He reemplazado mi nombre de usuario con "nombre de usuario".

Edit3: probé ssh-ing usando la misma clave que root y obtuve este resultado:

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).

Me pide una frase de contraseña aunque no debería necesitarla. Además, puedo usar la clave para ssh usando PuTTY en una máquina con Windows muy bien y no me pide una frase de contraseña.

Edit4: agregué el servidor a los usuarios de apache known_hosts y ahora obtengo esto:

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).`

Además, este es el contenido de known_hosts:

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

¿Por qué dice ecdsa? Es una clave rsa.

Edit5: Resuelto. El problema fue que el par de claves fue generado por PuTTY, que escribe la clave privada en un formato que no es compatible con OpenSSH. Solución proporcionada por cjc en un comentario.


Re: etiqueta de código. No, ya sea código de sonido envolvente con marca de retroceso o ponga 4 espacios al frente de la línea.
cjc

¿Cuál es el comando ssh completo?
cjc

¿Por qué estás pasando un -t?
Zoredache

@Zoredache Pensé que ayudaría. Algún sitio lo sugirió.
Surma

1
@Surma, ecdsa se refiere a la clave del servidor, no a la clave del cliente.
amcnabb

Respuestas:


11

El problema en realidad no parece ser que esté tratando de leer la frase de contraseña, eso es solo una advertencia. Más bien, está tratando de hacer la verificación de la clave del host pero falla. Si realmente desea que nunca pregunte sobre las claves de host, considere agregar las siguientes opciones a la línea de comando ssh:

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

Tenga en cuenta que puede haber implicaciones de seguridad, así que asegúrese de leer sobre estas opciones en la ssh_configpágina del manual.

EDITAR: dados sus mensajes de error actualizados, parece que tiene un archivo de identidad dañado (o como lo señaló cjc, podría estar en el formato incorrecto). Intente crear uno nuevo manualmente con ssh-keygen y agréguelo a las claves_autorizadas del servidor.


Parece que tienes razón, solo intenté usar la clave como root. Resultado en OP.
Surma

1
En realidad, en lugar de usar StrictHostKeyChecking = no, también puede obtener la clave pública del servidor y pegarla en el archivo .ssh / known_host del usuario. O ponga eso en el archivo conocido de host_hosts en todo el sistema.
cjc

@cjc, estoy de acuerdo en que esa suele ser la mejor solución.
amcnabb

@cjc Copié los unknown_hosts de root (que agregó el servidor a los hosts conocidos) y configuré los permisos correctos. Ahora tengo una salida diferente, verifique el OP.
Surma

1
@amcnabb Mencionaste que usaste la clave en PuTTY. ¿Convertiste la clave a OpenSSH?
cjc

0

Fuera de interés, lo que se establece como el entorno en /etc/passwd- la falta de /bin/bashserá probablemente su problema.


/ bin / false Probablemente debería haber mencionado que esto lo está ejecutando php, que aparentemente genera un shell cuando invocas shell_exec () (que es lo que estoy usando para ejecutar esto).
Surma

1
Entendido. Entonces en ese caso, ¿por qué no sólo el uso de pecl.php.net/package/ssh2 - en lugar de la piratería a través deshell_exec()
Ben Lessani - Sonassi

Eso es una buena idea.
Surma

Claro que sí, realmente debería explicar en su pregunta que está intentando hacer esto a través de PHP, ya que la respuesta que proporcioné es más precisa para resolver su pregunta.
Ben Lessani - Sonassi
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.