Hotels und (zu bezahlendes) WLAN
Inzwischen war ich in so einigen Hotels unterwegs und immer wieder trifft man auf WLANs, bei denen man fuer die Benutzung zahlen soll. Nach genauerem Blick haben sich die Hersteller oft mehr auf Corporate Design Fragen konzentriert als auf die Sicherheit. Deswegen hier einige Erfahrungen:
Grundsaetzlich ist es sinnvoll, wenn man einen Server hat auf dem man z.B. einen SSH-Server auf alternativen Ports laufen lassen kann. Ich empfehle explizit neben 22 auch 53, 80, 443, 3128 und 8080. Daneben gibt es einen sehr simplen und einfachen Perl-HTTP-Proxy, ich glaube ich hatte den mal aus irgendeinem Linux Magazin:
#!/usr/bin/perl use HTTP::Proxy; my $proxy = HTTP::Proxy->new( port => 3129); $proxy->start;
der die folgende Abhaengigkeit benoetigt:
sudo aptitude install libhttp-proxy-perl
Zu guter letzt hilft natuerlich immer, wenn man weiss, wie man mit SSH externe Ports lokal bindet. Damit kann man z.B. auf dem externen Server den HTTP-Proxy starten, den Port lokal hertunneln, und dann diesen Proxy z.B. in seinem Firefox eintragen... Ein Eintrag in einer ~/.ssh/config koennte wie folgt aussehen:
Host hotelhelper HostName 1.2.3.4 User user Port 443 LocalForward 3129 localhost:3129
Dann kanns losgehen:
- Testen welche Ports nach aussen offen sind. Oft wird nur Port 80 und 443 beschraenkt, der Rest ist offen. Man kann sich dann ohne Probleme ueber andere Ports verbinden.
- Gucken ob im Netz nicht irgendwo ein Proxy laeuft ueber den man raustunneln kann. Hier kann einem
sudo aptitude install nmap corkskrew
helfen
- Gucken ob DNS-Anfragen richtig aufgeloest werden. Evtl. werden _nur_ http Pakete gefiltert werden auf den offenen Ports, evtl. geht ja SSH auf Port 53 oder 443 raus...
- Gucken ob klicks auf Portalseiten nicht weitere Dinge oeffnen. In einem Beispiel konnte ich mit einem Klick auf "Hier klicken um mit VISA zu Zahlen" und der Weiterleitung auf die Seite eines externen Zahlungsanbieters den Proxy dazu bewegen fuer ein Zeitfenster von 30min SSH auf den bekannten Ports zu oeffnen.
Command Line, SSH and webproxy
Ich hatte ja gerade erst darueber geschrieben wie man apt hinter einem proxy benutzen kann, hier noch 2-3 Kleinigkeiten hinzugefuegt.
Als erstes ist es gut, auch die env variable http_proxy="" zu setzen, damit Programme wie w3m funktionieren:
export http_proxy="http://1.2.3.4:8080"
als zweites ist es natuerlich interessant auch per SSH rauszukommen. Zum Glueck gibt es dafuer in den Ubuntu repositories
aptitude install corkscrew
einem "tunnel TCP connections through HTTP proxies" Programm. Dafuer die folgenden beiden Zeilen in die ~/.ssh/config hinzufuegen
Host * ProxyCommand /usr/bin/corkscrew 1.2.3.4 8080 %h %p
wenn es eine Fehlermeldung geben sollte wie:
Proxy could not open connnection to example.net: Proxy Error ( The specified Secure Sockets Layer (SSL) port is not allowed. ISA Server is not configured to allow SSL requests from this port. Most Web browsers use port 443 for SSL requests. )
einfach mal den SSH-Server auch auf Port 443 lauschen lassen (echo "Port 443 >> /etc/ssh/sshd_config; /etc/init.d/sshd restart) und dann auf dem Port verbinden.
SSH ProxyCommand
Mal wieder SSH ... Wie nervig ist es immer wegen Firewalls und Serverhopping erst auf den einen Server gehen zu muessen, bevor man sich auf dem gewuenschten einloggen kann. Die Loesung lautet ProxyCommand. Ein Beispiel fuer eine .ssh/config:
Host * Compression yes CompressionLevel 9 Host bar User username Port 22 ProxyCommand ssh foo nc %h %p Ciphers arcfour ClearAllForwardings yes Host foo HostName 192.168.1.1 User username Port 22
Wenn man nun noch eine Key-Authentifizierung hat, (und auf foo in der .ssh/config auch bar definiert ist) kann man sich Schwupps mit
ssh barauf dem gewuenschten Rechner einloggen ohne laestiges zwischendrin
Ciphers und ClearAllForwardings sind Performancesachen, denn die eine Verbindung muss nicht soo stark verschluesselt sein, wenn es der Tunnel bereits ist.
SSH – Keys und Agent
SSH gehoert fuer mich zum taeglich Brot. Gefuehlte 1.000.000 mal taeglich baue ich Verbindungen zu irgendwelchen Servern auf, mache dort etwas, baue die Verbindung wieder ab usw... Etwas was mir mein Leben dabei sehr stark erleichtert ist die ~/.ssh/config in der ich fuer die entsprechenden Server die Voreinstellungen hinterlegt habe. Vor vielen Jahren hatte ich darueber bereits hier auf dem Blog geschrieben.
Authentifizierung ueber Keys ist ein weiteres Thema das das Leben sehr viel erleichtern kann. Deswegen hier kurz was dazu geschrieben. Als erstes benoetigt man einen Key. Der wird mit dem folgenden Befehl erzeugt:
ssh-keygen -t dsa
Dabei wird zur Eingabe eines Passworts aufgefordert, wenn man nicht sehr triftige Gruende dagegen hat sollte man das auch tun. Als zweites muss der public Key auf den betreffenden Server kopiert werden, z.B.:
scp ~/.ssh/id_dsa.pub username@example.net:/home/username/.ssh/authorized_keys2
Nun kann ich mich schon mit
ssh username@example.com
ueber den Key (mit dem Passwort des Keys) authentifizieren. Noch einfacher wird es jedoch, wenn man diese Identity dem SSH-Agent mitteilt. Das passiert mit dem Befehl:
ssh-addNach der Eingabe des Passworts fuer den Key uebernimmt der Agent alles weitere fuer einen. Man kann sich nun mit dem Key ohne Angabe des Passworts an dem Server anmelden, bis der Agent neu gestartet wird.
Natuerlich kann man auch mehr als einen Key haben, z.B. um private und dienstliche Sachen voneinander zu trennen:
ssh-keygen -t dsa .ssh/work ssh-add .ssh/work
Die aktiven Identitys kann man sich uebrigens mit
ssh-add -l
anzeigen lassen
