Skip to content

Automatisch ein screen nach einem SSH-Login starten

Wenn ich mich auf einem Server per SSH einlogge, starte ich in der Regel direkt die Software screen oder tmux. Dies sind so genannte Multiplexer. Sie erlauben es mir mehrere “Fenster” zu öffnen und auch wenn die Verbindung weg ist, werden die Befehle weiter abgearbeitet.

Im Normalfall gebe ich also zuerst ssh server ein und wenn ich dann auf dem Server eingeloggt bin, gebe ich screen -R oder tmux a ein. Viel schöner wäre es nun, wenn der letzte Schritt automatisiert geschehen würde. Man mag es kaum glauben, aber OpenSSH ist dazu in der Lage. :-)

Hier hilft eine kleine Einstellung in der Konfigurationsdatei. Diese liegt normalerweise im Verzeichnis ~/.ssh und heißt config. Ein Eintrag könnte so aussehen:

Host server
  HostName server.example.com
  IdentityFile ~/.ssh/mein-geheimer-schluessel
  User jens

Mit der Eingabe ssh server verbindet sich SSH zu dem Rechner unter der Adresse server.example.com, nutzt den angegebenen Schlüssel und loggt sich als Nutzer jens ein. Mit den Optionen RemoteCommand und RequestTTY kann ich nun den gewünschten Effekt erzielen:

Host server
  HostName server.example.com
  IdentityFile ~/.ssh/mein-geheimer-schluessel
  User jens
  RemoteCommand screen -RD #oder tmux a
  RequestTTY yes

Nun führt OpenSSH den gewünschten Befehl aus und ich lande sofort in meiner gewünschten Sitzung.

Dies ist natürlich nur eine Kleinigkeit. Aber es nimmt mir einen kleinen Schritt ab und fühlt sich so bequemer an. Vielleicht probiert ihr es auch mal aus und erzählt von euren Erfahrungen.

OSINT: SSH und Tor Hidden Services aufdecken

Mit der Anonymität ist das so eine Sache. Passt man nicht richtig auf oder macht etwas falsch, so kann der ganze Aufwand für die Katz sein. Ein solches Beispiel machte auf Twitter die Runde.

Tor Hidden Services sind eine Möglichkeit, um anonym Informationen anzubieten. Das heißt, der Leser soll herausfinden können, wer diese Informationen anbietet. Neben Webseiten lassen sich die Hidden Services für verschiedene Zwecke einsetzen. Ich nutze die beispielsweise sehr gern, um mich über SSH mit Servern zu verbinden. Dies machen offensichtlich auch andere Leute gern.

Auf der Seite von Tor müssen nur zwei Zeilen geändert werden:

HiddenServiceDir /var/lib/tor/ssh
HiddenServicePort 22 127.0.0.1:22

Nach einem Restart von Tor liegt in /var/lib/tor/ssh/hostname der Name des Hidden Service’. Unter dieser Adresse steht der Dienst zur Verfügung, solange Tor auch läuft.

Jetzt könnte eigentlich alles gut sein. Jedoch spätestens seit zmap und ähnliches Werkzeugen ist das Durchprobieren aller IPv4-Adressen sehr einfach geworden. Ein findiger Angreifer verbindet sich einfach zu allen Adressen auf Port 22 und sammelt den Fingerprint ein, falls sich einer findet. So lassen sich beispielsweise bei Shodan Fingerprints finden.

Wenn ihr nun eine Onion-Adresse seht, hinter der ein SSH-Dienst steckt, verbindet ihr euch mit dem und sucht den Fingerprint in eurer Datenbank. Findet ihr eine Übereinstimmung, kennt ihr die reale IP-Adresse des Dienstes.

Doch was lässt sich dagegen tun? Der einfachste Weg ist, den SSH-Dienst gar nicht mehr öffentlich anzubieten. Mit der Zeile ListenAddress 127.0.0.1 ist der Dienst nur noch lokal und eben als Tor Hidden Service erreichbar. Dies hat den Vorteil, dass auch die nervigen Loginversuche durch Scriptkiddies aufhören. Wenn der Dienst vorher schon als Hidden Service lief, solltet ihr darauf achten, dass ihr die beiden Dateien in dem Verzeichnis /var/lib/tor/ssh/ löscht. Tor wird dann einen neuen Hostnamen mit neuem Fingerprint erzeugen. Damit ist der Dienst wieder nicht mit diesen einfachen Mitteln aufzufinden.

