CSS, HTML und Javascript mit {stil}

SSH-Schlüssel unter MacOS

SSH-Schlüssel stellen eine höhere Sicherheit für das Login auf einem Server dar als SSH mit einem Passwort. Da schwebt natürlich immer eine kleine Portion Angst mit im Raum: Was ist, wenn was schief läuft bei der Einrichtung?

Das Passwort kann bei einem Brute Force-Angriff geknackt werden, während SSH-Schlüssel kaum durch eine Brute Force-Attacke allein in falsche Hände geraten können. 

SSH-Schlüssel sind ein Paar von zwei langen Strings (Zeichenketten): Ein öffentlicher Schlüssel und ein privater Schlüssel.

Der private Schlüssel (Private Key) bleibt auf dem Client-Rechner, der öffentliche Schlüssel (Public Key) wird auf den Server übertragen und mit dem privaten Schlüssel gekoppelt. Wenn die beiden Schlüssel beim Login zusammenpassen, braucht der Server kein Passwort. Allerdings erhöht eine Passphrase (Passwort-Phrase) die Sicherheit des Logins via Public Key und Private Key um einen weiteren Faktor.

Das RSA-Schlüsselpaar

SSH-Key auf dem lokalen Rechner: Schlüsselpaar

Das Schlüsselpaar wird auf dem Client-Rechner erzeugt – in den meisten Fällen ist das der lokale Rechner / die Workstation des Webmasters oder Administrators.

ssh-keygen -t rsa

Das Terminal bestätigt den Aufruf mit

Generating public/private rsa key pair

Schlüssel und Passwort-Phrase speichern

Der ssh-keygen-Befehl stellt Fragen:

Enter file in which to save the key (/Users/myusername/.ssh/id_rsa):

Enter speichert die Datei im vorgeschlagenen Verzeichnis. Bei einem neuen Schlüsselpaar ist der Default-Name immer id_rsa und id_rsa.pub. Aber Vorsicht!

ssh-Schlüssel für mehrere Domains / Server

Ein zweites Schlüsselpaar für einen weiteren Server würde die Schlüssel überschreiben und den alten Schlüssel endgültig unbrauchbar machen! 

Darum kann man die Dateinamen der Schlüssel während der Erzeugung ändern oder ergänzen. Wenn weitere Schlüssel erzeugt werden, ändert man die Dateinamen, z.B.

Mehrere SSH-Schlüssel für verschiedene Server / Domains
/Users/myusername/.ssh/id_rsa_server1

Die Dateinamen der Schlüssel lauten dann id_rsa_server1 und id_rsa_server1.pub. Und besser statt server1 einen sprechenden Namen einsetze.

Passphrase für mehr Sicherheit

Enter passphrase (empty for no passphrase):

Die Passphrase chiffriert den Schlüssel zusätzlich und muss beim Login wie ein Passwort eingegeben werden, um den Private Key zu entschlüsseln. Es geht auch ohne Passphrase, aber das lokale Passwort ist ein weiterer Sicherheitsmechanismus: Die Sicherheit des Private Keys beruht darauf, dass er für niemanden sichtbar ist. Sollte der lokale Rechner kompromittiert werden (z.B. wenn der Rechner gehackt oder gestohlen wird), kann sich der Hacker ohne die Passphrase immer noch nicht einloggen.

Warum Passphrase und nicht Passwort? Eine Passphrase kann Buchstaben und Ziffern, Sonderzeichen und Leerzeichen enthalten. Viele kennen Passphrase sicher aus der WordPress config.php.

Der Private Key wird nicht im Netz gespeichert, sondern nur auf der eigenen Workstation. Die Passphrase entschlüsselt den Private Key nur auf dem lokalen Rechner und kann nicht durch eine Brute Force-Attacke ausgehebelt werden.

Die Erzeugung der Schlüssel

Nach der Abfrage der Passphrase erzeugt der Client das Schlüsselpaar.

