Login per SSH per Key mit oder ohne Passphrase (Putty)

Hier gibt's Anleitungen und Themen dazu.
Antworten

Themenstarter
Outi
Administrator
Administrator
Beiträge: 478
Registriert: 13.02.2015, 22:24
RasPis: 10+
Kontaktdaten:

Login per SSH per Key mit oder ohne Passphrase (Putty)

Beitrag von Outi »

History:
25.11.2023 - Erste Fertigstellung



Hinweis:
Diese Anleitung/Information erhebt keinen Anspruch auf Vollständigkeit und kann Fehler enthalten und die Benutzung erfolgt auf eigene Gefahr.
Es wird keinerlei Haftung für Schäden und/oder Datenverluste übernommen.

Info:
Diese Anleitung beschreibt das Login auf einen Raspberry Pi per SSH (Kommandozeile/Terminal) mit einer Schlüsseldatei (Key) ohne reguläres Passwort.
Hierbei genügt es normalerweise in der Konfiguration die Datei (den Schlüssel) entsprechend auf dem Pi und dem PC zu hinterlegen und anschließend auf den Pi zuzugreifen, ohne nach einem Passwort gefragt zu werden.
Diese Methode hat den Vorteil, dass man sich quasi kein Passwort mehr merken muss und dass ein Angreifer bei einer Passwortattacke kein Passwort mehr erhacken kann, weil keins mehr zum Login vorhanden ist (bei entsprechender Konfiguration).
Wer will, kann dieser Schlüsseldatei natürlich auch eine sogenannte Passphrase (auch eine Art Passwort) verpassen, was zu empfehlen ist, wenn mehrere Leute auf den selben PC zugreifen und sonst ohne Weiteres auf den Pi zugreifen könnten.

Es können dabei drei Szenarien verwirklicht werden:

Empfehlung für alle 3 Szenarien:
Bitte bei Zugriffen ins/oder aus dem Internet nur einen normalen User und KEINEN SuperUser/Admin Account nutzen !!
Wer Adminzugriff nutzen möchte, kann nach dem Login in diesen Modus wechseln.

Sollte ein Angreifer doch irgendwie Zugang zum System geschafft haben, hat er meist kaum Rechte (Adminrechte aber trotzdem nicht ganz ausschließbar).
Bei Szenario 3 könnte man evtl. auch Adminrechte zulassen, da man für das Keypasswort den Key knacken müsste aber das muss jeder selbst entscheiden und eine Umschaltung auf Admin ist nach dem Login kein Hexenwerk.

1. SSH Key + bisherige Nutzung des Passworts (nicht empfehlenswert !!)
Vorteil: Man kann von unterwegs auf den Pi wie gewohnt per Passwort zugreifen, wo kein Zugriff per Key möglich ist
Nachteil: Es gibt keinen zusätzlichen Schutz durch den Key, da dieser damit dem normalen Passwort umgangen wird
Sicherheit: Keine weitere Sicherheit durch den Key, dieser funktioniert nur als schnellerer Zugriff
Info: Hier sollte man mindestens ein sehr komplexes Passwort vergeben, wenn man unbedingt externen Passwortzugriff benötigt !!

2. SSH Key + Deaktivierung der Passwortfunktion
Vorteil: Ohne Passwort sind entsprechende Angriffe sehr viel schwerer
Nachteil: Ohne Key auch kein eigener Zugriff / kommt der Key abhanden, ist er auch als Zugang Fremder nutzbar
Sicherheit: Deutlich höhere Sicherheit als per Passwortzugang
Info: Wer hier auch den Zugang per Key absichern will (vor Fremdzugriff am PC oder geklautem Key), nutzt Szenario 3

