keywords: SSH, Authentifizierung, Authentication, Schlüsselpaar
Einmalig für sein persönliches Schlüsselpaar
Lokaler persönlicher Rechner (Linux, macOS)
SSH Private Public Schlüsselpaar erstellen
- Vorab
sollte man sich eine sichere Passphrase überlegen. Die ist zukünftig
das einzige Passwort, das man sich für jeden SSH-Login merken und
eingeben muss, der mittels dieser Private Public Keys abgesichert wird.
- Es
empfiehlt sich, vorher im jeweils genutzten Passwort Manager eine neue Notiz zu eröffnen mit
Titel "SSH private key" und dort vorab die zuvor überlegte Passphrase als Passwort einzutragen.
- Public private key pair (Schlüsselpaar) generieren:
ssh-keygen -t rsa -b 4096 -o -a 100 -C [email address]
Generating public/private rsa key pair.
Hier einfach mit Return bestätigen, dass der vorgeschlagene default-Dateiname für den private key erzeugt wird:
Enter file in which to save the key (/.../.../.ssh/id_rsa):
Hier die zuvor überlegte, sichere und vorab im jeweils genutzten Passwort Manager hinterlegte Passphrase eingeben:
Enter passphrase (empty for no passphrase):
Hier die Passphrase noch ein zweites Mal zwecks Bestätigung eingeben:
Enter same passphrase again:
Your identification has been saved in [/path/to/user]/.ssh/id_rsa.
Your public key has been saved in [/path/to/user]/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:... [email address]
The key's randomart image is:
...
- id_rsa ist die sensible private key Datei! Den Inhalt von id_rsa und die passphrase im jeweils genutzten Passwort-Manager in einem Eintrag mit Titel "SSH private key" o.ä. hinterlegen.
ACHTUNG: Der private key wird niemals mit anderen geteilt! - id_rsa.pub ist die public key Datei. Den Inhalt von id_rsa.pub im jeweils genutzten Passwort-Manager in einem Eintrag "SSH public key" o.ä. hinterlegen.
- Rechte des Verzeichnis
~/.ssh prüfen. Wenn nicht drwx------, dann auf das benötigte Minimum beschränken
chmod 700 ~/.ssh - Rechte der beiden Key-Dateien prüfen. Wenn nicht
-rw-------, dann auf das benötigte Minimum beschränken
chmod 600 ~/.ssh/id_rsa*
Anmerkungen
- Sowohl der private als auch public key file können und sollten umbenannt werden, damit klarer ist, wessen Identität sie darstellen. Zudem kann jeder für sich selbst bei Bedarf auch zwei Schlüsselpaare erstellen, für beruflich und privat, und diese auch durch die Angabe der privaten oder beruflichen E-Mail-Adresse unterscheiden. Beispiele:
- Privates key pair für Maria Musterfrau:
- private key: maria.musterfrau_id_rsa
- public key: maria.musterfrau_id_rsa.pub
- Berufliches key pair für Maria Musterfrau, die bei der Musterfirma GmbH arbeitet:
- private key: musterfirma_maria.musterfrau_id_rsa
- public key: musterfirma_maria.musterfrau_id_rsa.pub
- Die Daten sollten im jeweils genutzten Passwort Manager hinterlegt werden. Empfehlung: Zwei Einträge:
- "SSH private key" (inkl. passphrase). ACHTUNG: Sensibel!
- "SSH public key" (ohne passphrase). Der ist nicht sensibel und öffentlich und kann daher mit anderen geteilt werden bei Bedarf.
- Windows: Ab Windows 10 ist das sog Windows Subsystem for Linux (WSL) Bestandteil. Nach Installation von OpenSSH per
sudo apt install openssh-client ist ssh-keygen verfügbar.
Die .ssh/authorized_keys wird sich im Laufe der Zeit füllen.
Ein großes Manko, das Tatu Ylönen, der Erfinder von SSH, erwähnte:
Die
Sys-Admins denken nicht daran, nicht mehr benötigte public keys zu
löschen. Personen, die ein Unternehmen verlassen haben, können noch
Jahre danach mit ihren keys zugreifen.
Es sollte von Anfang an darauf geachtet werden, dass regelmäßig aufgeräumt wird.
Damit das effizient möglich ist, sollten alle public keys am Ende die Mail-Adresse des Mitarbeiters enthalten. Deshalb ist die Nutzung des Parameters "-C" (= comment) wichtig. Dadurch kann die
Person gleich identifiziert und zugeordnet werden, ohne zuvor einzelne
Schlüssel-Schnipsel o.ä. vergleichen zu müssen.
Passphrase
"2. Passphrase considerations
When creating the SSH key pair, as shown in the following steps, you can choose to either lock your private key with a passphrase or use no passphrase at all.
Adding a passphrase requires the same passphrase to be entered whenever the key pair is used. Not adding a passphrase removes this requirement. For this reason, creating a key pair without a passphrase is more convenient and potentially essential for certain scripts and automation tasks. But it’s also less secure.
If a third-party gains access to a private key without a passphrase they will be able to access all connections and services using the public key.
A good compromise between convenience and security is to generate a separate key pair for each service or connection you want to use, adding a passphrase only for critical services. If you suspect a key has been compromised, simply generate a new pair for that service and remove the less secure key."
https://ubuntu.com/tutorials/ssh-keygen-on-windows#2-passphrase-considerationsRegelmäßig für jeden SSH-Account auf dem jeweiligen Ziel-Server
Ziel-Server (Linux oder OS X)
Public key hinterlegen
- Prüfen, ob Verzeichnis .ssh bereits besteht. Falls nicht, anlegen
mkdir ~/.ssh - Rechte des Verzeichnis .ssh auf das empfohlene Minimum
drwx------ beschränken
chmod 700 ~/.ssh
(600 reicht hier nicht aus, dann klappt der ssh connect nicht)
- Prüfen, ob Datei authorized_keys bereits besteht. Falls nicht, anlegen
touch ~/.ssh/authorized_keys - Rechte der Datei authorized_keys auf das empfohlene Minimum
-rw------- beschränken
chmod 600 ~/.ssh/authorized_keys - Seinen public key hinterlegen
vi ~/.ssh/authorized_keys
=> per copy & paste den public key (Inhalt der id_rsa.pub) eintragen bzw. bei vorhandenen Einträgen hinzufügen
Auf jedem Managed Server liegt eine authorized_keys mit den Public Keys der aktuellen Mitarbeiter in folgendem Verzeichnis ab:
~/.ssh/authorized_keys
SSH: Fehlenden oder verlorenen public key nachträglich mit vorhandenem private key erstellen
Erstellen
ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub
Enter passphrase:
Diese Ausgabe im Format "-----BEGIN PUBLIC KEY----- ..." wird so allerdings in der ~/.ssh/authorized_keys nicht akzeptiert.
ACHTUNG: Der Kommentar (E-Mail-Adresse) wird nicht mit erstellt!
RSA vs DSA vs Ed25519
"DSA was deprecated by OpenSSH and is later going to be entirely dropped"
http://security.stackexchange.com/questions/112802/why-openssh-deprecated-dsa-keys„But
I saved the killer argument for the end: man ssh-keygen says that a DSA
key has to be exactly 1024 bits long to be compliant with NIST's FIPS 186-2.
So although in theory longer DSA keys are possible (FIPS 186-3 also
explicitly allows them) you are still restricted to 1024 bits. And if
you take the considerations of this [article], we are no longer secure
with 1024 bits for either RSA or DSA.“
- Never use DSA or ECDSA.
-
Ed25519 is probably the strongest mathematically (and also the
fastest), but not yet widely supported. As a bonus, it has stronger
encryption (password-protection) of the private key by default than
other key types.
- RSA is the best bet if you can't use Ed25519.
http://security.stackexchange.com/questions/5096/rsa-vs-dsa-for-ssh-authentication-keys
Generate client keys using the following commands:
ssh-keygen -t ed25519 -o -a 100
ssh-keygen -t rsa -b 4096 -o -a 100
Sehr
gute und verständlich geschriebene Einführung in die Möglichkeiten von
SSH. Die Möglichkeiten der ~/.ssh/config (Client) und
/etc/ssh/sshd_config (Server) sollte man sich näher anschauen:
ssh-keygen - Generate a New SSH Key
SSH-Key erstellen - so geht's
- Noch sicherer mit anderem Format?
Um den Private-Key noch sicherer zu machen, wandeln wir den Private-Key in ein anderes Format um (PCKS#8).
...
Dieses Format ist noch sicherer gegen Brute-Force Attacken und vor allem abwärtskompatibel, da PCKS#8 Bestandteil von openSSL und das wiederum von openSSH ist.
...
In der Kurzanleitung habe ich ja schon den Private-Key in das PCKS#8
Format umgewandelt, da für Brute-Force Attacken anfälliger. Das Passwort
wird nämlich nur MD5 gehasht, mit einem Salt versehen und anschließend
wird der Key damit verschlüsselt. Das gehashte Passwort ist jedoch relativ leicht aus der Datei zu extrahieren und damit auch anfälliger für Brute-Force Attacken. - Welche ssh Schlüssellänge ist heutzutage aktuell?
Wie
oben schon kurz angedeutet, dauert die Erzeugung des keys länger, je
größer die Schlüssellänge in Bit gewählt wird und ist damit auch
rechenleistungsabhängig. Das Ver- und Entschlüsseln dauert
dementsprechend auch länger. Die Standardlänge im SSH-Client ist auf 2048 bits gesetzt, wobei mittlerweile eine Schlüssellänge von 4096 bits empfohlen
wird. Ein 4096 bits langer Schlüssel wird nicht so schnell geknackt wie
einer mit einer Länge von 2048 oder sogar 1024. Wobei ein 1024 bit RSA
Schlüssel genauso stark ist wie ein 1024 bit DSA Schlüssel.
Ich
selber habe meine Schlüssel mit 8192 bit erstellt, damit ich diesen
Schlüssel auch etwas länger nutzen kann, ohne mir Sorgen um die
Sicherheit meines Schlüssels machen zu müssen.
https://www.mittwald.de/blog/mittwald/howtos/ssh-key-erstellen - Komfortabler mit SSH Agent, der Identitäten bzw. Passwörter kennt?
For keys that were added to the SSH Agent (a program that runs in the
background and avoids the need for re-entering the keyfile passphrase
over and over again), you can use the ssh-add -L command to list the public keys for keys that were added to the agent (via ssh-add -l). This is useful when the SSH key is stored on a smart card (and access to the private key file is not possible).
https://askubuntu.com/questions/53553/how-do-i-retrieve-the-public-key-from-a-ssh-private-key