Wenn ich mich von PC/Cygwin über SSH (über WiFi) mit dem Telefon verbinde, werde ich immer mit der folgenden makabren Nachricht begrüßt:
$ 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:/ $
Ich weiß, dass das Gerät da ist, und ich habe auch verschiedene Berechtigungen ausprobiert chmod.
sttyDas Problem ist, dass ich (oder etwas, das mit s verwandt ist ) nicht verwenden kann tty, um meine Terminalumgebungsvariablen festzulegen, und daher kann ich die Befehlszeilen-TAB-Vervollständigung oder den Pfeil nach oben nicht verwenden, um den letzten Befehl abzurufen oder usw. zu verwenden. CTRL-C/D/ZIch habe es auch versucht mit verschiedenen set -oOptionen spielen, ohne Erfolg.
Das Seltsame ist nun, dass dieses Problem überhaupt nicht vorhanden ist, wenn eine lokale Shell über die Android-Terminal-Emulator-App verwendet wird, die ein Pseudo-Terminal mit vollständiger Jobkontrolle korrekt zuzuweisen scheint.
Ich habe überall gesucht, wie ich das lösen kann, bin aber nirgendwo hingekommen. Mein Samsung-Telefon verwendet eine SELinux (AOS 4.2.2)-fähige Version und ich bin mit CF-Auto-Root (v1.94) gerootet und verwende die neueste ADB. Das Standard- Mksh ist @(#)MIRBSD KSH R40 2011/10/07und daher möglicherweise nicht vollständig kompatibel mit SEL AOS, aber ich kann keine neuere (~ R49) MKSH ARM-Binärdatei finden, um es damit zu versuchen.
EDIT-1 : Ich verwende den SSH-Server .
EDIT-2 : Ich habe gerade SSHelper ausprobiert , die sehr nett zu sein scheinen (obwohl 6 x größer). Aber es ist instabil und zeigt ähnliche Probleme im Webprotokoll:PTY allocation request failed on channel 0
EDIT-3 : Nach der Anmeldung (mit neuem sshd-Server) mit: ssh -T dummy@192.168.1.10 -p 2222verliere ich die Eingabeaufforderung, aber der Shell-Zugriff ist immer noch in Ordnung. Wenn Sie dann laufen, su -c /system/bin/sh -igeben Sie mir die korrekte su- Eingabeaufforderung # zurück, und die Überprüfung set -oergibt:
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
Aber TAB wird immer noch direkt als TAB-Zeichen und nicht als Befehlszeilenvervollständigung interpretiert.
EDIT-4 : Dies muss ein SELinux / SEAndroid- bezogenes Problem sein, denn wenn ich SELinux Enforcing deaktiviere, indem ich es auf Permissive setze , verliere ich die Fähigkeit zu SU, aber alle normalen Shell-Terminal-Steuerelemente funktionieren. Der Weg, dies zu tun, besteht darin, Folgendes auszugeben: su 0 setenforce 0in einer beliebigen Shell, die Sie erhalten können, und sich dann abmelden und erneut anmelden. Dies dauert so lange, bis Sie das Telefon neu starten.
EDIT-5 : Soweit ich weiß, ssh -twird mit der Option die Zuweisung eines Pseudo-Terminals erzwungen und die Verbindung beendet, wenn dies fehlschlägt. Daher schlägt es fehl, wenn pty im " Enforcing "-Modus blockiert ist , während die Verwendung ssh -2mit minimalem Fehlerunterschied akzeptiert wird, wenn die Verwendung -vvvzum Debuggen verwendet wird.
$ 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
Nicht akzeptiert, aber dieser nächste gibt mir ohne Aufforderung eine Shell.
$ 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
Dieses Verhalten überzeugt mich zu der Annahme, dass es direkt mit dem blockierenden ptyZugriff von SELinux zusammenhängt. Aber ich habe keine Ahnung, wie und wo das gemacht wird.
EDIT-6 : Ja, da ist es. Ich habe gerade die Ablehnung der SELinux-Richtlinie in der audit.logDatei gefunden in: /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
Wie kann man das beheben?
Sie verwenden ssh -Twhich verhindert die Zuweisung von tty(4) . Ohne Controlling ttygeht vieles nicht – ttyganz ohne Controlling geht vieles nicht.
Beachten Sie, dass Ihr ursprüngliches Problem nicht auf das Fehlen eines steuernden tty zurückzuführen ist, sondern auf das Fehlen einer pty/tty-Paarzuordnung.
Was Sie hier haben, ist im Grunde eine Eingabezeile „Bearbeiten“ – in Ihrem Fall nicht-Bearbeiten – auf der SSH- Client- Seite, die dann über ssh auf das Android-Gerät übertragen wird.
Versuchen Sie es mit ssh -t (Kleinbuchstaben t, beachten Sie den Unterschied). Ich kann Ihr Problem lokal reproduzieren, indem ich ausführe ssh -T localhost mksh -i, was auch zu einer Shell ohne Bearbeitung der Eingabezeile führt, also ist die Zuweisung von pty/tty hier der Weg, um sie zu lösen.
Ich gehe von den Änderungen an der Frage aus, dass dies bereits /dev/ptmxvorhanden und /dev/ptsgemountet ist und dass dies ein SELinux-Problem ist .
Die Einstellung $TERMlöst hier nichts: Sie ist lediglich dazu da, Programmen, die termcap oder curses verwenden (mksh verwendet beides nicht), mitzuteilen, welches physische Terminal (oder dessen Emulation) mit dem ttyGerät verbunden ist. mkshverwendet ein ttyfür die Befehlszeilenbearbeitung, wenn es vorhanden ist, und deaktiviert die Befehlszeilenbearbeitung, wenn es nicht vorhanden ist.
Sie müssen Ihre SELinux-Richtlinien bearbeiten, damit der SSH-Server ein pty/tty-Paar (oder sogar mehrere) pro Verbindung zuweisen kann.
(Diese Antwort wurde bearbeitet, um die Kommentare aus dieser und der ursprünglichen Frage einzufügen und einige Änderungen an der Frage widerzuspiegeln.)
-Tdas pty-Problem zu vermeiden, indem ich eine TERM-Variable manuell übergebe. Vielleicht falsch? Jedes Mal, wenn ich den -tSchalter gebe, akzeptiert ssh das Passwort und schlägt dann wegen der Erlaubnis zum Öffnen von pty mit fehl PTY allocation request failed on channel 0. Die Verwendung von (ssh2) lässt mich jedoch -2durch.
Izzy
nicht2qubit
nicht2qubit
Izzy
mirabilos
nicht2qubit