3. SSH Key + Deaktivierung der Passwortfunktion + zusätzliche Key Passphrase (sehr empfehlenswert !!)
Vorteil: Sehr hoher Schutz, da der Key zusätzlich mit einem eigenen Passwort abgesichert wird
Nachteil: Ohne Key auch kein eigener Zugriff
Sicherheit: Noch höhere Sicherheit als Szenario 2, da der Key ohne die dazugehörige Passphrase (Passwort) nutzlos ist
Info: Höchste Sicherheit der 3 Szenarien

Andere Szenarios (Mischungen aus den obigen) habe ich weggelassen, da sie in meinen Augen sicherheitstechnisch keinen Sinn machen.
Sollte ich was Wichtiges vergessen oder falsch beschrieben haben, bitte ich um Hinweis(e) unter dieser Anleitung.

Meine Meinung:
Szenario 1 ist eigentlich nur dann rechtfertigbar, wenn man den Pi nicht ins Internet lässt und ein gutes Passwort vergibt und dabei die Key Variante parallel installiert, damit man beim Start der SSH Sitzung (per Putty oder SSH Befehl des PC Betriebssystems) schnell ohne Passwort verbinden kann.
Wichtig dabei zu bedenken: Auch andere Familienmitglieder oder Leute in der Umgebung mit Zugriff auf den PC haben somit Zugang zum Pi ohne jegliche Einschränkung.

Szenario 2 wird meist verwendet, wenn man erhöhte Sicherheit möchte und der Pi auch ins Internet geht und/oder von dort aus erreichbar ist und/oder von dort aus erreichbar sein soll.
Da hier die Passwortabfrage deaktiviert wurde, sind reine Passworthacker zumindest schon mal "kälter gestellt".
Hier muss der Key, also die entsprechende Schlüsseldatei, auf alle Geräte, die Zugriff auf den Pi haben sollen.
Ohne den passenden Schlüssel kein Zugriff, auch kein eigener Zugriff.

Szenario 3 kommt mindestens dann zum Einsatz, wenn man den fremden Zugriff auf dem eigenen PC nicht verhindern kann.
Dann wird auch mit vorhandenem (und evtl. geklautem Key) ein Passwort (beim Key Passphrase genannt) abgefragt.
Wer die höchstmögliche Sicherheit möchte (was nur den reinen SSH Zugang angeht !!), nutzt Szenario 3.

Nun fragt sich der eine oder andere, was denn nun daran sicherer sein soll an Szenario 3 statt einem reinen Passwortzugang wie sonst, da man ja bei beidem ein Passwort eingeben muss, man aber doch einen höheren Konfigurationsaufwand hat.
Ganz Einfach: Generell wird bei Szenario 2 und 3 die "normale" Passwortabfrage deaktiviert, die deutlich leichter zu knacken ist, als ein Schlüssel (Key), der viel sicherer selbst verschlüsselt wird. Normal reicht Szenario 2 eigentlich schon aus, da ohne Key auch kein Zugriff per Passwort möglich ist, da Zugriffsversuche schon ohne den Key scheitern.
Szenario 3 sichert nun noch zusätzlich den Key an dem Gerät vor Leuten, die Zugriffe auf dieses Gerät und damit den Key haben, was oft zuhause eher selten ist, da normal jeder sein eigenes Gerät hat oder man der Familie traut.
Anders sieht es aus bei Geräten in Firmen oder Vereinen, also quasi öffentlichen Geräten.
Nicht zu vergessen: Da die Passphrase im Key sehr komplex verschlüsselt wird, ist dieser bei einem Diebstahl so gut wie nutzlos.

Jeder nutzt die Sicherheit, die er vertreten kann !! Ich übernehme keine Verantwortung und biete hier lediglich meine Erfahrung !!


Das obige Infofeld war nun etwas viel Text aber ich finde diesen Punkt extrem wichtig und es liegt mir am Herzen, dass auch Einsteiger dieses Thema sehr ernst nehmen, sobald sie ihren Pi mit dem Internet verknüpfen und auch von extern auf die Kommandozeile zugreifen wollen.
Es gibt noch viele weitere Sachen, die wichtig sind, wenn der Pi auf das Internet zugreift aber ich sehe diesen Zugang per SSH schon für sich genommen wichtig genug, um ihm ein eigenes Thema zu widmen.

