Netz - Rettung - Recht (Artikel mit Tag ssh)

Auswahl des SSH-Ports auf Servern

nospam@example.com (Thomas Hochstein) — Thu, 06 Sep 2018 05:50:00 +0000

Damit zwei Rechner über das Internet kommunizieren können, müssen sie ihre IP-Adressen kennen; will man einen bestimmten Dienst auf einem Rechner ansprechen, muss man auch den Port kennen, unter dem dieser Dienst angeboten wird. Damit das nicht zu einem Ratespiel gerät, gibt es für die meisten Dienste Standardports - der Webserver läuft auf Port 80 (kann aber auch mal auf Port 8080 oder anderswo lauschen), SMTP funktioniert über Port 25 (oder 465 oder 587), und SSH-Verbindungen werden standardgemäß auf Port 22 erwartet.

Dienste auf ungewohnte Ports zu verlegen macht meist nur wenig Sinn, weil der Rest der Welt damit nicht rechnet - wer seinen SMTP-Server auf Port 2525 laufen lässt, wird nicht allzuviel Mail erhalten. Beim SSH-Dienst kann das aber schon sinnvoll sein, weil SSH-Zugänge üblicherweise nicht öffentlich verfügbar sind, und den Berechtigten kann man neben dem Hostnamen, ihrer Benutzerkennung und ggf. dem Passwort dann auch den richtigen Port mitteilen.

Das erhöht natürlich nicht wirklich die Sicherheit gegen Angriffe, hatte aber über lange Jahre immerhin den Vorteil, das Logfile zu entlasten: statt Dutzender Meldungen täglich über unbefugte Zugriffsversuche auf Port 22, der routinemäßig gescannt wird, herrscht Ruhe, wenn der sshd eben auf Port 2022 lauscht. Für die notwendige Sicherheit sorgt dann die Beschränkung des Zugriffs auf per SSH-Key authentifizierte Nutzer und ggf. ein Dienst wie fail2ban, der nach mehreren Fehlversuchen die betreffende IP für einen beschränkten Zeitraum bereits auf Ebene der Hostfirewall blockt.

Über die Jahre funktioniert dieser “Trick” aber immer weniger. War 2004 dann noch Ruhe im Karton (bzw. Logfile), sind mir 2009 bzw. 2010 bereits vereinzelte Zugriffsversuche auf den an einem nicht standardisierten Port lauschenden SSH-Server aufgefallen. Mittlerweile erfolgen Dutzende dieser Zugriffe täglich.

Daher frage ich mich: lohnt es sich überhaupt noch, den sshd auf einen anderen Port zu verlegen, oder kann man es bei Port 22 belassen (und sich damit die gesonderte Konfiguration des Ports in allen verwendeten Programmen und Diensten sparen)?

Eine Antwort auf diese Frage hat - genau einen Tag, nachdem ich sie mir das erste Mal gestellt hatte - Felix bereits auf Twitter gegeben:

Ich möchte die Frage aber nochmals in die Runde stellen - welche Erfahrungen und Empfehlungen hat die werte Leserschaft?

Github: alte TLS-Versionen und SSH-Algorithmen deaktiviert

nospam@example.com (Thomas Hochstein) — Tue, 03 Apr 2018 04:40:00 +0000

Github hat am 22.02.2018 Änderungen an der HTTPS-und SSH-Konfiguration vorgenommen und ältere und weniger sichere Zugriffsmöglichkeiten deaktiviert. Das betrifft sowohl TLS 1.0 und TLS 1.1 als auch - für den SSH-Schlüsselaustauch - diffie-hellman-group1-sha1 und *diffie-hellman-group14-sha1. Wenn die verwendete Client-Software nicht mindestens TLS 1.2 bzw. einen anderen Schlüsselaustausch-Algorithmus beherrscht, muss man mithin aktiv werden.

Wer - wie ich - Git for Windows zusammen mit PLink aus dem Putty-Paket als SSH-Client verwendet, bekommt sonst möglicherweise - wenn er Putty länger nicht mehr geupdatet hat - beim git pull oder git push eine Meldung dieser Art zu sehen:

FATAL ERROR: Couldn't agree a key exchange algorithm (available: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521)

Natürlich (?) hatte ich die Ankündigungen über die Änderungen bei Github nicht präsent, vermutete aber etwas in der Art - und Google führte mich nach einiger Zeit zu einem Issue im Github-Desktop-Projekt. Und siehe da - Putty kann erst ab Version 0.68 (21.02.2017) elliptische Kurven:

