SSH in einer typischen Administrationssituation
Ein Webhoster nennt einen SSH-Zugang, ein Administrator verbindet sich mit einem Linux-Server oder ein NAS bietet für Wartungsaufgaben einen Terminalzugriff an. In solchen Situationen geht es meist nicht um eine ferngesteuerte Desktop-Oberfläche, sondern um eine textbasierte Verbindung zu einem entfernten System.
SSH steht für Secure Shell und ist ein Protokoll für verschlüsselten Zugriff auf entfernte Systeme, häufig über eine Kommandozeile. Darüber lassen sich Server verwalten, Dateien übertragen, Git-Repositorys erreichen oder geschützte Verbindungen für bestimmte Dienste aufbauen.
SSH ist dabei weder eine konkrete Shell noch ein Terminalprogramm. Das Protokoll stellt die geschützte Verbindung bereit. Das Terminal ist die Bedienoberfläche auf dem eigenen Gerät, während die Shell auf dem entfernten System Befehle entgegennimmt und verarbeitet. Eine grafische Fernwartung zeigt dagegen typischerweise einen entfernten Desktop und folgt einem anderen Bedienmodell.
Die interaktive Kommandozeile ist nur ein Einsatzbereich. Über SSH können auch Dateiübertragungen, Tunnel für bestimmte Netzwerkverbindungen und Zugriffe auf Git-Repositorys abgewickelt werden. Welche Funktionen verfügbar sind, hängt vom entfernten System und dessen Konfiguration ab.
So entsteht eine SSH-Verbindung: Client, Server, Konto und Shell
Am Anfang steht ein SSH-Client. Das ist ein Programm auf dem eigenen Computer, Smartphone oder einem anderen Gerät, das eine Verbindung anfragt. Auf dem Zielsystem läuft der SSH-Server: ein Dienst, der solche Anfragen annimmt, sofern er gestartet, über das Netzwerk erreichbar und für den betreffenden Zugang freigegeben ist.
Damit die Anfrage das richtige System erreicht, benötigt der Client einen Hostnamen oder eine IP-Adresse. Hinzu kommen der Benutzername des Kontos auf dem Zielsystem und der vorgesehene Port. Port 22 ist der Standardport für SSH, aber keine unveränderliche Vorgabe. Hoster, Unternehmen oder Gerätehersteller können einen anderen Port vorsehen.
Der Benutzername bezeichnet ein konkretes Konto auf dem entfernten System. Er muss nicht mit dem Namen des lokalen Rechnerkontos, einer E-Mail-Adresse oder dem Login für eine Verwaltungsoberfläche übereinstimmen. Selbst wenn Server und Port korrekt sind, kann eine Anmeldung deshalb am falschen Benutzernamen scheitern.
Terminal, Shell und Berechtigungen
Das Terminal stellt Ein- und Ausgaben dar. Nach einer erfolgreichen SSH-Anmeldung erscheint darin häufig eine Shell des entfernten Systems. Sie verarbeitet eingegebene Befehle und zeigt deren Ausgaben an. SSH transportiert diese Daten verschlüsselt zwischen Client und Server, ist aber nicht selbst die Shell.
Die Sitzung läuft im Kontext des angemeldeten Benutzerkontos. Häufig beginnt sie im Home-Verzeichnis dieses Kontos, also in dessen persönlichem Bereich im Dateisystem. Welche Dateien gelesen oder verändert und welche Befehle ausgeführt werden dürfen, bestimmen die Berechtigungen des Systems. Eine erfolgreiche SSH-Anmeldung bedeutet daher nicht automatisch, dass das Konto über administrative Rechte verfügt.
Anmeldung mit Passwort oder Schlüsselpaar
Bei der Passwortanmeldung weist sich der Nutzer mit einem zum Serverkonto gehörenden Passwort aus. Ob diese Methode angeboten wird, hängt von der Konfiguration des Servers und den Vorgaben des Betreibers ab. Ein Passwort für eine Kunden- oder Geräteoberfläche ist nicht zwangsläufig zugleich das SSH-Passwort.
Bei der Schlüsselanmeldung gehören ein öffentlicher und ein privater Schlüssel zusammen. Der öffentliche Schlüssel kann dem Benutzerkonto auf dem Server zugeordnet werden. Der private Schlüssel bleibt beim Nutzer, wird nicht an den Server oder an Supportstellen weitergegeben und muss besonders geschützt werden. Der Server prüft bei der Anmeldung, ob der Nutzer den passenden privaten Schlüssel nachweisen kann, ohne dass dieser übertragen werden muss.
Eine Passphrase kann den privaten Schlüssel zusätzlich schützen. Sie verschlüsselt beziehungsweise schützt dessen lokale Nutzung und ist nicht mit dem Passwort des Serverkontos gleichzusetzen. Auch eine Schlüsselanmeldung bietet keine automatische Sicherheitsgarantie: Entscheidend bleiben unter anderem der Schutz des privaten Schlüssels, die Serverkonfiguration und der sorgfältige Umgang mit Warnungen.
Zwei getrennte Prüfungen schaffen Vertrauen
Beim Verbindungsaufbau sind Serverauthentisierung und Benutzerauthentisierung zu unterscheiden. Zunächst präsentiert der SSH-Server einen Host-Key. Dessen Fingerprint ist eine kompakte Prüfdarstellung des Schlüssels. Wird der Fingerprint über eine unabhängige, vertrauenswürdige Quelle bestätigt, lässt sich die Gegenstelle belastbar zuordnen.
Beim ersten Kontakt kennt der Client den Host-Key in der Regel noch nicht. Wird er ohne unabhängigen Vergleich gespeichert, entsteht zunächst vor allem eine Vergleichsbasis für spätere Verbindungen. Viele Clients halten bereits gesehene Zuordnungen von Zielsystemen und Host-Keys lokal in known_hosts fest. Ändert sich der präsentierte Schlüssel später, kann der Client davor warnen.
Erst danach weist sich der Nutzer gegenüber dem Server aus, etwa mit einem Passwort oder einem Schlüsselpaar. Der Host-Key betrifft somit die Identität des Servers; Passwort oder Benutzerschlüssel betreffen das Konto des Nutzers. Eine erfolgreiche Anmeldung ersetzt nicht die Prüfung der Serveridentität, und ein bestätigter Host-Key garantiert nicht, dass ein bestimmtes Benutzerkonto zugelassen ist.
Dateiübertragung, typische Einsatzfelder und Sicherheitsbegriffe
SSH und SFTP sind nicht dasselbe
SFTP dient der verschlüsselten Dateiübertragung über SSH. Es ist nicht lediglich FTP unter einem anderen Namen und auch keine bloße Umbenennung des klassischen FTP-Protokolls. SFTP nutzt die geschützte SSH-Verbindung und deren Mechanismen zur Server- und Benutzerprüfung, konzentriert sich aber auf das Übertragen und Verwalten von Dateien.
Ein Anbieter kann deshalb sowohl von einem SSH- als auch von einem SFTP-Zugang sprechen. Die Zieladresse, das Benutzerkonto und die Schlüssel können dabei zusammenhängen, während die verwendeten Programme und erlaubten Funktionen unterschiedlich sind. Ein freigegebener SFTP-Zugang bedeutet nicht zwingend, dass auch eine interaktive Shell verfügbar ist.
Typische Aufgaben über SSH
- Server aktualisieren: Administratoren können vorgesehene Aktualisierungen auf einem entfernten System ausführen und deren Rückmeldungen verfolgen.
- Konfigurationen bearbeiten: Dienste und Anwendungen werden häufig über textbasierte Konfigurationsdateien verwaltet. Änderungen setzen entsprechende Berechtigungen und Kenntnisse voraus.
- Logs lesen: Protokolldateien helfen dabei, den Zustand von Anwendungen, Diensten oder Systemkomponenten zu beurteilen.
- Dienste verwalten: Autorisierte Konten können Dienste prüfen oder neu starten, sofern das Berechtigungskonzept dies vorsieht.
- Git-Repositorys erreichen: Entwicklungsumgebungen nutzen SSH häufig, um Nutzer gegenüber einer Git-Plattform oder einem eigenen Repository-Server zu authentisieren.
- Webprojekte bereitstellen: Dateien, Abhängigkeiten und serverseitige Abläufe eines Webprojekts lassen sich über freigegebene SSH- oder SFTP-Zugänge verwalten.
- Raspberry Pi administrieren: Ein Einplatinencomputer kann ohne dauerhaft angeschlossenen Bildschirm über das Netzwerk gewartet werden.
- NAS-Systeme verwalten: Manche NAS-Geräte bieten SSH für Wartungs- oder Diagnoseaufgaben. Der Funktionsumfang ist hersteller- und konfigurationsabhängig.
Darüber hinaus kann SSH verschlüsselte Tunnel für bestimmte Netzwerkverbindungen bereitstellen. Welche Weiterleitungen erlaubt und sinnvoll sind, richtet sich nach der jeweiligen Umgebung. Auch hier ist SSH der geschützte Transportweg und nicht der weitergeleitete Dienst selbst.
Wichtige Sicherheitsbegriffe im Zusammenhang
Fingerprint und known_hosts: Der Fingerprint ist eine kompakte Darstellung eines Host-Keys und lässt sich mit einer vertrauenswürdigen Referenz vergleichen. In known_hosts speichert der Client üblicherweise bereits gesehene Server-Host-Keys. Die Sammlung hilft, unerwartete Änderungen bei späteren Verbindungen zu erkennen; sie ersetzt bei einem ersten Kontakt jedoch keine unabhängige Prüfung.
Passphrase: Eine Passphrase schützt den privaten Schlüssel zusätzlich auf dem Gerät des Nutzers. Sie ist weder der öffentliche Schlüssel noch das Passwort des Serverkontos. Ihr Nutzen hängt auch davon ab, wie der private Schlüssel und das verwendete Gerät insgesamt geschützt sind.
Root-Login und sudo: root bezeichnet auf vielen Unix- und Linux-Systemen das Konto mit umfassenden administrativen Rechten. Ein direkter Root-Login über SSH kann bewusst deaktiviert sein. sudo steht dagegen für eine kontrollierte Rechteerweiterung aus einem anderen Konto heraus, sofern dieses dafür autorisiert wurde. Welche Vorgehensweise vorgesehen ist, bestimmt die jeweilige Systemkonfiguration.
Firewall und Fail2ban: Eine Firewall kontrolliert Netzwerkverkehr und kann festlegen, aus welchen Netzen oder zu welchen Diensten Verbindungen möglich sind. Fail2ban kann wiederholte auffällige oder fehlgeschlagene Zugriffsversuche erkennen und zeitweise Sperren veranlassen. Beide Mechanismen ergänzen den SSH-Schutz, garantieren aber weder für sich allein noch gemeinsam die Sicherheit eines Systems.
Zwei-Faktor-Authentifizierung: Ein zusätzlicher Faktor kann neben Passwort oder Schlüssel einen weiteren Nachweis verlangen. Ob und wie dies unterstützt wird, hängt vom Server, der Anmeldemethode und der administrativen Umgebung ab. Auch dieser Mechanismus ersetzt nicht den Schutz der Konten, Schlüssel und Endgeräte oder die Prüfung des Host-Keys.
SSH-Fehler sicher einordnen: von Permission denied bis Host-Key-Warnung
Eine SSH-Meldung zeigt meist, in welcher Phase der Verbindungsaufbau scheitert. Sie liefert jedoch selten schon eine eindeutige Ursache. Die folgende Übersicht trennt deshalb Erreichbarkeit, SSH-Dienst, Serveridentität, Benutzeranmeldung und Berechtigungen voneinander.
| Was Sie sehen | Wo die Verbindung vermutlich scheitert | Was sich gefahrlos prüfen lässt | Wann Sie nicht fortfahren sollten |
|---|---|---|---|
| Die Verbindung wird abgelehnt beziehungsweise mit „Connection refused“ beendet. | SSH-Dienst und Port: Die Gegenstelle antwortet, nimmt am angegebenen Port aber keine SSH-Verbindung an. Der Dienst kann gestoppt sein, an einem anderen Port lauschen oder für dieses Ziel nicht angeboten werden. | Hostname beziehungsweise IP-Adresse und Port mit den offiziellen Zugangsdaten abgleichen. Bei einem verwalteten Server, NAS oder Webhosting-Angebot lässt sich außerdem prüfen, ob SSH dort aktiviert und aktuell verfügbar ist. | Nicht mit wechselnden Ports oder Zugangsdaten experimentieren, wenn das Zielsystem nicht eindeutig feststeht oder der Anbieter keinen SSH-Zugang bestätigt. |
| Der Verbindungsversuch endet nach längerer Wartezeit mit einer Zeitüberschreitung. | Netzwerk und Zieladresse: Das Ziel antwortet nicht rechtzeitig. Möglich sind eine falsche Adresse, ein nicht erreichbares Netz, eine Filterung oder ein ausgeschaltetes System. | Die Zieladresse mit einer verlässlichen Quelle vergleichen und klären, ob der Server grundsätzlich online sowie aus dem verwendeten Netz erreichbar sein soll. | Nicht von einem Anmeldefehler ausgehen oder Zugangsdaten unnötig ändern. Bei einer unbestätigten Zieladresse sollte zunächst die zuständige Stelle eingebunden werden. |
| Der Server beziehungsweise Host wird als nicht erreichbar gemeldet. | Netzwerk und Zieladresse: Der Rechner kann das Ziel nicht erreichen oder den angegebenen Hostnamen nicht auflösen. Auch eine fehlende vorgesehene Verbindung zu einem internen Netz kommt infrage. | Schreibweise des Hostnamens, aktuelle Anbieterangaben und erforderliche Netzvoraussetzungen prüfen. Verantwortliche können bestätigen, ob der Zugang nur aus einem bestimmten Netz vorgesehen ist. | Nicht eigenmächtig auf ähnlich klingende Hostnamen oder fremde IP-Adressen ausweichen. |
| Die Angaben wirken korrekt, dennoch kommt am gewählten Port keine SSH-Verbindung zustande. | SSH-Dienst und Port: Port 22 ist lediglich der Standard. Der konkrete Zugang kann einen anderen Port verwenden, oder die vorhandene Angabe kann veraltet sein. | Den Port ausschließlich mit der Dokumentation des Hosters, einer authentisierten Verwaltungsoberfläche oder den zuständigen Verantwortlichen abgleichen. | Nicht wahllos Ports durchprobieren. Das liefert keine verlässliche Diagnose und kann betrieblichen Vorgaben widersprechen. |
| Mit einem Benutzernamen erscheint „Permission denied“, während ein anderer Kontoname vorgesehen sein könnte. | Benutzeranmeldung: Der verwendete Benutzername bezeichnet möglicherweise kein zugelassenes Konto auf dem Zielsystem oder ist nicht für SSH freigeschaltet. | Groß- und Kleinschreibung sowie den vorgesehenen Kontonamen anhand der offiziellen Zugangsdaten prüfen. Der Benutzername des lokalen Rechners muss nicht dem Serverkonto entsprechen. | Nicht fortfahren, wenn unklar ist, welches Konto zugeordnet wurde. Keine fremden oder lediglich vermuteten Kontonamen testen. |
| Die Anmeldung endet allgemein mit „Permission denied“. | Benutzeranmeldung: Der Server weist die Anmeldung ab. Ursache kann ein falscher Benutzername, eine nicht akzeptierte Anmeldemethode, ein unpassender Schlüssel, ein falsches Passwort oder eine fehlende Anmeldeberechtigung sein. | Benutzerkonto, vorgesehene Methode und bereitgestellte Zugangsdaten getrennt abgleichen. Die Meldung allein beweist nicht, dass lediglich das Passwort falsch ist. | Nicht wiederholt Zugangsdaten ausprobieren, wenn eine Kontosperre möglich ist oder Herkunft und Gültigkeit der Daten unklar sind. |
| Die Schlüsselanmeldung schlägt fehl, obwohl eine Schlüsseldatei vorhanden ist. | Benutzeranmeldung: Der Client kann den falschen privaten Schlüssel verwenden, der passende öffentliche Schlüssel kann auf dem Server fehlen oder das Konto akzeptiert diese Methode nicht. | Prüfen, welcher private Schlüssel laut eigener Dokumentation zu diesem Konto gehört, und die Zuordnung durch den Hoster oder die Administration bestätigen lassen. Der private Schlüssel wird dabei nicht weitergegeben. | Nicht fortfahren, wenn die Schlüsseldatei aus unbekannter Quelle stammt, unerwartet ausgetauscht wurde oder Dritte die Herausgabe des privaten Schlüssels verlangen. |
| Die Verbindung funktioniert nur aus bestimmten Netzen oder bricht bereits vor der Anmeldung ab. | Netzwerk und Zieladresse: Eine lokale, netzseitige, serverseitige oder vom Anbieter betriebene Firewall kann den Zugriff begrenzen. Auch betriebliche Freigaben können an bestimmte Netze gebunden sein. | Klären, aus welchem Netz der Zugang vorgesehen ist und ob eine bekannte Störung oder Zugriffsbeschränkung besteht. Zuständige Stellen können Protokolle und Freigaben kontrolliert prüfen. | Keine Filter oder Sicherheitsvorgaben umgehen. Bei einer unbekannten Blockade sollte die Ursache administrativ geklärt werden. |
Die direkte Anmeldung als root wird abgewiesen, ein reguläres Konto ist jedoch vorgesehen. |
Benutzeranmeldung: Der direkte Root-Login kann bewusst deaktiviert sein. Das ist nicht automatisch ein Defekt des SSH-Dienstes. | In den offiziellen Zugangsinformationen prüfen, ob zunächst ein persönliches oder administratives Standardkonto verwendet werden soll. Erweiterte Rechte können in der Umgebung getrennt geregelt sein. | Nicht versuchen, die Sperre über andere Konten oder nicht freigegebene Methoden zu umgehen. |
| Beim ersten Kontakt wird ein bislang unbekannter Host-Key oder Fingerprint angezeigt. | Serveridentität: Für dieses Ziel ist lokal noch kein bekannter Host-Key in known_hosts hinterlegt. Das kann bei einer echten Erstverbindung normal sein, bestätigt den Server aber noch nicht von selbst. |
Den angezeigten Fingerprint über eine unabhängige, vertrauenswürdige Quelle vergleichen, etwa eine authentisierte Anbieteroberfläche oder eine bestätigte Auskunft der zuständigen Administration. | Nicht bestätigen, wenn der Fingerprint nicht verifiziert werden kann, die Zieladresse zweifelhaft ist oder die Warnung unerwartet bei einem vermeintlich bekannten System erscheint. |
| SSH warnt, dass sich der Host-Key eines bereits bekannten Servers geändert hat. | Serveridentität: Der aktuelle Host-Key passt nicht zu dem in known_hosts gespeicherten Schlüssel. Eine Neuinstallation kann das erklären; ebenso kommen eine falsche Zieladresse oder ein Manipulationsversuch infrage. |
Die Verbindung zunächst unterbrechen. Zieladresse und Fingerprint über einen getrennten vertrauenswürdigen Kanal mit dem Hoster oder den Verantwortlichen bestätigen lassen. | Nicht fortfahren, solange die Änderung nicht nachvollziehbar bestätigt wurde. Der bekannte Eintrag sollte nicht allein deshalb ungeprüft überschrieben oder entfernt werden. |
| Die Anmeldung gelingt, ein Befehl oder der Zugriff auf eine Datei wird danach verweigert. | Berechtigung nach der Anmeldung: Die SSH-Sitzung besteht, doch das angemeldete Konto besitzt für die betreffende Datei, das Verzeichnis oder die administrative Aktion nicht die erforderlichen Rechte. | Kontozweck, Dateizuständigkeit und vorgesehene Rechte mit der Systemdokumentation oder Administration abgleichen. Eine erfolgreiche Anmeldung verleiht nicht automatisch Vollzugriff. | Nicht versuchen, bestehende Berechtigungsgrenzen zu umgehen. Änderungen an produktiven Systemen gehören in einen autorisierten administrativen Ablauf. |
Die Verbindungsphase entscheidet über die Einordnung
Bleibt bereits die Netzwerkverbindung aus, sind Passwort und Schlüssel noch gar nicht beteiligt. Antwortet das Ziel, nimmt aber am angegebenen Port keine SSH-Verbindung an, liegt der Schwerpunkt eher beim SSH-Dienst oder bei der Portangabe. Erst danach folgen die Prüfung der Serveridentität und die Anmeldung des Benutzers. Eine verweigerte Dateioperation nach erfolgreichem Login gehört wiederum in eine spätere Phase: Sie betrifft die Rechte des angemeldeten Kontos.
Für den Vertrauensaufbau sind zwei Richtungen zu unterscheiden. Der Host-Key weist den entfernten Server gegenüber dem Client aus. Passwort oder Schlüsselpaar weisen anschließend den Nutzer gegenüber dem Server aus. Eine erfolgreiche Benutzerauthentisierung ersetzt daher nicht die Prüfung des Host-Keys; umgekehrt sagt ein bestätigter Server-Fingerprint noch nichts darüber aus, ob das verwendete Konto zugelassen ist.
Warum ein geänderter Host-Key besondere Aufmerksamkeit verlangt
Angenommen, ein Webserver wurde nach einem Defekt vollständig neu installiert. Bei der Neuinstallation erhält der SSH-Dienst neue Host-Keys. Obwohl der Hostname gleich geblieben ist, stimmt der aktuelle Host-Key nun nicht mehr mit dem lokal in known_hosts gespeicherten Schlüssel überein. Die Warnung ist in diesem Fall technisch korrekt und kann eine legitime Ursache haben.
Dieselbe Warnung kann jedoch entstehen, wenn eine falsche oder veraltete Zieladresse zu einem anderen Rechner führt. In einem ungünstigeren Fall könnte sich ein fremdes System als das erwartete Ziel ausgeben. Aus der Warnung allein lässt sich nicht erkennen, welche Erklärung zutrifft. Deshalb sollte die Verbindung pausieren, bis der neue Fingerprint über einen unabhängigen, vertrauenswürdigen Kanal bestätigt wurde. Erst die nachvollziehbare Bestätigung der Neuinstallation oder eines geplanten Schlüsseltauschs löst den Widerspruch auf.
Häufige Fragen zu SSH
Was bedeutet SSH?
SSH steht für Secure Shell. Gemeint ist ein Protokoll für verschlüsselten Zugriff auf entfernte Systeme, häufig über eine Kommandozeile.
Wofür nutzt man SSH?
SSH dient vor allem der entfernten Administration von Servern, NAS-Systemen und Einplatinencomputern. Darüber können außerdem Dateiübertragungen, Git-Zugriffe und Tunnelverbindungen abgewickelt werden.
Was ist ein SSH-Schlüssel?
Für die Benutzeranmeldung wird ein Schlüsselpaar eingesetzt: Der öffentliche Schlüssel kann beim Benutzerkonto auf dem Server hinterlegt werden, während der private Schlüssel beim Nutzer bleibt. Der private Teil muss besonders geschützt und darf nicht weitergegeben werden.
Was ist der Unterschied zwischen SSH und SFTP?
SSH stellt den geschützten Verbindungsrahmen für Fernzugriffe bereit. SFTP ist ein darauf aufbauendes Protokoll für verschlüsselte Dateiübertragung und nicht lediglich FTP unter einem anderen Namen.
Was bedeutet Permission denied?
Die angeforderte Anmeldung oder Aktion wurde verweigert. Bei der Anmeldung kommen unter anderem ein falsches Konto, eine nicht akzeptierte Methode, ein unpassender Schlüssel, ein falsches Passwort oder eine fehlende Zugangsberechtigung infrage. Nach dem Login kann die Meldung stattdessen fehlende Datei- oder Verwaltungsrechte betreffen.
Warum warnt SSH vor einem geänderten Host-Key?
Der Server präsentiert einen anderen Host-Key als den für dieses Ziel gespeicherten. Das kann nach einer legitimen Neuinstallation vorkommen, aber auch auf eine falsche Zieladresse oder einen Manipulationsversuch hindeuten. Der neue Fingerprint sollte deshalb unabhängig bestätigt werden.
Ist SSH sicher?
SSH verschlüsselt die Verbindung und unterstützt die Prüfung von Server und Nutzer. Die tatsächliche Sicherheit hängt dennoch von der Konfiguration, geschützten Schlüsseln und Konten, einer verlässlichen Host-Key-Prüfung, passenden Berechtigungen sowie der Sicherheit der beteiligten Geräte ab.
Warum ist SSH eher für Fortgeschrittene?
SSH eröffnet häufig direkten Zugriff auf Systemdateien, Dienste und administrative Funktionen, ohne eine grafische Oberfläche als Orientierung. Befehle wirken mit den Rechten des angemeldeten Kontos und können weitreichende Folgen haben. Sichere Nutzung setzt daher ein Verständnis von Zielsystem, Konten, Berechtigungen und Vertrauensmeldungen voraus.
SSH ist ein verschlüsseltes Protokoll für entfernte Administration, aber kein Ersatzbegriff für jedes Terminalfenster und keine grafische Fernsteuerung. Entscheidend ist das Zusammenspiel aus erreichbarem SSH-Server, passendem Client, korrekter Zieladresse, Benutzerkonto, Berechtigungen und verlässlicher Serverprüfung.
Wer Host-Key, Fingerprint, known_hosts und Schlüsselpaar auseinanderhält, kann typische Meldungen ruhiger bewerten. Besonders Host-Key-Warnungen verdienen Aufmerksamkeit: Eine legitime Änderung ist möglich, sollte aber über eine vertrauenswürdige Quelle bestätigt werden, bevor die Verbindung fortgesetzt wird.
Werbung
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten