Rechner via Open SSH verbinden

Rückblick auf Telnet

Zunächst ein Blick zurück. In den Anfängen (1970er) konnte man sich mit dem Client/Server-Netzwerkprotokoll Telnet einen bidirektionalen, textbasierten Zugriff auf einen fernen Rechner via TCP/IP (Transmission Control Protocol/Internet Protocol) ermöglichen. Diese Fernsitzugen funktionieren mit einer Eingabeaufforderung über die man vom Client (Terminal, Fernschreiber, etc.) zugreifen konnte, als säße man direkt am fernen Rechner (Server, Großrechner etc.). Die Authentifizierung erfolgt im Dialog mit Benutzernamen und Password mit in etwa folgendem Syntax zur Eröffnung einer Sitzung in der Regel über Port 23:

telnet 1.2.3.4  

oder anfangs im Vorgänger des Internet (ARPNET) über den Rechnernamen, die in einer simplen Datei hosts verwaltet wurde, später (1980er) über’s Internet mit IP-Adressen oder die Namensauflösung DNS (Domain Name System)

telnet mein.ferner-rechner.de    

Da Telnet die Daten – auch Usernamen und Password – im Klartext überträgt ist es extrem unsicher und heute in öffentlich zugänglichen Netzen obsolet. Moderne Systeme unterstützen verschlüsselte Übertragungen via SSH oder PuTTy etc.

Quellen: ComputerWeekly.de, Wiki Ubuntu Users

SSH Secure Shell

In den 1980er enstand SSH. Die SSH-Vorteile sind klar und machen den Erfolg aus. a) die Gegenstelle kann via eines Schlüssels authentifiziert werden. Das minimiert das Risiko einer Fehlverbindung. b) die Datenübertragung ist verschlüsselt. Dadurch kein Mithören durch Cyper-Kriminelle, Roboter (bösartige Chatbots), Spione oder andere Unbefugte. c) Datenintegrität, das verhindert oder minimiert zumindest das Risiko einer Manipulation der übertragenen Daten.

Zunächst benötigt man für SSH die erforderlichen Schlüssel PubKey und PrivKey. Wie man diese erstellt und aufbewahrt sowie grundsätzlich verteilt, hab ich ja schon im vorangegangenen Beitrag Public & Privat Key beschrieben.

Im Server werden die Weichen für die Sicherheit gestellt oder besser formuliert bestimmte sicherheitsrelevante Einstellungen und Festlegungen getroffen. Da gibt es mehrere kritische Punkte von denen ich einige ausgewählte Aspekte und Ansätze hier diskutieren möchte und ich Euch meine jeweilige Best Prachtices zeige.

root

Fangen wir mit root, dem absoluten Chef im Ring an. Der User root hat uneingeschränkte Zugriffsrechte auf das gesamte System und kann alle administrativen Aufgaben ausführen. Deshalb ist er auch für Angreifer das Hauptziel. Wird er kompromittiert ist der Server quasi verloren und der Unbefugte kann allerlei Schlimmes und Illegales anstellen.

Servernamen respektive die IP-Adressen lassen sich in öffentliche Netzten durch einen Angreifer sehr leicht ermitteln. Auch der Benutzername root ist bei Linux-Systemen bekannt. Bleibt noch das Password. Sei es auch noch so komplex, es könnte erraten, erschlichen, erpresst oder sonstwie in die Hände einer unbefugten Person geraten.

Nun es gibt verschiedene Ansätze das Einloggen eines unbefugten root via client möglichst zu verhindern. Mit einen der besten Lösungsansätze finde ich: Der root hat gar kein Password und er darf sich auch gar nicht über ssh einloggen. In der Praxis kann das so funktionieren:

• Ich begleite die ferne Server-Installation von der Konsole meines Hosters (zB mein Konto bei Hetzner) und parallel von meinem Client (zB mein persönliches MacBook), das auch das Schlüsselpaar mit PubKey & PrivKey an Board hat

• schon während der geeigneten image-basierten Installation des virtuellen Servers wird root bereits von Anfang an ohne Password eingerichtet.

• direkt während der Installation vom Image (zB ubuntu) wird mein öffentlicher PubKey zum Beispiel von GitHub bezogen und direkt im richtigen Verzeichnis quasi automatisch installiert:/root/.ssh/authorized_keys
• in einem späteren Schritt während der Grundeinrichtung wird die Möglichkeit des Einloggens dem root verboten. Wie und wo das geht zeige ich noch weiter unten in diesem Beitrag.

Was erreichen wir damit:

a) ein nicht vorhandenes Password kann auch nicht kompromittiert werden und somit auch nicht in falsche Hände geraten.

b) das Einloggen des root ist gar nicht mehr möglich.

c) ich verwende für mich selbst einen unüblichen (ggf. komplexen) Benutzernamen – vorübergehend mit Password – Dabei achte ich darauf, dass ich mich nicht vom Server (zB durch eine zweite parallele Sitzung) aussperre, bevor ich auch für mich später den Login mit Password verbiete.

Ich editiere die sshd_config und setze bzw. prüfe in der SSH-Konfiguration die folgenden Optionen:

sudo nano /etc/ssh/sshd_config
PermitRootLogin without-password

oder alternativ statt without-password prohibit-password

Zwischendurch prüfe ich, ob ich mich mit meinem persönlichen Benutzernamen und meinem PrivKey anmelden kann. Dabei halte ich eine zweite Sitzung offen, um mich bei einem Tipp-Fehler etc. nicht auszusperren. Funktioniert die Anmeldung mit PrivKey (Client) und hinterlegtem PubKey (Server) editiere ich die sshd_config zu Ende, in dem ich das Login für alle User mit Password verbiete.

PermitRootLogin prohibit-password
PubkeyAuthentication yes
PasswordAuthentication no

Stelle sicher, dass das Verzeichnis /root/.ssh auf 700 und die Datei authorized_keys auf 600 gesetzt sind sowie der Eigentümer (owner) jeweils root ist.

Dann starte ich den SSH-Dienst neu und teste, ob ich mich mit meinem Benutzernamen nun ohne Password nur mit dem Schlüsselpaar im Hintergrund automatisch anmelden kann und eine Terminalsitzung bekomme.

systemctl reload sshd

sudo Berechtigung

Der Befehl sudo (“superuser do”) wird auf Unix- und Linux-Systemen verwendet, um bestimmte Kommandos mit administrativen (Root-)Rechten auszuführen – und zwar ohne dass das Root-Passwort bekannt oder geteilt werden muss. Mit sudo können Benutzer gezielt und kontrolliert für einzelne administrative Aufgaben autorisiert werden, ohne vollständigen Root-Zugang zu erhalten. Die Rechte werden über die sogenannte sudoers-Datei festgelegt und sind genau nachvollziehbar.

Typische Anwendung: Ein einzelner administrativer Befehl wird mit

sudo <befehl>

ausgeführt. Beispiele:

sudo apt updatesudo systemctl restart nginx

Vorteile von sudo gegenüber su

• Keine Weitergabe des Root-Passworts nötig
• Feingranulare Rechtevergabe möglich
• Bessere Nachverfolgbarkeit durch Einträge im sudo-Log

Quelle: wiki.ubuntuusers

sudo su –

In Einzelsystemen kann man statt su (klassische root Shell mit root Password) den Befehl

sudo su -

benutzen, was eine neue login Shell als root. Vorteile sind

• zum Aktivieren reicht das Password des Users, das root Password wird nicht benötigt
• auch hier ist somit keine Weitergabe des root Passwords nötig
• der Wechsel wird protokolliert
• Rechte werden in der zentralen /etc/sudoers verwaltet

Die häufige Nutzung von Root-Shells birgt erhebliche Risiken, da sämtliche Befehle mit uneingeschränkten Systemrechten ausgeführt werden und alle Schutzmechanismen umgangen werden können.

Best Practices

• Nach Möglichkeit sollten administrative Aufgaben immer gezielt mit sudo für einzelne Kommandos ausgeführt werden.