Nun geht es aber los:

Um von einem PC aus per SSH auf den Raspberry Pi zuzugreifen, muss dort natürlich dieser Zugang erst freigeschaltet werden.
Wer meine Anleitung zur Einrichtung vom Raspberry Pi OS schon benutzt hat, sollte bereits diesen Zugang aktiviert haben.
Falls nicht, dort bitte nachlesen und ggf. nachträglich aktivieren (geht auch in der grafischen Oberfläche, falls installiert).

Nutzer vom MAC oder einem anderen Linux Gerät haben sicherlich ihren eigenen "Puttyersatz".
Jedoch habe ich nur Windows zur Verfügung und kann daher leider nicht auf einen MAC oder Linux PC zurückgreifen.

Dieser Weg beschreib aber nur den Zugang von Windows auf den Raspberry Pi in die textbasierende Kommandozeile über Putty.

Zuerst laden wir beide Programme herunter (Direktlinks der .exe Dateien):

Externer Link Putty in 64Bit für Win
Externer Link PuttyGen in 64Bit für Win

Die beiden Dateien können nach dem Download direkt gestartet werden und benötigen keine Installation.
Wer dennoch die Installationsdateien und Weiteres nutzen möchte, findet alles hier:
Externer Link Putty Downloadseite

Nach dem Download der beiden Dateien richten wir zuerst den ganz normalen Zugang zum Pi per Putty ein, indem wir auf die erste heruntergeladene Datei doppelklicken.

Es erscheint folgende Ansicht:

Bild

Auch wenn es evtl. schon voreingestellt ist, kontrollieren wir, ob als Dateispeichercodierung UTF-8 eingestellt ist, da im Internet auf Webseiten faktisch nichts anderes mehr verwendet wird.
Somit beugen wir auch diversen Falschdarstellungen bei Texten vor, die später nur schwerlich umzukonvertieren sind.
Auch Datenbankabfragen verwenden so gut wie nur noch UTF-8 in bestimmten Versionen.

Diese Einstellung finden wir in Putty links im Menüpunkt Window => Translation:

Bild

Nun wechseln wir wieder links im Menü zurück auf die Hauptseite über den Punkt Session:

Bild

Hier nun die folgende weitere Vorgehensweise in 6 Punkten:
  1. mit diesem Menüpunkt geht es auf die gezeigte Hauptseite
  2. hier den Namen des RasPis eingeben, so wie oben in der Vorabkonfiguration (hier: raspberrypi)
  3. hier den Namen der zu speichernden Konfiguration eingeben (frei wählbar)
  4. das Ganze hier speichern, um nicht jedes Mal alles neu eingeben zu müssen
  5. sobald gespeichert wurde, erscheint hier ein neuer Eintrag
  6. nach dem Speichern hier die Konfiguration starten und die Verbindung herstellen
Wenn man später Putty neu startet, kann man über die Auswahl bei Punkt 5 die zuvor gespeicherte Konfiguration per Load laden und unten per Open einfach starten.

Bei der allerersten Verbindung erscheint ein Sicherheitshinweis in Putty:

Bild

Da Putty den Server und dessen Sicherheitsschlüssel noch nicht kennt und wir diese Konfiguration gerade erst erstellt haben, teilen wir Putty per Accept mit, sich diese Kombination aus Konfiguration und Verschlüsselung zu merken.

Beim der nächsten Verbindung über Putty erscheint dann diese Warnung nicht mehr.

Sollte diese Meldung nicht erscheinen und stattdessen eine Fehlermeldung, dass der Host nicht gefunden wurde, sollte man den Namen des Pi und das Passwort nochmals kontrollieren.

Ist alles ok, dann erscheint das Login auf den RasPi im Terminalfenster:

Bild

