nicht alle Programme funktionieren über ssh

tobb · Beitrag von **tobb** » 20.06.2006 19:04:01

Wenn ich mich über ssh auf einem anderen Rechner einlogge, kann ich dort keine Dateien mit vim auf der Konsole bearbeiten. Öffne ich eine Datei mit zB "vim /etc/resolv.conf" erscheint vim allerdings wird der Dateiinhalt nicht angezeigt, so als wäre die Datei leer. Lustigerweise kann ich garnichts eingeben, d.h. ich kann vim nicht mal beenden. Das selbe passiert bei aptitue wenn ich im Menü die Suchoption auswähle. Dann kann ich kein Suchbegriff mehr eingeben und auch aptitude nicht mehr beenden.

crazyed · Beitrag von **crazyed** » 20.06.2006 20:27:08

Dir fehlen die nötigen Rechte. Damit bleibt vim eben leer.

tobb · Beitrag von **tobb** » 20.06.2006 20:52:00

Nein da ist doch kein Verhalten bei fehlenden Rechten. Es passiert aber auch las root...

tobb · Beitrag von **tobb** » 24.06.2006 20:43:42

Also nochmal:

ich logge mich so ein:

Code: Alles auswählen

ssh -l [username] [ip-adresse]

Beispiel 1:
Ich möchte etwas installieren:

Code: Alles auswählen

# aptitude install acpid
Paketlisten werden gelesen... Fertig
Abh�gigkeitsbaum wird aufgebaut
Lese erweiterte Statusinformationen
Initialisiere Paketstatus... Fertig
Lese Task-Beschreibungen... Fertig
Die folgenden Pakete werden zus�zlich installiert:
  acpid
0 Pakete aktualisiert, 1 zus�zlich installiert, 0 werden entfernt und 0 nicht aktualisiert.
Muss 0B/28,3kB an Archiven herunterladen.Nach dem Entpacken werden 188kB zus�zlich belegt sein.
Schreibe erweiterte Statusinformation... Fertig
Vorkonfigurieren der Pakete ...

So, da hängt er dann Stunden lang, es tut sich nichts mehr. Installiere ich das Programm am Rechner selber läuft alles ohne Probleme.

Beispiel 2:
Ich starte das Programm top

Code: Alles auswählen

# top

Er springt in eine neue Zeile und das wars. ab jetzt ist die Konsole unbenutzbar, ich muss erst ssh killen damit ich ausgellogt werde und die Konsole wieder benutzen kann.

Beispiel 3:
Ich starte vim:
Ein leerer Bildschirm begrüßt mich mit dem vim cursor oben links. Allerdings kann ich absolut nichts eingeben oder vim beenden. Es hängt also wieder alles.
emacs funktioniert ohne Probleme.

Beispiel 4:
Ab und zu passiert es, dass nach einem Befehl die Meldung "Garbage option" erscheint. Dann hängt wieder alles.

Ich kann die Kiste so also nicht per ssh bedienen. Wenigstens funktioniert ein reboot, weil an dem Rechner sind weder Bildschirm noch Tastatur.

deadeye · Beitrag von **deadeye** » 24.06.2006 20:52:22

Ich würde mal Terminal-Einstellungen einwerfen.
Könnte mir vorstellen, dass die Einstellungen da inkompatibel sind, dass noch auf der reinen Console gut geht, aber sobald ncurses ins Spiel kommt, geht es schief.

Vergleiche mal

Code: Alles auswählen

echo $TERM

auf beiden Maschinen.

HTH,
deadeye

tobb · Beitrag von **tobb** » 24.06.2006 21:28:46

xterm kommt raus.

Der ssh-server ist dabei ein debian sarge und der Rechner mit dem ich mich einlogge ein debian testing.

chabayo · Beitrag von **chabayo** » 24.06.2006 23:24:39

...auch zwei Tests anfuehren will...

...andere Terminals versucht ? Bei mir macht xterm/gnome-terminal nicht das gleiche, wenn du ohne X arbeitest, schon mit X ueber xterm versucht ( gleiches Problem ) ...

...etwas wobei ich gern selbst draus lerne...es gibt doch Tasks die gewisse Prozesse als root starten moechten, koennte es sein das die Einstellung

/etc/ssh/sshd_config hat geschrieben:PermitRootLogin no

vielleicht hierbei ein Problem verursacht??

...fuer mich klingt es aber im allgemeinen mehr nach einem verstaendnisdefizit hinsichtlich tty<->pty (hab ich das jetzt richtig in Beziehung gesetzt

)...

tobb · Beitrag von **tobb** » 24.06.2006 23:38:14

Ich habe die Sachen auf der Normalen Linuxkonsole, also Strg+Alt+F1 ausgeführt. Das ist doch einfach nur die bash und kein Terminal.