• Eine dauerhafte Root-Shell sollte nur ausnahmsweise und sehr bewusst genutzt werden, um die Angriffsfläche und das Fehlerpotenzial zu minimieren.

• Die Nutzung von Root-Shells sollte immer so restriktiv wie möglich erfolgen, um sowohl das System als auch sensible Daten zu schützen.

Aufbau einer SSH Sitzung

Der User OttoMuster möchte eine Sitzung zum Server unser.ferner-server.de aufbauen. Auf dem fernen Server und dem lokalen Client sind die Schlüssel hinterlegt und die Einrichtungen wie vorstehend beschrieben erfolgt. Otto nutzt dafür in diesem Beispiel die Terminal-APP seines MacBook:

ottomuster@MacBook-Pro-von-Otto ~ % 
ottomuster@MacBook-Pro-von-Otto ~ % SSH ottomuster@unser.ferner-server.de
ottomuster@unser.server:~$

Zeile 1: promt des MacBook
Zeile 2: am Promt des MacBook gibt Otto den SSH Befehl zum Aufbau der Sitzung ein
Zeile 3: der ferne Server meldet sich mit seinem promt im Homeverzeichnis von otto

Solange der private Schlüssel PrivKey nicht in die Hände eine unbefugter Nutzers fällt, wir dieser sich nicht einloggen können.

Zusammenfassung

Open SSH in Verbindung mit einem Schlüsselpaar und ohne Passwordeingabe können bei richtiger Konfiguration und Handhabung die Systemsicherheit und Rückverfolgbarkeit deutlich erhöhen sowie die Auswirkung von Admin-Fehlern reduzieren. Darüber hinaus werden Angriffsflächen reduziert und die Verfolgbarkeit von Angriffen und Fehlern verbessert.

Zwei Rechner via Schlüsselpaar und ohne Passwordeingabe sicher verbinden

Eine Verbindung via SSH zwischen zwei jeweils fernen Servern ist der vorstehend beschriebenen SSH Server Client Verbindung sehr ähnlich.

In meiner quick and dirty Best Practies liege ich dazu auf beiden Servern zwei identische User (gleiche UID, gleiche GID) für den Datenaustausch an und platziere in deren jeweiligem Home Verzeichnis unter dem versteckten Ordner .ssh, die benötigten Zertifikate. Wie das geht habe ich in den vorangegangenen Beiträgen Public & Privat Key und Owner UID & Group GID auf zwei Servern identisch im Detail beschrieben.

Mithilfe der SSH Schlüsselpaare kann ich nun, – ohne, dass ich ein Passwort eingeben muss, – sichere Verbindung von Server zu Server aufbauen und zum Beispiel Kopieraktion automatisiert (via Script) durchführen. Das kann dann im Grundsatz für eine Synchronisierung in etwa so oder so ähnlich aussehen:

Beispiel: Um eine Datei vom Server 2 aus einem bestimmten Verzeichnispfad (Verzeichnispfad 2) auf Server 1 in einen Zielverzeichnispfad zu kopieren und dabei die Rechte, Besitzer und Zeitstempel zu erhalten, solltest du den rsync-Befehl mit den Parametern -a (Archivmodus) nutzen. Über SSH sieht der typische Befehl so aus:

rsync -a -e ssh user@server2:/pfad/zu/datei2 /pfad/zum/zielverzeichnis/

Dabei steht:

• -a: Archiv-Modus (behält Rechte, Besitzer, Zeitstempel usw.)
• -e ssh: Transfer erfolgt über SSH
• user@server2: Benutzername und Server-IP/-Hostname von Server 2
• /pfad/zu/datei2: Quellpfad und Dateiname auf Server 2
• /pfad/zum/zielverzeichnis/: Zielpfad auf Server 1

Text folgt

Hinweis: Ich bevorzuge in meinen Texten aus Gründen der besseren Lesbarkeit das Generisches Maskulinum. Weibliche und andere anderweitige Geschlechtsidentitäten werden dabei ausdrücklich mit gemeint, soweit es für die Aussage erforderlich ist.

Dieser Blog verfolgt keine kommerziellen Interessen. Etwaige Werbung ist kostenfrei! #supportyourlocal