Generating public/private rsa key pair.
Enter file in which to save the key (/Users/myusername/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /Users/myusername/.ssh/id_rsa.
Your public key has been saved in /Users/myusername/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:jWwmjfEqKtPykNNaMPhFzcBvBMt1janp4ygtHiI2oJo myusername@MyClient.local
The key's randomart image is:
+---[RSA 2048]----+
|   .o.. .+       |
|   ..*..o .      |
|    +o+o         |
|.  .  =* o       |
|=   .oo S .      |
|o* .  o=         |
|B+=..o..         |
|BB=oo..          |
|E*+o             |
+----[SHA256]-----+
  1. Der Private Key (private Schlüssel) liegt jetzt unter /Users/myusername/.ssh/id_rsa
  2. Der Public Key (öffentlicher Schlüssel) unter /Users/myusername/.ssh/id_rsa.pub
-rw-------   1 myusername  staff  1766  1 Mär 07:21 id_rsa
-rw-r--r--   1 myusername  staff   416  1 Mär 07:21 id_rsa.pub
-rw-r--r--@  1 myusername  staff  1875 29 Dez 15:42 known_hosts

cat zeigt den Inhalt des Public Key:

ssh-rsa AAAAB3NzaC1yc2EAAAAD… myusername@MyClient.local

Public Key auf den Server kopieren

Jetzt muss der Public Key auf den Server in authorized_keys transferiert werden. Wenn es noch keine Datei authorized_keys im Verzeichnis .ssh auf dem remote Server gibt, wird die Datei neu angelegt.

touch authorized_keys
 ls -al
 -rw-r--r--  1 root root    0  1. Mär 08:41 authorized_keys
 -rw-r--r--  1 root root 1003 22. Sep 15:09 known_hosts

Beim ersten angelegten Schlüssel in authorized_keys kann der Public Key mit scp (Secure Copy) (Pfad zum .ssh-Verzeichnis anpassen!) übertragen werden.

scp /Users/myusername/.ssh/id_rsa.pub user@123.45.67.89:/root/.ssh/authorized_keys

Passwort eingeben und der Upload beginnt:

id_rsa.pub.  100%  416     4.1KB/s   00:00

Mit scp also nur für die erste Schlüsseldatei! Wenn ein zweiter oder dritter Schlüssel angelegt wird, würde die authorized_keys-Datei überschrieben. Stattdessen den neuen Key mit vi oder nano mit -w-Flag als neue Zeile in die authorized_keys einfügen.

Die Datei authorized_keys hat keine Schreibrechte. Evtl. die Schreibrechte setzen:

chmod u+w authorized_keys

Den Inhalt von id_rsa.pub mit vi oder nano in die Datei authorized_keys kopieren (), nano mit dem -w Flag ( -w. –nowrap Don’t hard-wrap long lines), damit keine Zeilenumbrüche eingefügt werden.

Anschließend die Schreibrechte wieder zurücknehmen:

chmod u-w authorized_keys

Login testen nicht vergessen! Um sich auf einem remote Host einzuloggen, neues Terminalfenster öffnen und ssh eingeben:

ssh myusername@remoteServer

Wenn nicht der vorgegebene Name des Schlüssels benutzt wird, müssen Pfad und Name des Schlüssels angegeben werden:

ssh -i /Users/myusername/.ssh/id_rsa_mykey remoteuser@123.456.789.012

!!! Mehr als ein Schlüsselpaar?

Wenn Public und Private Key für mehr als einen Server angelegt wurden, muss eine Config-Datei auf dem eigenen Rechner / der Workstation des Webmasters dem Login zeigen wo’s lang geht.

Wenn es noch keine Config-Datei gibt, wird sie im .ssh-Verzeichnis des Users mit touch angelegt.

touch config
Host server1
  Hostname 123.45.67.89
  user webmaster
  IdentityFile ~/.ssh/id_rsa_server1
Host server2
  Hostname 98.76.543.210
  user webmaster
  IdentityFile ~/.ssh/id_rsa_server2

und anmelden mit

ssh server1 oder
ssh server2

Root Login nur noch mit SSH-Keys

Wenn der öffentliche Schlüssel auf den Server kopiert wurde und das Login mit SSH-Schlüssel erfolgreich getestet wurde, kann das Login in der SSH-Konfiguration auf SSH-Keys beschränkt werden.

sudo nano /etc/ssh/sshd_config

Zeile mit PasswordAuthentication suchen

PasswordAuthentication no

ssh neu starten, um die Änderungen zu übernehmen (Ubuntu):

reload ssh

oder (CENTOS, REDHEAD, FEDORA)

/etc/init.d/sshd restart oder 
service sshd restart

Backup von Private und Public Key

Beim einfachen SSH-Login muss das Passwort den Angriffen standhalten. Beim Login mit dem Private Key ist der lokale Rechner allein verantwortlich. Ein weiterer Rechner mit SSH-Schlüssel-Zugang oder zumindest ein externes Backup müssen dafür sorgen, dass bei einem Ausfall des Rechners der Zugang zum Server möglich ist.

Passphrase für Private Key ändern

Das -p Flag fordert eine Änderung der Passphrase für den Private Key an. ssh-keygen will die alte Passphrase und zwei mal die neue Passphrase.

ssh-keygen -f id_rsa -p
2024-02-12 SITEMAP BLOG