Hier wurde im Bild bereits pi als Benutzer eingegeben.
Das Passwort wird nun blind eingegeben, so wie es zuvor in der Vorabkonfiguration festgelegt wurde.

Nach dem erfolgreichen Login sehen wir die folgende Ausgabe:

Bild

Bei späteren Logins wird uns auch noch die IP des letzten Gerätes angezeigt, mit dem wir uns zum RasPi verbunden haben.
Die grüne Farbe und der Name pi in der Eingabezeile zeigt, dass wir als normaler Nutzer eingeloggt sind.
Um mit Rootrechten zu arbeiten (eher nicht empfohlen), gibt man sudo su ein und der Name pi ändert sich in root und die grüne Farbe wechselt zu grau (wie der Rest).
Zurück in den reinen Benutzermodus kommt man wieder mit der Eingabe exit.
Ein weiteres exit beendet die Verbindung und schließt Putty ebenfalls.

Wir lassen das Putty Fenster aber noch offen, da wir es noch für den Schlüssel benötigen.

Damit haben wir nun das generelle Login per SSH über Putty eingerichtet und kümmern uns nun um den Schlüssel:

Dazu starten wir nun statt Putty das zweite Programm PuttyGen und sehen folgendes Fenster:

Bild

Auf dem Bild sind folgende Punkte rot eingekreist:

Links unten:
Type of key to generate: RSA
Das ist der Verschlüsselungstyp, der empfohlen wird und sehr sicher sein soll.
Ganz rechts unten (über der 4096) ist noch der alte unsichere Standard, den man meiden sollte, da bereits geknackt.

Rechts unten:
Number of bits in a generated key: 4096
Das ist die Schlüssellänge und je länger der Schlüssel, desto sicherer.
Früher hatte man 2048 Bits, ging dann auf 3072 Bits aber inzwischen ist die Hardware so schnell, dass hier locker auch 4096 Bits verwendet werden kann.
Sollte hier eine kleinere Zahl stehen, kann man die durchaus auf 4096 stellen, was noch lange Zeit ausreichen sollte.

Rechts Richtung Mitte: Button Generate
Damit starten wir die Erzeugung des Schlüssels (Key) per Klick darauf.

Weil auch per CPU agierende Zufallsgeneratoren irgendwie nicht zufällig genug sind, wird bei diesem Programm noch die menschliche "Ungenauigkeit" hinzugezogen und man soll, wie auf dem folgenden Bild zu sehen ist, während der Generierung die Maus wild hin und her bewegen.
Diese menschlichen Bewegungen werden mit einbezogen:

Bild

Man muss nun die Maus solange über das Fenster hin und her bewegen, bis der Fortschrittsbalken komplett am Ende ankommt.
Danach beginnt die Generierung mit den erzeugten Daten:

Bild

Dieser Prozess läuft nun selbstständig durch.
Nach Fertigstellung erscheint folgendes Ergebnis:

Bild

Dieses Bild zeigt oben unter dem Pfeil den neu generierten Schlüssel blau hinterlegt.
Es kann auch sein, dass die blaue Hinterlegung nicht erscheint, das ist aber egal.
Ich kann nicht nachvollziehen, wann diese erfolgt, mal kommt sie nach Generierung, mal nicht.
Ist sie da, kann man per Rechtsklick den Key aus dem Fenster per Rechtsklick gleich in die Zwischenanlage kopieren.
Sollte der Key nicht markiert sein, machen wir das einfach mit der Maus nachträglich, indem wir per Rechtsklick auf den Key klicken und Alle auswählen anklicken, womit der gesamte Key markiert wurde (auch der nicht sichtbare Teil).
Nun lässt sich der Key per Rechtsklick in die Zwischenablage Kopieren.

Da wir den privaten und den öffentlichen Teil später vielleicht nochmal brauchen, speichern wir beide Teile auf den PC in ein Verzeichnis, wo wir beide Teile später bei Bedarf wiederfinden.

