SSH public private keys

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-considerations

Regelmäß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:

Prüfen

ssh-keygen -l -f ~/.ssh/id_rsa

4096 d6:7b:c7:7a:4f:3c:4d:29:54:62:5f:2c:58:b2:cb:86 ~/.ssh/id_rsa (RSA)

Create a public SSH key from the private key?

https://serverfault.com/questions/52285/create-a-public-ssh-key-from-the-private-key

Alternative

openssl rsa -in wemove -pubout -out wemove.pub2

Use RSA private key to generate public key?

https://stackoverflow.com/questions/5244129/use-rsa-private-key-to-generate-public-key

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!

Man kann ihn aber wohl einfach hinzufügen (weitere Recherche, ob pub file dann immer noch wirklich konsistent ist?):

How do I retrieve the public key from a SSH private key?

https://askubuntu.com/questions/53553/how-do-i-retrieve-the-public-key-from-a-ssh-private-key

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 

https://stribika.github.io/2015/01/04/secure-secure-shell.html

„Fazit: RSA ist DSA vorzuziehen, da es weniger anfällig für schlechte Zufallsgeneratoren ist. Ansonsten gilt in Sachen Schlüssellänge oder Modulus: 1.024 Bit sind zu wenig.“

http://www.golem.de/news/verschluesselung-was-noch-sicher-ist-1309-101457-6.html

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:

https://wiki.ubuntuusers.de/SSH/

Gute Anleitungen

ssh-keygen - Generate a New SSH Key

https://www.ssh.com/ssh/keygen

SSH-Key erstellen - so geht's

https://www.heise.de/tipps-tricks/SSH-Key-erstellen-so-geht-s-4400280.html

Recherchieren

• • 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