Support for elliptic-curve cryptography (the NIST curves and 25519), for host keys, user authentication keys, and key exchange.

Ein putty-Update später flutschte dann auch wieder alles.

(Ab dieser Version wird allerdings ggf. eine 64bit-Version von Putty installiert, die dann unter Windows nicht in C:\Program Files (x86) landet, sondern in C:\Program Files, so dass ggf. die Umgebungsvariable GIT_SSH angepasst werden muss.)

Tips und Tricks für den Umgang mit git

nospam@example.com (Thomas Hochstein) — Wed, 12 Jan 2011 16:30:00 +0000

Bei meiner Arbeit mit git stehe ich immer wieder vor der Frage, ob man dieses oder jenes damit nicht einfach machen können müßte. Meistens lautet die Antwort auf diese Frage "ja", aber teilweise muß man schon etwas googeln, um diese Antwort zu finden. Daher möchte ich ab und an kleine ergoogelte Wissensschnippsel mit der Leserschaft teilen; vielleicht steht ja noch einmal jemand anderes vor demelben Problem (und überdies sind deutschsprachige Informationen zu git nicht so wirklich umfänglich vorhanden).

Git über SSH und mehrere SSH-Keys pro Host

Mehr eine allgemeine SSH-Frage, aber da sie sich mir im Zusammenhang mit git gestellt hat …

Ein beliebter Zugriffsweg auf Git-Repositories ist der über SSH, insbesondere, wenn es auch um einen schreibenden Zugang geht und man diesen authentifizieren will. Zu diesem Zweck kann man sich den passenden SSH-Schlüssel für den Zugriff auf das Git-Repository über die SSH-Konfiguration definieren, bspw. durch einen Eintrag in ~/.ssh/config wie den folgenden:

Host git.example.org
Port 2022
IdentityFile ~/.ssh/gitkey

SSH-Zugriffe auf den Server "git.example.org" erfolgen also auf Port 2022 (statt 22) und unter Verwendung des Schlüssels "gitkey". Der Git-Zugriff via SSH berücksichtigt diese Einstellungen dann automatisch.

Was aber tun, wenn man von demselben Client mit mehreren verschiedenen SSH-Schlüsseln auf denselben Server zugreifen muß, wie es insbesondere bei der Verwendung von Tools wie gitosis auf der Serverseite vorkommen kann? Dieselbe Frage stellt sich natürlich, wenn man sich neben dem Zugriff auf ein Git-Repository auch ganz normal per SSH auf dem Server einloggen können will. Auf die obige Art und Weise läßt sich nur ein Key für den Zugriff auf "git.example.org" vordefinieren - und will man wirklich immer einen abweichenden Schlüssel per Option angeben? Eine Lösung wäre die Vergabe von weiteren CNAMEs im DNS für git.example.org, aber das skaliert auf die Dauer auch nicht.

Die einfachste Lösung dafür bieten Aliase direkt in der SSH-Konfiguration, wie das Git-Wiki empfiehlt:

Host private.example.com
    User myname
    Hostname git.example.com
    IdentityFile ~/.ssh/private-identity
Host public.example.com
    User groupname
    Hostname git.example.com
    IdentityFile ~/.ssh/public-identity

Auf diese Art und Weise kann man denselben Server mit zwei verschiedenen Konfigurationen ansprechen.

Übernahme einer einzelnen Datei aus einem anderen Branch

Alle Änderungen aus einem anderen Entwicklungszweig zu übernehmen ist einfach und geht per merge; nur bestimmte Änderungen (commits) zu übernehmen funktioniert via cherry-pick. (Warum auch immer das Rosinenpicken der Deutschen dem Angelsachsen ein Picken nach Kirschen ist …) Aber wie kann man eine bestimmte Datei - also alle Änderungen, aber nur die in einer bestimmten Datei - aus einem anderen Branch übernehmen?

Zu dieser Frage hat Jason Rudolph die passende Antwort: das geht mit git-checkout, und zwar in der Form git checkout $branch $path. Nehmen wir an, ich möchte die Fassung der Datei "README" aus dem Branch "test" in meinen Branch "master" übernehmen, aber eben nur diese Datei in genau dem Zustand, den sie im "test"-Branch hat. Das geht dann folgendermaßen:

git checkout master
git checkout test README
git commit -m 'Imported README from test branch'

Genauso funktioniert das natürlich mit mehreren Dateien:

git checkout test README doc/explanation.txt doc/TODO

Voilà. Soviel für heute.