Achtung, hier kommt nun der eingekreiste Bereich Key passphrase: und Confirm passphrase ins Spiel.
Hier wird nun das Passwort vergeben, wie es oben in Szenario 3 beschrieben wurde.
Wer beim Zugriff per SSH Key dieses Passwort möchte, gibt dies dort zwei mal (untereinender) ein.
Alle anderen lassen die beiden Felder leer.

Die darüber befindlichen Felder Key fingerprint: und Key comment: können wir so übernehmen.

Hierzu klicken wir auf auf die beiden eingekreisten Buttons Save public key und Save private key und vergeben den beiden Keys die entsprechenden Namen, z.B. public.ppk und private.ppk.
Die Endung .ppk hat sich in der Schlüsselverwaltung etabliert, kann aber auch ganz anders genannt werden.

Sollte man einen der beiden Teile des Keys später wieder benötigen, kann man diese einfach in Puttygen wieder laden.

Nun muss der öffentliche Teil auf den Server (Public Key) in das entsprechende Verzeichnis.
Wenn wir Putty von vorhin noch offen haben, holen wir das Terminalfenster von Putty nach vorne.
Sollte das geschlossen worden sein oder keine Eingaben mehr annehmen (Timeout), dann starten wir Putty einfach neu und loggen uns mit den Benutzer und dem dazugehörigen Passwort wieder ein.

Der Key muss nun in das Verzeichnis des Nutzers, der diesen später als Login nutzt.
Dazu muss ein Verzeichnis mit dem Namen .ssh existieren oder falls nicht, angelegt werden.
Der Punkt vor dem Namen ist wichtig !!

Daher prüfen wir, ob nicht schon ein entsprechendes Verzeichnis existiert.
Da ich den User root nicht empfehle, nehmen wir hier beispielhaft den User pi oder eben jenen, den der bei der Grundinstallation des Raspberry Pi OS angelegt wurde.
Hier für diese Anleitung hatte ich eben pi verwendet.

Um zu prüfen, ob das Verzeichnis existiert, geben wir folgenden Befehl ein:

Code: Alles auswählen

dir ~/.ssh
Die Datei könnte evtl. schon vorhanden sein und sich bereits Keys darin befinden.
In der Regel ist das aber nach einer Neuinstallation nicht der Fall.

Ist das Verzeichnis nicht vorhanden, erscheint folgende Ausgabe:

Code: Alles auswählen

dir ~/.ssh
dir: Zugriff auf '/home/pi/.ssh' nicht möglich: Datei oder Verzeichnis nicht gefunden
In der Ausgabe sehen wir auch den User, mit dem wir uns eingeloggt haben, das ~ ersetzt /home/user/, also ist eine Abkürzung für das Homeverzeichnis des eingeloggten Users.
Sollte ein anderer User verwendet werden, sollte man sich auch mit dem anderen User einloggen, zumal sonst nachher die Benutzerrechte nicht stimmen.

Nach obiger Ausgabe muss also das Verzeichnis .ssh angelegt werden und zwar so:

Code: Alles auswählen

mkdir ~/.ssh
Wurde das Verzeichnis korrekt angelegt und es erscheint kein Fehler (z.B. Verzeichnis existiert bereits u.s.w.), erfolgt keine weitere Ausgabe.

Nun muss eine Datei angelegt werden, die den generierten öffentlichen Key von PuttyGen aufnimmt:

Code: Alles auswählen

nano ~/.ssh/authorized_keys
Erscheint eine Abfrage, welcher Editor zukünftig benutzt werden soll, nehmen wir nano.

Das Fenster in Putty sieht nun so aus:

Bild

Oben im Fenster sehen wir auch den korrekt aufgelösten Pfad: /home/pi/.ssh/authorized_keys
Dort liegt die Datei auch für spätere Änderungen oder Erweiterungen (z.B. andere Geräte mit eigenen Keys).

Der grüne Cursor zeigt die Position im Fenster, also am Anfang der Datei.
Befindet sich der Key noch in der Zwischenablage, transferieren wir ihn mit einem Rechtsklick auf den grünen Cursor.

