Cuando me conecto desde el PC/Cygwin vía SSH (a través de WiFi) al teléfono, siempre me aparece 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á ahí, y también he probado varios chmod permisos.
El problema es que no puedo utilizar stty (o cualquier cosa relacionada con tty s) para establecer las variables de entorno de mi terminal, y por lo tanto no puedo utilizar la terminación de la línea de comandos TAB o la flecha hacia arriba, para obtener el último comando, o utilizar CTRL-C/D/Z etc. También he intentado jugar con varios set -o opciones, en vano.
Ahora bien, lo extraño es que este problema no se presenta en absoluto cuando se utiliza 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á utilizando un SELinux (AOS 4.2.2) versión habilitada y estoy rooteado con CF-Auto-Root (v1.94), y el uso de la última ADB . Las acciones mksh es @(#)MIRBSD KSH R40 2011/10/07 y, por lo tanto, tal vez no sea totalmente compatible con los AOS de SEL, pero no puedo encontrar un binario MKSH ARM más reciente (~R49), para probarlo.
EDIT-1 : Estoy usando Servidor SSH .
EDIT-2 : Acabo de intentar SSHelper que parecen muy agradables (aunque 6 x más grandes). 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 prompt, pero el acceso al shell sigue siendo correcto. su -c /system/bin/sh -i devuélveme lo correcto su prompt # y comprobación set -o da:
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 offPero TAB se sigue interpretando directamente como un carácter TAB y no como una terminación de línea de comandos.
EDIT-4 : Esto debe ser un SELinux / SEAndroid problema relacionado, ya que cuando desactivo SELinux Aplicación de poniéndolo en Permiso En este caso, pierdo la capacidad de usar SU, pero todos los controles normales de la terminal funcionan. La forma de hacerlo es emitiendo: su 0 setenforce 0 en cualquier shell que puedas conseguir, y luego cerrar la sesión y volver a entrar. Esto durará hasta que reinicie el teléfono.
EDIT-5 : Por lo que tengo entendido, el uso de la ssh -t se utiliza para forzar la asignación de un pseudotérmino, y termina la conexión si falla. Por lo tanto, falla cuando pty se bloquea en " Aplicación de ", mientras que el uso de ssh -2 se acepta con una diferencia mínima de error cuando se utiliza -vvv para 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 0No se aceptan, pero este siguiente me da una cáscara 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 armv7lEste comportamiento me está convenciendo de que está directamente relacionado con el bloqueo de SELinux pty acceso. Pero no tengo ni idea de cómo y dónde se hace esto.
EDIT-6 : Sí, ahí está. Acabo de encontrar la negación de la política SELinux en el audit.log archivar 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¿Cómo se arregla esto?
