Wie kann man ssh, schlüsselbasierte ("kennwortlose") Anmeldungen auf einem Linux / MacOSX-sshd-Server über Windows-, Linux- oder MacOSX-Clients einrichten?

5299
Johnny Utahh

Wie kann man ssh, schlüsselbasierte ("kennwortlose") Client-Anmeldungen bei einem Linux / MacOSX-sshd-Server über Windows-, Linux- oder MacOSX-Clients durchführen?

[Sie suchen sowohl das grundlegende konzeptionelle Verständnis der auf Schlüssel basierenden ssh / sshd-Logins als auch ein Betriebsbeispiel für das Setup aller oben genannten Betriebssysteme.]

4
(Ich habe vor, meine eigene Frage mit einer Beschreibung der schlüsselbasierten Anmeldekonzepte, einschließlich Challenge-Response und Authentifizierung, zu beantworten und dann ein Beispiel für den Betrieb anzugeben. Aber ich habe noch nicht genug Wiederholungspunkte, um sofort antworten zu können Sie müssen ca. 8 Stunden warten, bevor Sie dies tun.) Johnny Utahh vor 12 Jahren 0
Stellen Sie sicher, dass Sie Folgendes gesehen haben: [Wie kann ich SSH einrichten, damit ich mein Passwort nicht eingeben muss?] (Http://superuser.com/questions/8077/how-do-i-set-up-ssh -so-i-dont-have-to-type-mein-passwort / 8110 # 8110) slhck vor 12 Jahren 1
@ slhck- thx, hilfreiche ref. Johnny Utahh vor 12 Jahren 0

1 Antwort auf die Frage

3
Johnny Utahh

Bevorzugen:

  1. Diskutieren Sie prägnante Grundlagen des Schlüsselverschlüsselungskonzepts (versuchen, die Magie zu entmystifizieren)
  2. Wenden Sie diese Konzepte auf Login-über-Netzwerk (Authentifizierung) an
  3. Geben Sie ein detailliertes betriebliches Beispiel / Verfahren an.

1: Basisverschlüsselung, Authentifizierungskonzepte

Ein öffentlicher Schlüssel generiert verschlüsselte Daten, die nur ein privater Schlüssel entschlüsseln kann. Egal was diese Daten sind. [Könnte eine einfache Textdatei sein ... oder eine Art Challenge-Response-Authentifizierungssystem (Details unten) ... es handelt sich lediglich um einen Mechanismus zum Verschlüsseln und Entschlüsseln.] Beispielsweise kann jemand E-Mail-Inhalte mit dem öffentlichen Schlüssel "Johnny Utahh's" verschlüsseln. und die resultierende, verschlüsselte Ausgabe, die nur mit dem privaten Schlüssel von Johnny Utahh entschlüsselt werden kann. Daher ist es wichtig, dass der private Schlüssel an einem sicheren Ort aufbewahrt wird (vorzugsweise nicht über das Netzwerk), um eine sichere und private Kommunikation zu ermöglichen.

2: Anwenden der Konzepte zum Aktivieren von kennwortlosen Anmeldungen

Eine Anmeldung ohne Kennwort ist häufig mit einem Challenge-Response-Authentifizierungssystem aktiviert . Das System "sich anmelden" (nennen es MachineA) wartet auf eine "Frage" (wahrscheinlich nur eine zufällige Zeichenfolge) und verschlüsselt diese Frage mit einem öffentlichen Schlüssel, der der "Maschine" zugeordnet ist, die sich anmelden möchte (nennen Sie es MachineX). " MachineX entschlüsselt diese Frage und sendet die entschlüsselte Frage als "Antwort" zurück, die von MachineA validiert werden soll. Nach der Validierung gewährt MachineA ein MachineX-Login (an MachineA).

Dies setzt alles voraus, dass MachineA über den öffentlichen Schlüssel von MachineX verfügt (auf Linux-Systemen, der normalerweise unter ~/.ssh/authorized_keysdem Konto " Anmelden" gespeichert ist ), bevor der oben genannte Austausch stattfindet. Aus diesem Grund benötigt man eine Kopie des öffentlichen Schlüssels in der MachineA:~/.ssh/authorized_keysDatei. Theoretisch könnte diese Datei auch einen Namen haben ~/.ssh/authorized__public__keys... und könnte unter vielen Benutzern proaktiv eine Menge Verwirrung vermeiden, wenn sie als solche bezeichnet wird. Es wird jedoch angenommen, dass "verteilte" Schlüssel öffentliche Schlüssel sind. Daher vermuten wir die Designer Das "öffentliche" Adjektiv könnte überflüssig sein.

3: Detailliertes betriebliches Beispiel / Verfahren

(Vorwort: Dies setzt voraus, dass der Server / Computer, auf dem sich der Server anmeldet, über einen aktiven sshdDämon verfügt. Ein alternatives Beispiel / Prozedur / Notizen finden Sie in der Antwort "Wie erstelle ich SSH?", Damit ich mein Passwort nicht eingeben muss ", aber es werden unter anderem Windows-Clients nicht behandelt.)

Erstellen Sie ein Schlüsselpaar für den clientseitigen Anmeldeprozess (ssh). Erwägen Sie unter Windows die Verwendung von PuTTYgen und erstellen Sie ein neues Schlüsselpaar, einschließlich eines öffentlichen Schlüssels (natürlich). Für Linux / MacOSX empfiehlt sich ssh-keygen (1) . In diesem Beispiel wurde eine Sitzung zum Erstellen von Schlüsselpaaren unter Unbuntu (Linux) 11.04 ausgeführt:

joeschmo@MachineX:~$ ssh-keygen  Generating public/private rsa key pair. Enter file in which to save the key (/home/joeschmo/.ssh/id_rsa):  Created directory '/home/joeschmo/.ssh'. Enter passphrase (empty for no passphrase):  Enter same passphrase again:  Your identification has been saved in /home/joeschmo/.ssh/id_rsa. Your public key has been saved in /home/joeschmo/.ssh/id_rsa.pub. The key fingerprint is: e8:36:69:c5:9a:d2:e3:e0:53:f3:34:d4:d0:a2:8a:80 joeschmo@MachineX The key's randomart image is: [... <output truncated by author to save space> ...] joeschmo@MachineX:~$ ls -la .ssh total 16 drwx------ 2 joeschmo joeschmo 4096 Oct 20 12:26 . drwxr-xr-x 3 joeschmo joeschmo 4096 Oct 20 12:26 .. -rw------- 1 joeschmo joeschmo 1679 Oct 20 12:26 id_rsa -rw-r--r-- 1 joeschmo joeschmo 408 Oct 20 12:26 id_rsa.pub joeschmo@MachineX:~$ cat .ssh/id_rsa.pub  ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCp8nle6B68HgVQoQ8hCyQI9yKjsKnThRS0FjWsOwXId8Mc6i9E3zM0ByxBeneIFP8O42dwYmM9zwWrpP8zvpSbo0J2qIfhm+kZibClJnIIY8nVJt5AbXGdoQHOnxKOJUqP9EZgOgMqEjBNB3IVi7jPw2AXcMeZb1SCCbwsLWXzueECJP7Z4oJTU5+hD0grFMaWNhSszdpSD2Xo1hWi2fPdBu/cRMV4LTD3L7pOI57HeXS2mcLoznQohV7OV4RvDgRS9hhHi1A5/bzg9zRHJBISB0sxnwjmfz/kTaljBVZ8xtM9LenkmQYyj6B+0P+BFDAxzHIJKNOrf+i92fuLktoP joeschmo@MachineX joeschmo@MachineX:~$  

Enthält im obigen Beispiel für Linux /home/joeschmo/.ssh/id_rsaden privaten Schlüssel (nur Text), /home/joeschmo/.ssh/id_rsa.pubden öffentlichen Schlüssel (es ist auch nur Text). Ich habe im obigen Beispiel auch keine Passphrase eingegeben, nur "return" für "keine Passphrase".

[Anmerkung des Verfassers: Ich habe noch nie eine Passphrase für einen öffentlichen Schlüssel verwendet. Wenn Sie dies tun, müssen Sie die Passphrase erneut eingeben, um auf den öffentlichen Schlüssel zuzugreifen. Wahrscheinlich verschlüsselt die Passphrase den öffentlichen Schlüssel nicht sicher. Wenn die Passphrase jedes Mal eingegeben werden muss, verhindert dies den Zweck einer kennwortlosen Anmeldung. Vielleicht ist es nur ein einmaliger Eintrag? Hausaufgaben für später, möglicherweise ...]

Alle oben genannten Verfahren stellen die clientseitige (die Maschine auf „Anmelden von “) Verfahren. Nun zu der Server-Seite (die Maschine zu „melden Sie sich an, um “) Setup.

Sie müssen den id_rsa.pubInhalt an die ~/.ssh/authorized_keysDatei der Computer anhängen, für die ein Kennwort ohne Kennwort gewährt wird joeschmo@MachineX. (HINWEIS: ~/.ssh/authorized_keysStellen Sie sicher, dass Sie die Berechtigungen 'group' und 'other / world' deaktivieren. Andernfalls sshd liest die Datei normalerweise nicht, vermutlich weil sie als "unsicher" gilt). HINWEIS: ssh-copy-id automatisiert / vereinfacht diese Prozedur.

Das ist es. Wenn Sie sich nur mit einem Kennwort von einem Rechner zum anderen anmelden möchten, sind Sie fertig.

Aber ... allgemeiner ...

Behalten Sie den privaten Schlüssel auf einem Computer (und identifizieren Sie ihn so - nennen wir "MachineX") und kopieren Sie den öffentlichen Schlüsselteil des Paares auf jeden Computer, der ein Login für MachineX gewährt. Die Maschinen A, B, C fügen also alle eine Kopie des öffentlichen Schlüssels von MachineX in ihre entsprechende ~/.ssh/authorized_keyDatei ein, damit sich MachineX an den Maschinen A, B und C anmelden kann. (Außerdem können Sie viele andere öffentliche Schlüssel ... über DIFFERENT-Schlüsselpaare aufnehmen B. in Maschine A, B und C ~/.ssh/authorized_keys, um Anmeldungen von anderen Maschinen als MachineX zu ermöglichen.)

Machine X pub key --- copied to ~/.ssh/authorized_keys at --> Machine A Machine X pub key --- copied to ~/.ssh/authorized_keys at --> Machine B Machine X pub key --- copied to ~/.ssh/authorized_keys at --> Machine C 

Auf diese Weise kann sich ein Login von MachineX bei A, B oder C anmelden, ohne ein Passwort einzugeben.

Alternative:

Machine Y pub key --- copied to ~/.ssh/authorized_keys at --> Machine A Machine Y pub key --- copied to ~/.ssh/authorized_keys at --> Machine B Machine Y pub key --- copied to ~/.ssh/authorized_keys at --> Machine C 

Auf diese Weise kann sich ein Login von MachineY bei A, B oder C anmelden, ohne ein Passwort einzugeben.

So .... wenn alle über die „angewandte“ ist .... Maschinen A, B und C haben alle eine Kopie von X und öffentlichen Schlüssel des Y in A, B und C ist ~/.ssh/authorized_keys.

Beachten Sie auch, dass jedes Pub / Priv-Schlüsselpaar normalerweise einem bestimmten Konto auf einem Computer zugeordnet ist (in den obigen Fällen Machines X und Y). z. B. johnnyutahh @ MachineX, pappas @ MachineY usw.

In jedem Fall lebt der private Schlüssel in einem Pub / Priv-Schlüsselpaar nur auf einem Computer (wenn Sie es richtig machen) und wird niemals über ein Netzwerk transportiert. Also ist es privat. So ist es "sicher". Umgekehrt wird der öffentliche Schlüssel hin und her geworfen und überall kopiert.

Die ~/.ssh/authorized_keysDatei Beispiel hat unter dem öffentlichen Schlüssel von meinen johnnyutahh@my-laptop, root@site1.com, root@hypothetical-site2.com, joeschmo@MachineX(von ssh-keygen Beispiel oben), und enthalten andere könnte. Beachten Sie, dass diese "Adressen" am Ende jeder Zeile nur Kommentare sind. Es handelt sich lediglich um willkürlichen Text, der einem Menschen hilft herauszufinden, welcher Schlüssel welcher ist, und wird von keinem der automatisierten Systeme / Programme tatsächlich verwendet, um irgendetwas zu tun.

root@MachineA Oct 20 02:20:12 ~# cat ~/.ssh/authorized_keys ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAyTNCV7NUBssxobBZqWormtzcUmICSeGPTSp1i48FVIAebvpgAv7Pb3lFG3vFP8e88w9zGjFnZ6GzTQEwQaTL9YJ/Q9zOvAuxjb8chJz86j9Pg+S8ic4G34c2Og8UoNbTDWYOAZaP/axpoC9W81bh0tjldPnGQuifm9ELHXMXjfGq9QazyPqOcgNG6QL7cl8TYGoj4yJxRwoSytYG65l0/bCFX8JubkFdbWDXNY4tFEfollFIlm10xzQIfz6S6I80Bu0XesFvCjgfLwiLdt+8nT7U9Tawwq8jBc1U0yisQzkSJ9UwXYcKkYX2SJMQ8Ld3Nn82wsisXcEn+Zpe3A6Usw== johnnyutahh@my-laptop ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA0zPre+WkOlNgc4KzFRxGj2Y5UwG0gW+kI2LjvgwNYZLHGQqQ0GQGkmg5rulSbyx3WPo1KNCiaqafQ8fWFmXIgKreGWMwEOehnKLyXLhhxvzpYDgJhI1QbwgInLjUCj8krvsdj9fCLY6sFTYFCXLKUptJGbXThcB170kFhJCUlR33H4WfWn4NWzwpmma4HsVDR7F7eUmJE8FD+6AG4Uw9bljDaUS++XghAZ5oXUofGx7FE2vcQKdNAMF5jYIN/XbL4cj4HuJUonqYgyxCX2JpvJePEwMBW1qQffAjgtgs85217OFmfLIVL6rB3RHh1mmIHSVLtOhAZo1okg708scPCw== root@site1.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC84JdXtzFhQgcFj7/1pz+li2qzZSThJalddkUubuvI71i/Bk7fJ5uI8CCQDPvzr1P+HGaY//RxBG0S2jINXk4LEE1mA3Ogyo+r2ykMaqcNa2JJycHs0sdczZhZR0OOxf5KGz8hhy5W1cdhca6q0AcHmbj+KWz5N0U1qlLptMD4C45QgxtUjFYPWM7r9bDdt6kTo9J39LP4w3S1GTM9uDC8V5NUZX+lFZMap+Tch/YcEiPxAm4VaTM7CGXly+w5XpjlEVUNEb5xu51dOoOXbjueD5Vl3wdPwC6A511v2k9mD/1F4GXjRDzlelKiu4TJ9mVAI2J9+UC0iMUyYj52RO53 root@hypothetical-site2.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCp8nle6B68HgVQoQ8hCyQI9yKjsKnThRS0FjWsOwXId8Mc6i9E3zM0ByxBeneIFP8O42dwYmM9zwWrpP8zvpSbo0J2qIfhm+kZibClJnIIY8nVJt5AbXGdoQHOnxKOJUqP9EZgOgMqEjBNB3IVi7jPw2AXcMeZb1SCCbwsLWXzueECJP7Z4oJTU5+hD0grFMaWNhSszdpSD2Xo1hWi2fPdBu/cRMV4LTD3L7pOI57HeXS2mcLoznQohV7OV4RvDgRS9hhHi1A5/bzg9zRHJBISB0sxnwjmfz/kTaljBVZ8xtM9LenkmQYyj6B+0P+BFDAxzHIJKNOrf+i92fuLktoP joeschmo@MachineX root@MachineA Oct 20 02:20:19 ~#