!! Achtung !!
Wir sehen nach dem Einfügen nur den Schluss des Keys:

Bild

Daher bitte nicht wundern, wenn einem die Zeile extrem kurz vorkommt.
In Nano erfolgt normalerweise kein Zeilenumbruch und daher sehen wir nur den Schluss des eingefügten Inhaltes.

Speichern und Beenden erfolgt durch <STRG>X und der Bestätigung der nachfolgenden Frage mit j oder y.

Nun folgt noch die Rechteanpassung, damit der Key auch sicherer ist und nicht von jedermann darauf zugegriffen werden kann:

Code: Alles auswählen

chmod 600 ~/.ssh/authorized_keys
Wenn wir nun den Verzeichnistest von vorhin machen

Code: Alles auswählen

dir ~/.ssh
sollte jetzt folgende Ausgabe erscheinen:

Code: Alles auswählen

pi@raspberrypi:~ $ dir ~/.ssh
authorized_keys
pi@raspberrypi:~ $
Damit wäre nun der Key sowohl auf dem Server und der entsprechende andere Teil auf dem PC.
Nur mit Beidem kann erfolgreich eine Verbindung aufgebaut werden.

Aber es fehlt noch der private Teil des Keys, welches in Putty noch eingetragen werden muss.
Zuerst loggen wir uns vom Raspberry Pi aus und beenden damit auch Putty:
Dann starten wir Putty erneut, um wieder an die Einstellungen zu kommen.
Dabei müssen wir die zuvor gespeicherte Konfiguration aber erst wieder laden.
Dafür markieren wir den im Kasten neben Load, Save und Delete aufgeführten Eintrag Raspberry Pi aus (oder eir wir die Konfiguration auch genannt haben) und klicken rechts daneben auf den Button Load.
Nach dem Start von Putty wird keine Konfiguration geladen, daher diese Vorgehensweise.

Wurde die Konfiguration eingelesen, müssen wir im Menü links auf den Punkt Connection/Data klicken und oben im Feld Auto-login username Euren User (hier pi) eintragen:

Bild

Dies dient dazu, dass Putty nachher beim Login per Key nicht nach dem User fragt.

Dann wechseln wir links im Menü auf den Punkt Connection/SSH/Auth/Credentials:

Bild

