ssh: Sin control tty: abierto /dev/tty: No existe tal dispositivo o dirección

Cuando me conecto desde una PC/Cygwin a través de SSH (a través de WiFi) al teléfono, siempre recibo el siguiente mensaje macabro:

$ ssh -T root@192.168.1.100 -p 50000
Authenticated with partial success.
root@192.168.1.100's password:
/system/bin/sh: No controlling tty: open /dev/tty: No such device or address
/system/bin/sh: can't find tty fd
/system/bin/sh: warning: won't have full job control
root@android:/ $

Sé que el dispositivo está allí y también probé varios chmodpermisos.

El problema es que no puedo usar stty(o cualquier cosa relacionada con ttys) para configurar las variables de entorno de mi terminal y, por lo tanto, no puedo usar la línea de comando TAB para completar o flecha arriba, para obtener el último comando, o usar, etc. También he CTRL-C/D/Zintentado jugar con varias set -oopciones, en vano.

Ahora, lo extraño es que este problema no está presente en absoluto cuando se usa un shell local a través de la aplicación Android Terminal Emulator, que parece asignar correctamente un pseudo terminal con control total del trabajo.

He estado buscando por todas partes cómo resolver esto, pero no he llegado a ninguna parte. Mi teléfono Samsung está usando una versión habilitada para SELinux (AOS 4.2.2) y estoy rooteado con CF-Auto-Root (v1.94), y estoy usando la última versión de ADB. El stock mksh es @(#)MIRBSD KSH R40 2011/10/07y, por lo tanto, quizás no sea totalmente compatible con SEL AOS, pero no puedo encontrar un binario MKSH ARM más nuevo (~R49) para probar.

EDIT-1 : estoy usando el servidor SSH .

EDIT-2 : Acabo de probar SSHelper que parece muy bueno (aunque 6 veces más grande). Pero es inestable y muestra problemas similares en el registro web:PTY allocation request failed on channel 0

EDIT-3 : después de iniciar sesión (con el nuevo servidor sshd) con: ssh -T dummy@192.168.1.10 -p 2222, pierdo el aviso, pero el acceso al shell sigue siendo correcto. luego ejecutar su -c /system/bin/sh -idevuélveme el indicador su correcto # y verificar set -oda:

u0_a202@MSM8960:home # set -o
Current option settings
allexport      off  login          off  nounset        off  verbose        off
bgnice         off  markdirs       off  physical       off  vi             off
braceexpand    on   monitor        on   posix          off  vi-esccomplete off
emacs          on   noclobber      off  privileged     off  vi-tabcomplete on
errexit        off  noexec         off  restricted     off  viraw          off
gmacs          off  noglob         off  sh             off  xtrace         off
ignoreeof      off  nohup          on   stdin          on
interactive    on   nolog          off  trackall       off
keyword        off  notify         off  utf8-mode      off

Pero TAB todavía se interpreta directamente como un carácter TAB y no como una línea de comando completada.

EDIT-4 : Esto debe ser un problema relacionado con SELinux / SEAndroid , ya que cuando deshabilito SELinux Enforcing configurándolo en Permissive , pierdo la capacidad de SU, pero todos los controles de terminal de shell normales funcionan. La forma de hacer esto es emitiendo: su 0 setenforce 0en cualquier shell que pueda obtener, y luego cierre la sesión y vuelva a iniciar sesión. Esto durará hasta que reinicies el teléfono.

EDIT-5 : por lo que entiendo, usar la ssh -topción se usa para forzar la asignación de un pseudo-terminal y termina la conexión si eso falla. Por lo tanto, falla cuando pty está bloqueado en el modo " Implicar ", mientras que el uso ssh -2se acepta con una mínima diferencia de error cuando se usa -vvvpara depurar.

$ ssh -t dummy@192.168.1.10 -p 2222 -vvv
...
dummy@192.168.1.10's password:
debug3: packet_send2: adding 64 (len 51 padlen 13 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
Authenticated to 192.168.1.10 ([192.168.1.10]:2222).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 100 id 0
PTY allocation request failed on channel 0

No aceptado, pero este próximo me da un caparazón sin ningún aviso.

$ ssh -2 dummy@192.168.1.10 -p 2222 -vvv
...
PTY allocation request failed on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Linux 3.4.0-2340422 armv7l

Este comportamiento me convence para pensar que está directamente relacionado con el bloqueo de ptyacceso de SELinux. Pero no tengo ni idea de cómo y dónde se hace esto.

EDIT-6 : Sí, ahí está. Acabo de encontrar la denegación de la política de SELinux en el audit.logarchivo en: /data/misc/audit/audit.log

audit(1401291488.480:203): avc:  denied  { setattr } for  pid=11441 comm="sshelper_sshd" name="0" dev="devpts" ino=3 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:untrusted_app_devpts:s0 tclass=chr_file VE=SEPF_GT-I9195_4.2.2_0022_M
audit(1401291488.480:203): arch=40000028 syscall=15 per=840000 success=no exit=-13 a0=beffd438 a1=190 a2=27da a3=c0000000 items=1 ppid=8499 pid=11441 auid=4294967295 uid=10202 gid=10202 euid=10202 suid=10202 fsuid=10202 egid=10202 sgid=10202 fsgid=10202 tty=(none) ses=4294967295 comm="sshelper_sshd" exe="/data/data/com.arachnoid.sshelper/bin/sshelper_sshd" subj=u:r:untrusted_app:s0 key=(null)
audit(1401291488.480:203):  cwd="/"
audit(1401291488.480:203): item=0 name="/dev/pts/0" inode=3 dev=00:09 mode=020600 ouid=10202 ogid=10202 rdev=88:00 obj=u:object_r:untrusted_app_devpts:s0

Entonces, ¿cómo arreglar esto?