Fingerprints von SSL-Seiten prüfen

Das Desaster um die niederländische Zertifizierungsstelle DigiNotar zieht derzeit immer noch seine Kreise. Mir scheint es noch zu früh, um hier etwas dazu zu schreiben. Vielmehr will ich ein paar Worte verlieren, wie ich „meine eigene CA betreibe“. Denn schon seit längerem vertraue ich nicht, den von den Browsern mitgelieferten Zertifizierungsstellen (CA). Zumeist lösche ich alle und gebe dann einzeln Vertrauen.

Der beste Weg, um einem SSL-Zertifikat zu vertrauen, wäre, sich bei dem Betreiber zu melden und über einen sicheren Kanal den Fingerprint des Zertifikats zu klären. Mein Browser zeigt mit für die Seite Wikipedia-SSL-Seite den Fingerprint (SHA-1) BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E an. Wenn ich bei der Wikipedia anrufe und diese mir denselben nennen, so habe ich das korrekte Zertifikat. Dabei nehme ich natürlich an, dass das Telefon ein sicherer Weg zum Austausch der Informationen ist. Aber beispielsweise druckt die lokale Sparkasse eben diesen Fingerprint auf ihre Dokumente. Damit kann ich das als Kunde leicht verifizieren.

Wie das Beispiel Wikipedia aber schon zeigt, ergibt sich da ein Problem.Woher bekomme ich den Fingerprint? Muss ich bei Jimmy Wales direkt anrufen oder gar nach FloridaKalifornien¹ reisen? Hier kam nun meine Idee ins Spiel.

Ich habe auf diversen Servern einen Zugang, d.h. ich kann mich von der Ferne einloggen und dann dort arbeiten. Die Rechner stehen in verschiedenen Netzen und zum Teil auf verschiedenen Kontinenten. Nun logge ich mich auf den Servern ein, lade das Zertifikat herunter und lasse mir den Fingerprint anzeigen. Wenn dieser auf allen Rechner gleich ist, dann gehe ich davon aus, dass ich das korrekte Zertifikat angezeigt bekomme. In dem Fall akzeptiere ich das und vertraue dem. Sollten die Fingerprints abweichen, dann akzeptiere ich das nicht und recherchiere dem in der Regel ein wenig hinterher.

Jörg Sommer hat das nun ein wenig automatisiert und ein zsh-Skript (Quelltext weiter unten) geschrieben. Das wird folgendermaßen aufgerufen:

ssl-fp-check [-l] sslsi.te[:port] ssh1 [ssh2] [ssh3] ...

Dabei ist sslsi.te die Webseite, die geprüft werden soll. Ohne die Angabe eines Ports verwendet das Skript standardmäßig 443. Danach wird eine oder mehrere SSH-Verbindungen angegeben. Das Skript wird nun versuchen, sich überall einzuloggen und gibt dann den Fingerprint aus. Für den Fall, dass es auf dem Zielsystem kein OpenSSL gibt, existiert die Option -l. Dabei wird dann ein Tunnel gebaut und das lokale installierte OpenSSL verwendet.

Also für Wikimedia habe ich folgendes eingeben:

ssl-fp-check secure.wikimedia.org a b c d
a: SHA1 Fingerprint=BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E
b: SHA1 Fingerprint=BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E
c: SHA1 Fingerprint=BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E
d: SHA1 Fingerprint=BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E

Die SSH-Server a, b, c und d gaben also denselben Fingerprint aus. Also würde ich dem ganzen doch vertrauen. :-)

Ich werde das Skript jetzt wahrscheinlich immer verwenden. Es macht das Leben doch deutlich einfacher.

Continue reading "Fingerprints von SSL-Seiten prüfen"

Schreibschwäche am Abend

Das ist wohl ein Zeichen, dass ich langsam ins Bett gehen sollte:

jens@panse:~/ > ssh 192.1682.2.4
ssh: 192.1682.2.4: Name or service not known
jens@panse:~/ > ssh 192.1682.2.14
ssh: 192.1682.2.14: Name or service not known
jens@panse:~/ > ssh 192.1682.2.24
ssh: 192.1682.2.24: Name or service not known
jens@panse:~/ > ssh 192.168.2.24
Linux kernel 2.6.27-15 #1 SMP Tue Sep 14 16:22:17 UTC 2009 x86_64 GNU/Linux [...]
cronjob