Neben dem Feld für Private key file for authentification klicken wir auf Browse und wählen im Dateiexplorer die bei der Generierung des Keys gespeicherte Datei für den privaten Schlüssel (weiter oben im Beispiel private.ppk benannt.

Steht der Pfad und die eingebundene Datei im Feld, gehen wir in Putty im linken Menü wieder ganz nach oben und klicken auf den Eintrag Session (ggf. nach oben scrollen), um wieder das Startbild zu sehen.
Jetzt klicken wir rechts neben dem Konfigurationsauswahlfenster auf Save und somit ist der Key für die Zukunft verbunden.

Zum Test klicken wir nun noch unten auf den Button Open.

Wer keine Passphrase für den Key gesetzt hat, wird nun direkt eingeloggt und landet automatisch im System des Pi:

Bild

Dort sind der User und auch der Public Key Comment (aus PuttyGen) zu sehen.

Wer die Passphrase gesetzt hat, wird zuerst nach dieser gefragt, bevor er eingeloggt wird.
Im Gegensatz zum normalen Passwortlogin wird hier das Passwort (Passphrase) des Keys abgefragt.

An diesem Punkt haben wir nun zuerst nur das Szenario 1 erledigt, bei dem Key und Passwort (nicht vom Key) gleichzeitig aktiv sind.
Zwar wird immer erst nach einem Key gesucht, wenn wir am PC mit dem Key sind, jedoch alle anderen Geräte können nach wie vor per normalem Userpasswort einloggen.

Um das zu verhindern, deaktivieren wir die Passwortabfrage des SSH Systems, indem wir die passende Konfigurationsdatei ändern:

Code: Alles auswählen

sudo nano /etc/ssh/sshd_config
Das sudo erzwingt root Rechte, da nur der Root dort agieren darf und ihm diese Datei gehört.

Bild

Das ist nur ein kleiner Ausschnitt, der angezeigt wird, dort müssen wir für einige Einstellungen scrollen:

#Port 22
Wer Port 22 weiterhin benutzen möchte, lässt die Einstellung so, Putty hat Port 22 voreingestellt.
Es empfiehlt sich aber immer, diesen Port abzuändern, hier im Beispiel nehmen wir mal 101010.

Das sieht dann so aus:
Port 101010
Wichtig: Das # am Anfang der Zeile vor der Änderung muss weg !!
Sonst wird die Zeile nicht aktiv.

Bitte auch daran denken, dass in der Putty Konfiguration für Raspberry Pi der Port 101010 auch den Wert 22 überschreibt.
Also Putty starten, Session Raspberry Pi per Load laden, den Port 22 löschen und 101010 eintragen, Save klicken und mit Open starten.
Aber erst nachdem der neue Port bereits auf dem Pi läuft !!

Bevor wir aber speichern und beenden, ändern wir noch weitere Einträge:

PermitRootLogin no
Diesen Wert ändern wir gleich mit, sofern es nicht schon in der Grundinstallation erledigt wurde.
Der hier gezeigte Wert ist bereits geändert und falls kein no drin steht und ein # davor, darauf abändern.
Dann hat der Root Zugriff auch keine Chance, wenn wir den Key wieder entfernen und auf Passworteingabe zurückstellen.

#PubkeyAuthentication yes
Dieser Eintrag muss nicht aktiviert werden und kann so bleiben (mit # davor), da das sowieso die Grundeinstellung ist.

#PasswordAuthentication yes
Hier muss das # davor weg und auf no gestellt werden, also:
PasswordAuthentication no

Es gibt sicherlich noch weitere Einstellungen, die das Ganze noch sicherer machen aber ich denke, dieser Grundstock an Änderungen sollte das Minimum sein, wenn man den Pi ins Internet hängt.

Wir speichern und beenden die Datei per <STRG>X und starten den SSH Dienst neu:

Code: Alles auswählen

sudo service ssh restart
Läuft alles glatt, erscheint keine weitere Ausgabe.

Nun sind alle unsere Änderungen aktiv, was wir auch gleich testen wollen.
Dazu verlassen wir den Pi in Putty wieder per
Für den Test starten wir Putty erneut, laden aber KEINE Konfiguration, sondern geben oben bei Host Name (or IP adress) einfach den von Euch vergebenen Hostnamen an (hier also raspberrypi) oder die IP Adresse Eures Pis, den geänderten Port, falls geändert (sonst 22 lassen) und klicken unten auf Open.
Hier müssen wir diesmal die Grunddaten manuell angeben, sonst wird wieder der Key automatisch geladen.

Ist alles korrekt konfiguriert, erhaltet Ihr nach der Eingabe Eurer Userdaten vom früheren Passwortlogin folgende Fehlermeldung:

Bild

An diesem Punkt haben wir nun Szenario 2 und wer die zusätzliche Passphrase für den Key nutzt, hat mit Szenario 3 die höchste Sicherheit der drei Szenarios.

Generell wäre eine weitere und bessere Zugriffsmöglichkeit per VPN.
Dies erfordert aber weitreichendere Konfigurationen, bestenfalls über den eigenen Router, sofern dieser dazu in der Lage ist.

Für etwaige Hinweise auf Verbesserungen, Fehler oder Fehlendes, Meinungen und Erfahrungsaustausch, bitte gerne einen Eintrag unter der Anleitung hinterlassen.


Fortsetzungen, Korrekturen, Änderungen möglich ....

Copyright © 2024 by RasPiFun.de
;) Gruß Outi :D
Antworten