Deine genannte Option steht so:
PermitRootLogin yes

chabayo · Beitrag von **chabayo** » 24.06.2006 23:55:41

tobb hat geschrieben:Ich habe die Sachen auf der Normalen Linuxkonsole, also Strg+Alt+F1 ausgeführt. Das ist doch einfach nur die bash und kein Terminal.

...das macht zwar den Bock nicht Fett, aber ich dich nicht dumm sterben lassen willl.

Meines Wissens nach ist alles was nicht ueber Netzwerk (und alles was ueber Sockets laeuft betrachte ich als netzwerktechnisch ) mit Linux kommuniziert ueber Terminals mit dem zu steuernden Prozess in Verbindung.

Ich finds zwar echt schlecht beschrieben ( oder versteh ich nur zu wenig von der Materie ) aber ich hatte mich doch gefragt ob ich das tty <-> pty korrekt in beziehung setze, das fuehrte mich darueber http://de.wikipedia.org/wiki/Pseudoterminal .

Probier einfach mal, wenn du mal nen Kernel backst, die Option

Symbol: LEGACY_PTYS [=y]
│ Prompt: Legacy (BSD) PTY support
│ Defined at drivers/char/Kconfig:441
│ Location:
│ -> Device Drivers
│ -> Character devices

auf no - koennte Probleme bereiten ( uebrigens finde ich die Help-Seite in der Kernel-Config dazu besser ausgefuehrt, dabei hat sie nur 5 Saetze ).

Natuerlich muss ich zugeben, das ich denke das IPC oder aehnliches auch noch im Raum steht.

Vielleicht weiss ich einfach zu wenig...von allem...

Hoffentlich korrigiert mich einer wenn ich jetzt was falsches geschrieben habe.

greets
chab

deadeye · Beitrag von **deadeye** » 25.06.2006 01:41:40

Wow, Du willst für ne SSH-Verbindung nen Kernel neubauen? Das halte ich für ein wenig Overkill.

Allerdings hatte ich mir von $TERM mehr erwartet, als ein etwas unterschiedlicheres Ergebnis, auch verwundert mich, dass es bei zwei Debians auftritt.
Aber es muss irgendwo an den Einstellungen des OPs liegen, weil bei mir geht SSH zwischen Sarge und Etch wunderprächtig(auch aptitude, vorhin erst benutzt).

Ich bin der Meinung, PermitRootLogin spielt keine Rolle bei der Geschichte.

Ich tippe immer noch auf ncurses. Aber hab im Moment keine Idee, was man zur Ursachenforschung unternehmen könnte.

Du hast als User und als Root(auf dem Client) dasselbe Verhalten?

Gruß
deadeye

chabayo · Beitrag von **chabayo** » 25.06.2006 04:03:45

Vor lauter gehaeckel auf der Tastatur vorhin hatte ich noch einen ''gedanken'' vergessen zu erwaehnen...

Wer kann unterschiedliche Locales als Ursache ausschliessen ??

...und...

Vielleicht koennte er mal unter $TERM was anderes setzen, z.B. vt100 ??

deadeye · Beitrag von **deadeye** » 25.06.2006 13:12:15

chabayo hat geschrieben:Wer kann unterschiedliche Locales als Ursache ausschliessen ??

Daran hatte ich auch mal gedacht, zumal Etch ja nun (mehr oder weniger) auf UTF-8 läuft und Sarge wie immer auf ISO-8859-15. Aber bei mir geht es trotzdem.
Aber vielleicht hat der OP ja ganz andere Locales.

Daher mal ein

Code: Alles auswählen

set

auf dem Client und dem Server machen und in dann in auf [1] posten.

[1] http://nopaste.debianforum.de

Gruß
deadeye

tobb · Beitrag von **tobb** » 26.06.2006 15:08:24

Was ist denn der wichtige Teil von der ausgaben von set? Die Ausgabe ist zu groß für NoPaste.

deadeye · Beitrag von **deadeye** » 26.06.2006 15:13:51

COLORTERM
COLUMNS
LANG
LINES
TERM
SSH*

Hoffe ich habe nichts wichtiges vergessen.

Gruß
deadeye

tobb · Beitrag von **tobb** » 26.06.2006 15:22:57

set ist komischerweise auch ein Befehl der in eine neue Zeile springt und dann nichts mehr tut. Die Konsoel hängt dann wieder.
Ich habe die Ausgabe dann in eine Datei umgeleitet, deshalb hier:

Der Sarge PC der "fernbedient wird":
http://nopaste.debianforum.de/3519

Und hier die Ausgabe von meinem (enormer Größenunterschied):
http://nopaste.debianforum.de/3520