Dinge, die die Welt nicht braucht

In einer perfekten Welt wären Verbindungsprobleme nicht existent und Netzwerke würden immer funktionieren. Leider leben wir nicht in einer solchen und so muss man mit den Auswirkungen dieser Fehler klar kommen. Unterbricht eine SSH Verbindung weil die Gegenstelle nicht mehr reagiert (und auch keine ICMP Message schickt, die anzeigt, dass die Verbindung unterbrochen ist), so wartet der Client unter Umständen eine kleine Ewigkeit bis der Timeout zuschlägt und das Terminal wieder freigibt. Die übliche Abbruchmethode für Konsolenprogramme via CTRL+C funktioniert nicht, da der SSH Client dieses Tastenkombination einfach an den Server durchleitet. Das gleiche gilt für Telnet, dass auch oft benutzt wird um andere Dienste wie zum Beispiel HTTP oder POP3 zu testen.

Das Terminal zu schliessen oder den Prozess zu töten kann natürlich keine Lösung sein, zumal die Entwickler dieser Clients bereits an dieses Problem gedacht haben. Sowohl für SSH als auch für Telnet existiert ein so genannter Escape Character, um aus der Session zu entkommen und Zugriff auf das Programm zu erhalten.

Dieses Zeichen ist für SSH in der Voreinstellung die Tilde (~). Auf einer deutschen Tastatur ist sie über AltGr+ zu erreichen. Natürlich kann auch ein anderes Zeichen definiert werden. Die SSH Manpage sagt dazu:

-e escape_char
Sets the escape character for sessions with a pty (default: `~'). The
escape character is only recognized at the beginning of a line. The
escape character followed by a dot (`.') closes the connection; followed
by control-Z suspends the connection; and followed by itself sends the
escape character once. Setting the character to ``none'' disables any
escapes and makes the session fully transparent.

Folgende Befehle sind dann laut Manpage möglich

The supported escapes (assuming the default `~') are:

~. Disconnect.

~^Z Background ssh.

~# List forwarded connections.

~& Background ssh at logout when waiting for forwarded connection / X11 ses-
sions to terminate.

~? Display a list of escape characters.

~B Send a BREAK to the remote system (only useful for SSH protocol version 2
and if the peer supports it).

~C Open command line. Currently this allows the addition of port forward-
ings using the -L and -R options (see above). It also allows the cancel-
lation of existing remote port-forwardings using -KR hostport. !command
allows the user to execute a local command if the PermitLocalCommand
option is enabled in ssh_config(5). Basic help is available, using the
-h option.

~R Request rekeying of the connection (only useful for SSH protocol version
2 and if the peer supports it).

Ein Zirkumflex (^) steht übrigens für die Taste Ctrl (Strg). Funktionieren diese Kombinationen nicht, so ist auf dem Client PC vielleicht deadkeys als Tastaturlayoutvariante eingestellt. In diesem Fall muss die Tilde zwei mal gedrückt werden um diese Kommandos ausführen zu können. Soll die Tilde auf der Shell der Gegenseite ankommen ist sogar ein viermaliger Druck notwendig.

Telnet zeigt das Escape Zeichen beim Verbindungsauf an:

$ telnet www.google.de 80
Trying 72.14.221.104...
Connected to www.google.de.
Escape character is '^]'.

Dieses eckige Klammer (]) ist auf Tastaturen mit englischem Layout leicht zu erreichen und es muss tatsächlich nur Ctrl (Strg) und die ]-Taste gedrückt werden. Beim deutschen Layout wird zusätzlich noch AltGr gebraucht, wodurch die Kombination fast schon zum Affengriff wird. Dort muss Strg+AltGr+9 gedrückt werden, damit man in den Kommandomodus von telnet wechselt. Natürlich lässt sich auch dieses Zeichen ändern:

-e escapechar
Sets the initial telnet escape character to escapechar. If escapechar is
omitted, then there will be no escape character.

Mit einem einfachen Druck auf Return wechselt telnet vom Prompt zurück in die Verbindung.

Sorry. Aber ich muss jetzt meinem Ärger mal eben Luft machen. Ich benutze im Büro Debian, weil eigentlich alle Linux Büchsen hier damit laufen. Bei dieser Distribution sind in der Datei /etc/apt/sources.list URIs eingetragen, von denen sich das System Paketlisten besorgen kann (vergleichbar mit den RSYNC mirrors bei Gentoo). Dort sind bei mir sowohl einige HTTP als auch FTP Sourcen eingetragen. Das man bei Debian immer zig Einträge in dieser Datei braucht, damit man seine Software zusammenbekommt (mplayer, acroread, etc.), empfinde ich zwar als ziemlich störend, aber es hat immerhin einen nachvollziehbaren Grund (Lizenzgeraffel, falls sich jemand dafür intressiert).

Das Netz hier ist ziemlich dicht, nach außen geht es nur über den HTTP oder FTP Proxy. Das ganze lässt sich auch im Konfigurationsfile (/etc/apt/apt.conf) das Paketmanagement Frontends apt einstellen:

Acquire::ftp
{
Proxy "ftp://foobar:2121";
ProxyLogin
{
"USER $(SITE_USER)@$(SITE)";
"PASS $(SITE_PASS)";
};
};
Acquire::http::Proxy "http://barfoo:8080";

Dann aber wurde der FTP Proxy im Zuge einer Umstellung abgeschaltet. Glücklicherweise ist FTP ins Internet damit noch nicht gekappt, denn der HTTP Proxy beherrscht auch dieses Protokoll. Die FTP-in-HTTP-Verpackung sieht dann zum Beispiel in etwa so aus:

GET ftp://ftp.de.debian.org HTTP/1.1
...

Diese Umstellung sollte kein Problem darstellen, da der entsprechenden Konfigurationszeile das Zugriffsschema voransteht (http:// oder ftp://). Also war ftp://foobar:2121 einfach durch http://barfoo:8080 zu ersetzen. Der Erfolg blieb leider aus und es hagelte nur Connection Timeouts. An dieser Stelle ist der erste Gedanke natürlich: was passiert da auf dem Netz? Ethereal zeigt dann, dass apt offentlich versucht FTP mit dem HTTP Proxy zu sprechen. Klarer Fall: da hab ich etwas falsch konfiguriert. Nach mehrmaliger Prüfung war aber beim besten Willen kein Fehler zu finden. Alle Quellen im Netz hatten es auch so eingestellt. Fast vom Stuhl gefallen bin ich, als ich folgenden Abschnitt in man sources.list lesen konnte.

It is possible to proxy FTP over HTTP by setting the ftp_proxy environment variable to a http url - see the discussion of the http method above for syntax. You cannot set this in the configuration file and it is not recommended to use FTP over HTTP due to its low efficiency.

Hallo? Geht's noch ein bischen schizophrener? Wenn etwas in einer Environment Variable gesetzt ist funktioniert es. Im applikationseigenen Konfigurationsfile wird nicht angenommen. Allein das ist schon krank, aber es geht ja noch weiter. Die Proxyurl, vor der eindeutig http:// steht, dann ohne jegliche Fehlermeldung zu etwas anderem zu verwursten und dann zu behaupten der Server wäre kaputt setzt dem ganzen die Krone auf. Eine leidlich vollständige Dokumentation entbindet nicht davon einigermaßen sinnvolle Fehlermeldungen auszugeben.

Danke. Jetzt geht's mir besser.

Nachtrag
Natürlich will ich nicht nur meckern, sondern auch eine konkrete Problemlösung anbieten. Systemweite Environment Variablen werden bei Debian normalerweise in /etc/environment gesetzt. Allerdings werden diese offensichtlich nur bei einem Login und nicht bei einem Benutzerwechsel zu root ausgelesen. Daher sollte man den Proxy zusätzlich in /root/.profile setzen.

export http_proxy="http://barfoo:8080"
export ftp_proxy="http://barfoo:8080"