ssh (Shell-Befehl): Unterschied zwischen den Versionen
Michi (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Michi (Diskussion | Beiträge) |
||
(45 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
Der [[Shell-Befehl]] <b>ssh</b> (secure shell) ist ein | Der [[Shell-Befehl]] <b>ssh</b> (secure shell) ist ein SSH-Client und Teil des Pakets <b>Openssh</b>, das unter anderem auch den SSH-Server <b>sshd</b> enthält. Das Paket Openssh bietet alles, was für verschlüsselte Verbindungen über das [[Netzwerkprotokoll]] [[Secure Shell]] / SSH benötigt wird. | ||
{| class=wikitable | {| class=wikitable | ||
Zeile 27: | Zeile 25: | ||
Der Openssh-Client "ssh" ist in den meisten Linux-Distributionen bereits vorinstalliert, während der Openssh-Server "sshd" (aus dem Paket "openssh") meist nachträglich eingerichtet werden muss, falls von anderen Rechnern aus auf den lokalen Rechner zugegriffen werden soll. | Der Openssh-Client "ssh" ist in den meisten Linux-Distributionen bereits vorinstalliert, während der Openssh-Server "sshd" (aus dem Paket "openssh") meist nachträglich eingerichtet werden muss, falls von anderen Rechnern aus auf den lokalen Rechner zugegriffen werden soll. | ||
Grafische Oberflächen: [[ | Grafische Oberflächen: Cxsshadmin, [http://sourceforge.net/projects/gstm/files/ Gnome SSH Tunnel Manager / GSTM], kssh, [[Putty]], [http://secpanel.net/ Secpanel], Sshterm (kommerziell), [http://www.subakutty.net/tunnelmanager/ Tunnel Manager] | ||
[http://www.harding.motd.ca/autossh/ autossh] überwacht bestehende SSH-Verbindungen und baut sie nach einem Zusammenbruch automatisch neu auf. | [http://www.harding.motd.ca/autossh/ autossh] überwacht bestehende SSH-Verbindungen und baut sie nach einem Zusammenbruch automatisch neu auf. | ||
Zeile 33: | Zeile 31: | ||
== Funktionsweise == | == Funktionsweise == | ||
Auf einem Rechner läuft der SSH-Server "sshd". Er lauscht standardmässig an TCP-Port 22 auf eingehende Verbindungen. Der SSH-Client "ssh" verbindet sich mit dem Server auf diesem Port. Beim Verbindungsaufbau geschieht im Hintergrund folgendes. | Auf einem entfernten Rechner läuft der SSH-Server "sshd". Er lauscht standardmässig an TCP-Port 22 auf eingehende Verbindungen. Der SSH-Client "ssh" verbindet sich mit dem Server auf diesem Port. Beim Verbindungsaufbau geschieht im Hintergrund folgendes, was mit dem Befehl "ssh -vvv" detailliert mitverfolgt werden kann. | ||
1. SSH-Server und -Client verhandeln, welche [[Secure Shell / SSH (Netzwerkprotokoll)/Protokollversion|Protokollversion]] sie für die Kommunikation verwenden - zur Zeit stehen die Varianten SSH 1 und SSH 2 zur Verfügung, wobei SSH 2 viel sicherer und seit einiger Zeit als Standard eingestellt ist. | 1. SSH-Server und SSH-Client verhandeln, welche [[Secure Shell / SSH (Netzwerkprotokoll)/Protokollversion|Protokollversion]] sie für die Kommunikation verwenden - zur Zeit stehen die Varianten SSH 1 und SSH 2 zur Verfügung, wobei SSH 2 viel sicherer und seit einiger Zeit als Standard eingestellt ist. | ||
2. SSH-Server und -Client handeln den Verschlüsselungsalgorithmus aus | 2. SSH-Server und SSH-Client handeln den Verschlüsselungsalgorithmus aus. | ||
3. SSH-Server und -Client handeln den Schlüssel aus, den beide für diesen Datentransfer verwenden. Der Schlüssel gilt einmalig für diese Kommunikation und beide vernichten ihn nach dem Verbindungsende. Für längere Verbindungen ändert sich der Schlüssel zusätzlich in regelmässigen Abständen, standardmässig stündlich. | 3. SSH-Server und SSH-Client handeln den Schlüssel aus, den beide für diesen Datentransfer verwenden. Der Schlüssel gilt einmalig für diese Kommunikation und beide vernichten ihn nach dem Verbindungsende. Für längere Verbindungen ändert sich der Schlüssel zusätzlich in regelmässigen Abständen, standardmässig stündlich. | ||
Beim ersten Login kennt der SSH-Client den Rechnerschlüssel des Servers noch nicht und verlangt deshalb eine Bestätigung vor der Verbindungsaufnahme. | Beim ersten Login kennt der SSH-Client den Rechnerschlüssel des Servers noch nicht und verlangt deshalb eine Bestätigung vor der Verbindungsaufnahme. | ||
Zeile 53: | Zeile 51: | ||
Hier hilft nur, den betreffenden Fingerabdruck aus der Datei "~/.ssh/known_hosts" zu löschen und den neuen Schlüssel zu akzeptieren. Dieses Verhalten wird über die Variable "StrictHostKeyChecking" in der SSH-Client-Konfigurationsdatei "ssh_config" konfiguriert. | Hier hilft nur, den betreffenden Fingerabdruck aus der Datei "~/.ssh/known_hosts" zu löschen und den neuen Schlüssel zu akzeptieren. Dieses Verhalten wird über die Variable "StrictHostKeyChecking" in der SSH-Client-Konfigurationsdatei "ssh_config" konfiguriert. | ||
=== Public-Key-Authentication === | === Public-Key-Authentication === | ||
Zeile 68: | Zeile 58: | ||
1. Mit "ssh-keygen" wird ein [[RSA]]-Schlüsselpaar von 1024 Bit Länge generiert. Ein RSA-Schlüssel eignet sich für beide SSH-Protokollversionen. Die Schlüssellänge sollte aus Sicherheitsgründen 1024 Bit nicht unterschreiten. | 1. Mit "ssh-keygen" wird ein [[RSA]]-Schlüsselpaar von 1024 Bit Länge generiert. Ein RSA-Schlüssel eignet sich für beide SSH-Protokollversionen. Die Schlüssellänge sollte aus Sicherheitsgründen 1024 Bit nicht unterschreiten. | ||
$ <b> ssh-keygen -b 1024 -t rsa</b> | $ <b>ssh-keygen -b 1024 -t rsa</b> | ||
2. Die Software meldet daraufhin, dass sie ein Schlüsselpaar mit einem öffentlichen und einem privaten Schlüssel nach dem RSA-Verfahren erzeugt | 2. Die Software meldet daraufhin, dass sie ein Schlüsselpaar mit einem öffentlichen und einem privaten Schlüssel nach dem RSA-Verfahren am angegebenen Ort erzeugt (standardmässig unter "~.ssh/id_rsa" bzw. "~.ssh/id_rsa.pub"). | ||
3. Die Abfrage nach dem Passwort wird zweimal mit RETURN bestätigt (es wird also kein Passwort eingegeben). | 3. Die Abfrage nach dem Passwort wird zweimal mit RETURN bestätigt (es wird also kein Passwort eingegeben). | ||
Zeile 76: | Zeile 66: | ||
4. Das Programm sagt nun, in welchen Dateien es die Daten ablegt und zeigt den Fingerabdruck des neuen Schlüssels an. | 4. Das Programm sagt nun, in welchen Dateien es die Daten ablegt und zeigt den Fingerabdruck des neuen Schlüssels an. | ||
5. Nun wird der öffentliche Schlüssel auf den Zielrechner geschafft und dort in die Datei "~/.ssh/authorized_keys" kopiert. | 5. Nun wird der öffentliche Schlüssel (also die Datei "id_rsa.pub") auf den Zielrechner geschafft und dort in die Datei "~/.ssh/authorized_keys" kopiert. | ||
$ <b>cat id_rsa.pub >> ~/.ssh/authorized_keys</b> | $ <b>cat id_rsa.pub >> ~/.ssh/authorized_keys</b> | ||
Unter [[Putty]] kann der private Schlüssel mit dem Programm "puttygen.exe" in eine Form | Unter [[Putty]] kann der private Schlüssel mit dem Programm "puttygen.exe" in eine Form überführt werden, die auch Putty verstehen kann. Dazu wird der private Schlüssel (also die Datei "id_rsa") nach Microsoft Windows übertragen, dort "puttygen.exe" gestartet, der private Schlüssel importiert und einfach wieder abgespeichert. Anschliessend kann die so erzeugte Datei in Putty für die Benutzung über das Menü "SSH > Auth" angegeben werden. | ||
Weitere Einzelheiten dazu finden sich in den Manpages zu "ssh", "ssh-keygen", "ssh-agent" und "ssh-add". Die Befehle "ssh-agent" und "ssh-add" erlauben unter Unix, den privaten Schlüssel so anzumelden, dass die Passphrase nur einmal angegeben werden muss und bei Benutzung durch SSH nicht jedesmal danach gefragt wird. | |||
<!-- $ ssh -At kerry ssh -At sisis@panda ssh sisis@10.61.222.34 --> | |||
=== Schlüssel === | |||
Während der Installation von Openssh werden öffentliche und private Schlüssel für den lokalen Rechner angelegt, die je nach der Methode der Verschlüsselung ([[DSA]], [[RSA]]) in verschieden benannten Dateien liegen. | |||
* Der <b>öffentliche Schlüssel</b> (engl. public key) kann an jeden beliebigen Rechner verteilt werden, von dem aus eingeloggt werden können soll. | |||
* Der <b>private Schlüssel</b> (engl. private key) <b>muss geheim bleiben!</b> | |||
{| class=wiki | |||
! DSA !! Öffentlicher Schlüssel !! Privater Schlüssel | |||
|- | |||
| Benutzer "root" || <tt>/etc/ssh/ssh_host_dsa_key.pub</tt> || <tt>/etc/ssh/ssh_host_dsa_key</tt> | |||
|- | |||
| unprivilegierter Benutzer || <tt>~/.ssh/id_dsa.pub</tt> || <tt>~/.ssh/id_dsa</tt> | |||
|- | |||
! RSA !! Öffentlicher Schlüssel !! Privater Schlüssel | |||
|- | |||
| Benutzer "root" || <tt>/etc/ssh/ssh_host_rsa_key.pub</tt> || <tt>/etc/ssh/ssh_host_rsa_key</tt> | |||
|- | |||
| unprivilegierter Benutzer || <tt>~/.ssh/id_rsa.pub</tt> || <tt>~/.ssh/id_rsa</tt> | |||
|} | |||
=== Tunnel === | |||
Gemäss der Vorgabe dürfen nur Programme den Tunnel nutzen, die auf demselben Rechner laufen. Um auch anderen Rechnern im Netz den Tunnel zur Verfügung zu stellen, wird dem Befehl beim Aufbau des Tunnels der Parameter "-o GatewayPorts=yes" mitgegeben. Alternativ dazu kann die Option in der Konfiguratiunsdatei "ssh_config" gesetzt werden. | |||
Der Vorgang ähnelt einer [[VPN]]-Verbindung, lässt sich aber einfacher verwirklichen. Die SSH-Variante hat allerdings den Nachteil, dass immer nur ein einzelner [[TCP]]-Port weitergeleitet wird. Es werden also genausoviele SSH-Tunnels benötigt, wie Ports weitergeleitet werden sollen. | |||
Tunnel darf grundsätzlich jeder Benutzer aufbauen, solche für privilegierte Ports (mit Nummern unter 1024) sind jedoch dem Benutzer "root" vorbehalten. | |||
== Konfiguration == | == Konfiguration == | ||
Zeile 88: | Zeile 107: | ||
Die Konfigurationsdatei für den Openssh-Server heisst "/etc/ssh/sshd_config". | Die Konfigurationsdatei für den Openssh-Server heisst "/etc/ssh/sshd_config". | ||
Die Konfigurationsdatei für den Openssh-Client heisst "/etc/ssh/ssh_config". | Die Konfigurationsdatei für den Openssh-Client heisst "/etc/ssh/ssh_config". Benutzerbezogene Einstellungen können in der Datei "~/.ssh/config" gemacht werden. Die Befehlszeile kennt auch sämtliche in diesen Konfigurationsdateien möglichen Optionen. | ||
Falls kein Openssh-Daemon läuft, muss in der Datei "/etc/rc.config" der Schalter für ssh aktiviert werden. Auf der eigenen Seite der Verbindung muss dann nur noch ssh aufgerufen werden, wobei natürlich die IP-Adresse des fernen Rechners sowie eine gültige Benutzerkennung bekannt sein müssen. | Falls kein Openssh-Daemon läuft, muss in der Datei "/etc/rc.config" der Schalter für ssh aktiviert werden. Auf der eigenen Seite der Verbindung muss dann nur noch ssh aufgerufen werden, wobei natürlich die IP-Adresse des fernen Rechners sowie eine gültige Benutzerkennung bekannt sein müssen. | ||
== | === Anmeldung als Linux-Benutzer "root" === | ||
Die Konfiguration erfolgt über den Parameter "PermitRootLogin". Die Optionen sind: | |||
* yes: Erlauben | |||
* no: Verbieten | |||
* prohibit-password: Verbieten aller interaktiven Anmeldearten (z. B. mit Passwort) - erlaubt sind weiterhin die Anmeldung über einen öffentlichen Schlüssel, die rechnerbasierte Anmeldung sowie die GSSAPI-Authentifizierung | |||
=== Erzwungene Befehle === | |||
Der | In Verbindung mit einem Schlüsselpaar können fest bestimmte Befehle irgendwo im Rechnernetz ausgeführt werden, ohne dass das Benutzerkonto für andere Zwecke offen ist. | ||
* | |||
* Der | Der öffentliche Schlüssel liegt bei der Public Key-Authentifizierung in der Datei "~/.ssh/authorized_keys" auf dem Rechner, auf dem die Anmeldung stattfindet. Jede Zeile dieser Datei enthält einen einzelnen öffentlichen Schlüssel. Jede Zeile eines Schlüssel der SSH-Protokollversion 2 ist einige hundert zeichen lang und besteht aus folgenden Bereichen: | ||
* Optionen | |||
* Schlüsselart (z. B. "ssh-rsa") | |||
* Base64-kodierter Schlüssel | |||
* Kommentar | |||
Bei einem neu erzeugten Schlüssel ist das Optionenfeld nicht belegt. Um es für einen Schlüssel zu verwenden, werden am Beginn der Zeile, durch Kommas getrennt, die gewünschten Optionen eingesetzt. Hier sind keine Leerzeichen erlaubt, ausser sie stehen innerhalb von Anführungszeichen. | |||
* Mit "from = <i>Host-Muster</i>" lässt sich festlegen, von welchen Rechnern aus sich ein Benutzer mit diesem Schlüssel anmelden darf. Eine Negativauswahl lässt sich mit "!" vor einer Rechnerbezeichnung treffen. | |||
* Mit "command=<i>Befehl</i>" kann ein bestimmter Befehl zur ausschliesslichen Ausführung mittels dieses Schlüssels bestimmt werden. | |||
Im folgenden Beispiel wird in jedem Fall ausschliesslich der Befehl "dump /home" ausgeführt - interaktive Logins sind also nicht möglich. Die weiteren Parameter "no-pty,no-port-forwarding" verhindern, dass der Befehl in einem Pseudoterminal (PTY) läuft oder dass der SSH-Client TCP-Ports umleitet. | |||
command="dump /home",no-pty,no-port-forwarding 1024 33 23...2323 backup.hut.fi | |||
Selbstverständlich lassen sich auch weitere SSH-Befehle mit einem Schlüssel verbinden. Dieser Mechanismus ist praktisch, wenn ein Rechner (hier "tux") nicht direkt, sondern nur per Umweg über einen anderen Rechner. Das ist häufig beim Anmelden auf einen Rechner hinter einer Firewall der Fall: Ist auf dem Proxy-Rechner der öffentliche Schlüssel installiert, so verbindet dessen "sshd" den Client problemlos weiter zu seinem eigentlichen Ziel. Dort muss ebenfalls ein gültiger öffentlicher Schlüssel liegen. Die zugehörigen privaten Schlüssel bleiben beim Client. Durch dieses Verfahren sind die Rechner im lokalen Rechnernetz erreichbar, trotz Firewall und ohne einen eigenen Port nach innen zu öffnen. | |||
command="ssh -A -2 -1 abc tux" ssh-dss AAAB3N...KElw== abc@vaio | |||
Für regelmässig durchgeführte Aufgaben wie z. B. unbeobachtet arbeitende Cronjobs bieten schlüsselbezogene erzwungene Befehle ein weites Eingabefeld. Ihr Zugriff soll ja gerade auf eine genau begrenzte Aufgabe eingeschränkt werden. Die auszuführenden Befehle können natürlich auch eigene Skripte sein. Achtzugeben ist bei Befehlen (z. B. [[vi]]), welche die Möglichkeit eines Shell-Escape bieten. | |||
Im folgenden Beispiel erhält der Benutzer keine Shell angeboten, stattdessen wird die Verbindung nach zwei Stunden automatisch abgebaut - der SSH-Zugang ist so nur noch für das [[Portforwarding]] geeignet. Mit der Option "permitopen" kann das Portforwarding auf einen bestimmten Rechner und einen bestimmten Port eingeschränkt werden (hier "localhost:5910"). | |||
command="/bin/sleep 2h",permitopen="localhost:5910" ssh-dss AAAB3N...KElw== abc@vaio | |||
=== Verbindungsdaten speichern === | |||
Mit Hilfe der Konfigurationsdatei "~/.ssh/config" können für jeden Benutzer alle Einstellungen zu einer Verbindung gespeichert und später wieder aufgerufen werden. Diese Datei wird auch von den anderen Shell-Befehlen aus dem Openssh-Paket verwendet, also sowohl von ssh wie auch von [[scp]] und [[sftp]]. Die Werte in der Konfigurationsdatei wwerden der Reihe nach abgearbeitet, für jeden Parameter wird jeweils nur der erste Treffer genommen. Aus diesem Grunde stehen die Standardwerte am Dateiende unter "Host *" - die Einstellungen, die nur für einzelne Rechner gelten, stehen davor. Eine DNS-Auflösung findet hier aus Sicherheitsgründen nicht statt. | |||
Die Datei beginnt mit allgemeinen Einstellungen für alle Sitzungen. | |||
* "PreferredAuthentications" legt fest, dass Openssh versuchen soll, zuerst eine Anmeldung per Public Key auszuhandeln und es danach mit einem Passwort zu probieren, ohne andere Methoden einzuschieben. Die übrigen Zeilen im folgenden Beispiel schalten weitere Anmeldemethoden ab, um nutzlose Versuche zu vermeiden. | |||
Danach folgen die Einstellungen für einzelne Sitzungen. | |||
* "Host" leitet eine Sitzung ein, alle danach folgenden Anweisungen gelten nur für den genannten Zielrechner. Der Eintrag kann den Namen des Rechners enthalten, auch mit den Platzhaltern Stern ("*") und Fragezeichen ("?"), oder einen beliebigen Kurznamen. In letzterem Fall wird der zu kontaktierende Rechner dann mit dem Eintrag "HostName" bestimmt. | |||
* "Port" legt die Portnummer auf dem zu kontaktierenden Rechnere fest. | |||
* "Protocol" legt die Version des SSH-Protokolls auf dem zu kontaktierenden Rechnere fest. | |||
* "Compression" legt die für langsame Verbindungen zu empfehlende Kompression fest. | |||
* "Port" legt die Portnummer auf dem zu kontaktierenden Rechnere fest. | |||
* "LocalForward" legt einen gesicherten Tunnel fest. | |||
* "CheckHostIP" setzt eine Option, für die es keinen Befehlszeilenschlater gibt: Der ssh-Client prüft beim Verbinden nicht, ob die IP-Adresse des Rechners dieselbe ist, die in der Datei "~/.ssh/known_hosts" gespeichert ist. Das ist für Rechner mit dynamischer IP-Adresse wichtig, da Openssh sonst bei jeder Änderung die neue IP-Adresse zusätzlich in die Datei "known_hosts" einträgt und diese so unnötig aufbläht. | |||
* "ForwardX11" legt das X-Forwarding fest und entspricht der Befehlszeilenoption "-X". | |||
# Beispieldatei "config" | |||
# Allgemeine Einstellungen für alle Sitzungen | |||
PreferredAuthentications publickey,password | |||
PubkeyAuthentication yes | |||
ChallengeResponseAuthentication no | |||
HostbasedAuthentication no | |||
KerberosAuthentication no | |||
RhostsAuthentication no | |||
# Zuhause | |||
# entspricht dem folgenden ssh-Befehl: | |||
# $ ssh -p 56509 -2 -C -L 49580:127.0.0.1:80 abc@sshhost.dyndns.org | |||
# dieser Aufruf lässt sich damit verkürzen auf: | |||
# $ ssh abc@zuhause | |||
# $ scp abc@zuhause:file.txt . | |||
Host zuhause | |||
HostName sshhost.dyndns.org | |||
Port 56509 | |||
Protocol 2 | |||
LocalForward 49580 127.0.0.1:80 | |||
CheckHostIP no | |||
User abc | |||
# Sourceforge Shell | |||
Host *.sourceforge.net | |||
User sfname | |||
Protocol 1 | |||
PasswordAuthentication no | |||
IdentityFile /home/mik/.ssh/sourceforge.key | |||
ForwardX11 no | |||
# Standardwerte | |||
Host * | |||
StrictHostKeyChecking yes | |||
Compression yes | |||
Ciphers blowfish-cbc | |||
== Verwendung == | == Verwendung == | ||
Zeile 112: | Zeile 209: | ||
$ <b>ssh remotehost -l xyz</b> | $ <b>ssh remotehost -l xyz</b> | ||
Anmeldung als Benutzer "xyz" auf dem entfernten Rechner "remotehost" und direkter Aufruf des Befehls "pwd" (anstatt einer [[Login-Shell]]). | Anmeldung als Benutzer "xyz" auf dem entfernten Rechner "remotehost" und direkter Aufruf des Befehls "pwd" (anstatt einer [[Login-Shell]]). Alles was nach dem Rechnernamen auf der Befehlszeile steht, wird von ssh als Befehl betrachtet, der auf dem entfernten Rechner ausgeführt werden soll. Die SSH-Verbindung endet nach der Ausführung dieses Befehls automatisch. | ||
$ <b>ssh xyz@remotehost pwd</b> | $ <b>ssh xyz@remotehost pwd</b> | ||
Zeile 124: | Zeile 221: | ||
$ <b>ps -ef | grep ssh</b> | $ <b>ps -ef | grep ssh</b> | ||
$ <b>netstat -an | grep 22</b> | $ <b>netstat -an | grep 22</b> | ||
Manchmal beendet ssh die Verbindung nicht, obwohl man sich auf dem entfernten Rechner abgemeldet hat. Dann hilft die Tastenkombination "~." (Tilde Punkt), die ein Verbindungsende erzwingt. | |||
Mit "~#" (Tilde Raute) werden alle aktuell durch SSH-Tunnel geleiteten Verbindungen angezeigt. | |||
"~?" (Tilde Fragezeichen) zeigt die Online-Hilfe für alle Tilden-Befehle. | |||
=== Tunnel === | === Tunnel === | ||
Zeile 180: | Zeile 283: | ||
abc@10.0.5.5$ <b>netstat -tpn | grep xclock</b> | abc@10.0.5.5$ <b>netstat -tpn | grep xclock</b> | ||
tcp 0 0 127.0.0.1:32867 127.0.0.1:6010 VERBUNDEN 6788/xclock | tcp 0 0 127.0.0.1:32867 127.0.0.1:6010 VERBUNDEN 6788/xclock | ||
== FAQ == | |||
=== Verbindung "friert ein" === | |||
Falls die SSH-Verbindung nach einer Weile des Nichtstuns "einfriert, so kann die Aktivierung folgender Parameter helfen: | |||
* <tt>ClientAliveInterval </tt>in der Datei "sshd_config" | |||
* <tt>ServerAliveInterval </tt>in der Datei "ssh_config" | |||
Die eingestellte Zeit sollte kürzer sein als es üblicherweise bis zum "Einfrieren" dauert. | |||
=== ssh hängt bei "debug2: ssh_connect: needpriv 0" === | |||
Meist hat das Problem mit DNS zu tun und tritt nicht mehr auf, wenn ein Rechner anstatt über seinen DNS-Namen direkt über seine IP-Adresse angesprochen wird. | |||
In meinem Fall wurde der lästige Hänger durch Einfügen der folgenden Zeile in die Datei "ssh_config" behoben. | |||
# <b>vi /etc/ssh/ssh_config</b> | |||
AddressFamily inet | |||
Siehe auch http://linuxnshell.blogspot.ch/2015/02/debug2-sshconnect-needpriv-0-stuck-fix.html | |||
== Weblinks == | == Weblinks == | ||
{{Weblinks}} | |||
{{url|DE|Ubuntu Users|ger|http://wiki.ubuntuusers.de/SSH|SSH}} | |||
{{url|AT|Universität Innsbruck|ger|http://www.uibk.ac.at/zid/software/unix/linux/ssh-publickey.html|SSH public key-Authentifizierung}} | |||
{{ | {{url|NZ|Waikato Linux Users Group|eng|http://www.wlug.org.nz/SSHErrors|SSH errors|icon=http://www.wlug.org.nz/phpwiki/themes/WLUG05/images/favicon.ico}} | ||
{{url_dewikipedia|Secure_Shell|Secure Shell}} | |||
{{url|UA|O'Reilly|eng|http://docstore.mik.ua/orelly/networking_2ndEd/ssh/|SSH: the secure shell : the definitive guide|Autor: Daniel J. Barrett, Richard E. Silverman. - 1st edition (2001)}} | |||
{{url|DE|Berthold Cogel|ger|http://www.uni-koeln.de/rrzk/kompass/107/k1078.html|Passwortlose Logins mit SSH}} | |||
{{url|DE|Johannes Franken|ger|http://www.jfranken.de/homepages/johannes/vortraege/ssh1.de.html|Openssh, Teil1: Grundlagen}} | |||
{{url|DE|Johannes Franken|ger|http://www.jfranken.de/homepages/johannes/vortraege/ssh1.de.html|Openssh, Teil2: SSH-Tunnels}} | |||
{{url|DE|Johannes Franken|ger|http://www.jfranken.de/homepages/johannes/vortraege/ssh1.de.html|Openssh, Teil3: Firewalls durchbohren}} | |||
{{Fuss}} | |||
* http://www.linuxjournal.com/content/use-sshconfig-simplify-your-life | |||
* https://help.ubuntu.com/community/SSH/OpenSSH/PortForwarding | |||
{{cat|Daemon}} | {{cat|Daemon}} | ||
{{cat|Secure Shell}} | {{cat|Secure Shell}} | ||
{{cat|Shell- | {{cat|Shell-Befehl}} | ||
{{cat|Tunnel}} | {{cat|Tunnel}} |
Aktuelle Version vom 12. Juli 2024, 18:10 Uhr
Der Shell-Befehl ssh (secure shell) ist ein SSH-Client und Teil des Pakets Openssh, das unter anderem auch den SSH-Server sshd enthält. Das Paket Openssh bietet alles, was für verschlüsselte Verbindungen über das Netzwerkprotokoll Secure Shell / SSH benötigt wird.
Programm | Funktion |
---|---|
ssh | (secure shell) Der Openssh-Client baut verschlüsselte Verbindungen zu entfernten Rechnern auf und führt bei Bedarf auch direkt Befehle aus. |
scp | (secure copy) Nicht-interaktives Kopieren von Dateien lokal, zu oder von entfernten Rechnern. |
sftp | (secure FTP) Der Openssh-FTP-Client ermöglicht interaktives Kopieren, Verzeichniswechsel und -auflistung, die Änderung von Zugriffsrechten, das Löschen von Verzeichnissen und Dateien usw. |
sshd | (secure shell daemon) Der Openssh-Server "sshd" ist als Daemon implementiert und lauscht üblicherweise auf Port 22. Die Clients bauen Verbindungen mit diesem Server auf. |
ssh-keygen | Erstellen und Umwandeln von SSH-Schlüsseln. |
ssh-keysign | Hilfsprogramm, das bei der rechnerbasierten Authentifizierung eingesetzt wird. |
ssh-keyscan | Anzeige öffentlicher Rechnerschlüssel und Anhängen in die Datei "~/.ssh/known_hosts". |
ssh-agent | Verwaltung privater SSH-Schlüssel und Vereinfachung des Umgangs mit Passwörtern. |
ssh-add | Dieses Werkzeug macht den Openssh-Agenten "ssh-agent" mit neuen Schlüsseln bekannt. |
Der Openssh-Client "ssh" ist in den meisten Linux-Distributionen bereits vorinstalliert, während der Openssh-Server "sshd" (aus dem Paket "openssh") meist nachträglich eingerichtet werden muss, falls von anderen Rechnern aus auf den lokalen Rechner zugegriffen werden soll.
Grafische Oberflächen: Cxsshadmin, Gnome SSH Tunnel Manager / GSTM, kssh, Putty, Secpanel, Sshterm (kommerziell), Tunnel Manager
autossh überwacht bestehende SSH-Verbindungen und baut sie nach einem Zusammenbruch automatisch neu auf.
Funktionsweise
Auf einem entfernten Rechner läuft der SSH-Server "sshd". Er lauscht standardmässig an TCP-Port 22 auf eingehende Verbindungen. Der SSH-Client "ssh" verbindet sich mit dem Server auf diesem Port. Beim Verbindungsaufbau geschieht im Hintergrund folgendes, was mit dem Befehl "ssh -vvv" detailliert mitverfolgt werden kann.
1. SSH-Server und SSH-Client verhandeln, welche Protokollversion sie für die Kommunikation verwenden - zur Zeit stehen die Varianten SSH 1 und SSH 2 zur Verfügung, wobei SSH 2 viel sicherer und seit einiger Zeit als Standard eingestellt ist.
2. SSH-Server und SSH-Client handeln den Verschlüsselungsalgorithmus aus.
3. SSH-Server und SSH-Client handeln den Schlüssel aus, den beide für diesen Datentransfer verwenden. Der Schlüssel gilt einmalig für diese Kommunikation und beide vernichten ihn nach dem Verbindungsende. Für längere Verbindungen ändert sich der Schlüssel zusätzlich in regelmässigen Abständen, standardmässig stündlich.
Beim ersten Login kennt der SSH-Client den Rechnerschlüssel des Servers noch nicht und verlangt deshalb eine Bestätigung vor der Verbindungsaufnahme.
The authenticity of host 'myhost (10.0.1.100)' can't be established. RSA key fingerprint is 1e:f0:39:0d:g6:c0:6e:d9:f4:32:ed:ef:6f:d6:74:cb. Are you sure you want to continue connecting (yes/no)?
Erst nach einer Bestätigung dieser Frage mit "yes" importiert das der SSH-Client den sogenannten Fingerabdruck (engl. fingerprint) in die Datei "~/.ssh/known_hosts". Ändert sich der Rechnerschlüssel, so verweigert der SSH-Client bei einer späteren Anmeldung die Verbindungsaufnahme ("WARNING: Remote host identicfication has changed!"). Dafür kann es mehrere Gründe geben.
- Böswillige Absicht bzw. ein Man-in-the-middle-Angriff: Ein Dritter versucht sich zwischen zwei Verbindungspartner zu stellen und dadurch die Kontrolle über den gesamten Datenverkehr zu übernehmen. Er kann so Informationen nach Belieben ansehen oder sogar verändern.
- Der Systemverwalter hat den Schlüssel nicht geändert oder das System neu installiert.
Hier hilft nur, den betreffenden Fingerabdruck aus der Datei "~/.ssh/known_hosts" zu löschen und den neuen Schlüssel zu akzeptieren. Dieses Verhalten wird über die Variable "StrictHostKeyChecking" in der SSH-Client-Konfigurationsdatei "ssh_config" konfiguriert.
Public-Key-Authentication
Die Public-Key-Authentication kann verwendet werden, um das Passwort nicht jedesmal eingeben zu müssen. Diese passwortfreie Anmeldung kommt oft beim automatisierten Kopieren von Dateien auf einen entfernten Zielrechner zum Einsatz.
1. Mit "ssh-keygen" wird ein RSA-Schlüsselpaar von 1024 Bit Länge generiert. Ein RSA-Schlüssel eignet sich für beide SSH-Protokollversionen. Die Schlüssellänge sollte aus Sicherheitsgründen 1024 Bit nicht unterschreiten.
$ ssh-keygen -b 1024 -t rsa
2. Die Software meldet daraufhin, dass sie ein Schlüsselpaar mit einem öffentlichen und einem privaten Schlüssel nach dem RSA-Verfahren am angegebenen Ort erzeugt (standardmässig unter "~.ssh/id_rsa" bzw. "~.ssh/id_rsa.pub").
3. Die Abfrage nach dem Passwort wird zweimal mit RETURN bestätigt (es wird also kein Passwort eingegeben).
4. Das Programm sagt nun, in welchen Dateien es die Daten ablegt und zeigt den Fingerabdruck des neuen Schlüssels an.
5. Nun wird der öffentliche Schlüssel (also die Datei "id_rsa.pub") auf den Zielrechner geschafft und dort in die Datei "~/.ssh/authorized_keys" kopiert.
$ cat id_rsa.pub >> ~/.ssh/authorized_keys
Unter Putty kann der private Schlüssel mit dem Programm "puttygen.exe" in eine Form überführt werden, die auch Putty verstehen kann. Dazu wird der private Schlüssel (also die Datei "id_rsa") nach Microsoft Windows übertragen, dort "puttygen.exe" gestartet, der private Schlüssel importiert und einfach wieder abgespeichert. Anschliessend kann die so erzeugte Datei in Putty für die Benutzung über das Menü "SSH > Auth" angegeben werden.
Weitere Einzelheiten dazu finden sich in den Manpages zu "ssh", "ssh-keygen", "ssh-agent" und "ssh-add". Die Befehle "ssh-agent" und "ssh-add" erlauben unter Unix, den privaten Schlüssel so anzumelden, dass die Passphrase nur einmal angegeben werden muss und bei Benutzung durch SSH nicht jedesmal danach gefragt wird.
Schlüssel
Während der Installation von Openssh werden öffentliche und private Schlüssel für den lokalen Rechner angelegt, die je nach der Methode der Verschlüsselung (DSA, RSA) in verschieden benannten Dateien liegen.
- Der öffentliche Schlüssel (engl. public key) kann an jeden beliebigen Rechner verteilt werden, von dem aus eingeloggt werden können soll.
- Der private Schlüssel (engl. private key) muss geheim bleiben!
DSA | Öffentlicher Schlüssel | Privater Schlüssel |
---|---|---|
Benutzer "root" | /etc/ssh/ssh_host_dsa_key.pub | /etc/ssh/ssh_host_dsa_key |
unprivilegierter Benutzer | ~/.ssh/id_dsa.pub | ~/.ssh/id_dsa |
RSA | Öffentlicher Schlüssel | Privater Schlüssel |
Benutzer "root" | /etc/ssh/ssh_host_rsa_key.pub | /etc/ssh/ssh_host_rsa_key |
unprivilegierter Benutzer | ~/.ssh/id_rsa.pub | ~/.ssh/id_rsa |
Tunnel
Gemäss der Vorgabe dürfen nur Programme den Tunnel nutzen, die auf demselben Rechner laufen. Um auch anderen Rechnern im Netz den Tunnel zur Verfügung zu stellen, wird dem Befehl beim Aufbau des Tunnels der Parameter "-o GatewayPorts=yes" mitgegeben. Alternativ dazu kann die Option in der Konfiguratiunsdatei "ssh_config" gesetzt werden.
Der Vorgang ähnelt einer VPN-Verbindung, lässt sich aber einfacher verwirklichen. Die SSH-Variante hat allerdings den Nachteil, dass immer nur ein einzelner TCP-Port weitergeleitet wird. Es werden also genausoviele SSH-Tunnels benötigt, wie Ports weitergeleitet werden sollen.
Tunnel darf grundsätzlich jeder Benutzer aufbauen, solche für privilegierte Ports (mit Nummern unter 1024) sind jedoch dem Benutzer "root" vorbehalten.
Konfiguration
Die Konfigurationsdatei für den Openssh-Server heisst "/etc/ssh/sshd_config".
Die Konfigurationsdatei für den Openssh-Client heisst "/etc/ssh/ssh_config". Benutzerbezogene Einstellungen können in der Datei "~/.ssh/config" gemacht werden. Die Befehlszeile kennt auch sämtliche in diesen Konfigurationsdateien möglichen Optionen.
Falls kein Openssh-Daemon läuft, muss in der Datei "/etc/rc.config" der Schalter für ssh aktiviert werden. Auf der eigenen Seite der Verbindung muss dann nur noch ssh aufgerufen werden, wobei natürlich die IP-Adresse des fernen Rechners sowie eine gültige Benutzerkennung bekannt sein müssen.
Anmeldung als Linux-Benutzer "root"
Die Konfiguration erfolgt über den Parameter "PermitRootLogin". Die Optionen sind:
- yes: Erlauben
- no: Verbieten
- prohibit-password: Verbieten aller interaktiven Anmeldearten (z. B. mit Passwort) - erlaubt sind weiterhin die Anmeldung über einen öffentlichen Schlüssel, die rechnerbasierte Anmeldung sowie die GSSAPI-Authentifizierung
Erzwungene Befehle
In Verbindung mit einem Schlüsselpaar können fest bestimmte Befehle irgendwo im Rechnernetz ausgeführt werden, ohne dass das Benutzerkonto für andere Zwecke offen ist.
Der öffentliche Schlüssel liegt bei der Public Key-Authentifizierung in der Datei "~/.ssh/authorized_keys" auf dem Rechner, auf dem die Anmeldung stattfindet. Jede Zeile dieser Datei enthält einen einzelnen öffentlichen Schlüssel. Jede Zeile eines Schlüssel der SSH-Protokollversion 2 ist einige hundert zeichen lang und besteht aus folgenden Bereichen:
- Optionen
- Schlüsselart (z. B. "ssh-rsa")
- Base64-kodierter Schlüssel
- Kommentar
Bei einem neu erzeugten Schlüssel ist das Optionenfeld nicht belegt. Um es für einen Schlüssel zu verwenden, werden am Beginn der Zeile, durch Kommas getrennt, die gewünschten Optionen eingesetzt. Hier sind keine Leerzeichen erlaubt, ausser sie stehen innerhalb von Anführungszeichen.
- Mit "from = Host-Muster" lässt sich festlegen, von welchen Rechnern aus sich ein Benutzer mit diesem Schlüssel anmelden darf. Eine Negativauswahl lässt sich mit "!" vor einer Rechnerbezeichnung treffen.
- Mit "command=Befehl" kann ein bestimmter Befehl zur ausschliesslichen Ausführung mittels dieses Schlüssels bestimmt werden.
Im folgenden Beispiel wird in jedem Fall ausschliesslich der Befehl "dump /home" ausgeführt - interaktive Logins sind also nicht möglich. Die weiteren Parameter "no-pty,no-port-forwarding" verhindern, dass der Befehl in einem Pseudoterminal (PTY) läuft oder dass der SSH-Client TCP-Ports umleitet.
command="dump /home",no-pty,no-port-forwarding 1024 33 23...2323 backup.hut.fi
Selbstverständlich lassen sich auch weitere SSH-Befehle mit einem Schlüssel verbinden. Dieser Mechanismus ist praktisch, wenn ein Rechner (hier "tux") nicht direkt, sondern nur per Umweg über einen anderen Rechner. Das ist häufig beim Anmelden auf einen Rechner hinter einer Firewall der Fall: Ist auf dem Proxy-Rechner der öffentliche Schlüssel installiert, so verbindet dessen "sshd" den Client problemlos weiter zu seinem eigentlichen Ziel. Dort muss ebenfalls ein gültiger öffentlicher Schlüssel liegen. Die zugehörigen privaten Schlüssel bleiben beim Client. Durch dieses Verfahren sind die Rechner im lokalen Rechnernetz erreichbar, trotz Firewall und ohne einen eigenen Port nach innen zu öffnen.
command="ssh -A -2 -1 abc tux" ssh-dss AAAB3N...KElw== abc@vaio
Für regelmässig durchgeführte Aufgaben wie z. B. unbeobachtet arbeitende Cronjobs bieten schlüsselbezogene erzwungene Befehle ein weites Eingabefeld. Ihr Zugriff soll ja gerade auf eine genau begrenzte Aufgabe eingeschränkt werden. Die auszuführenden Befehle können natürlich auch eigene Skripte sein. Achtzugeben ist bei Befehlen (z. B. vi), welche die Möglichkeit eines Shell-Escape bieten.
Im folgenden Beispiel erhält der Benutzer keine Shell angeboten, stattdessen wird die Verbindung nach zwei Stunden automatisch abgebaut - der SSH-Zugang ist so nur noch für das Portforwarding geeignet. Mit der Option "permitopen" kann das Portforwarding auf einen bestimmten Rechner und einen bestimmten Port eingeschränkt werden (hier "localhost:5910").
command="/bin/sleep 2h",permitopen="localhost:5910" ssh-dss AAAB3N...KElw== abc@vaio
Verbindungsdaten speichern
Mit Hilfe der Konfigurationsdatei "~/.ssh/config" können für jeden Benutzer alle Einstellungen zu einer Verbindung gespeichert und später wieder aufgerufen werden. Diese Datei wird auch von den anderen Shell-Befehlen aus dem Openssh-Paket verwendet, also sowohl von ssh wie auch von scp und sftp. Die Werte in der Konfigurationsdatei wwerden der Reihe nach abgearbeitet, für jeden Parameter wird jeweils nur der erste Treffer genommen. Aus diesem Grunde stehen die Standardwerte am Dateiende unter "Host *" - die Einstellungen, die nur für einzelne Rechner gelten, stehen davor. Eine DNS-Auflösung findet hier aus Sicherheitsgründen nicht statt.
Die Datei beginnt mit allgemeinen Einstellungen für alle Sitzungen.
- "PreferredAuthentications" legt fest, dass Openssh versuchen soll, zuerst eine Anmeldung per Public Key auszuhandeln und es danach mit einem Passwort zu probieren, ohne andere Methoden einzuschieben. Die übrigen Zeilen im folgenden Beispiel schalten weitere Anmeldemethoden ab, um nutzlose Versuche zu vermeiden.
Danach folgen die Einstellungen für einzelne Sitzungen.
- "Host" leitet eine Sitzung ein, alle danach folgenden Anweisungen gelten nur für den genannten Zielrechner. Der Eintrag kann den Namen des Rechners enthalten, auch mit den Platzhaltern Stern ("*") und Fragezeichen ("?"), oder einen beliebigen Kurznamen. In letzterem Fall wird der zu kontaktierende Rechner dann mit dem Eintrag "HostName" bestimmt.
- "Port" legt die Portnummer auf dem zu kontaktierenden Rechnere fest.
- "Protocol" legt die Version des SSH-Protokolls auf dem zu kontaktierenden Rechnere fest.
- "Compression" legt die für langsame Verbindungen zu empfehlende Kompression fest.
- "Port" legt die Portnummer auf dem zu kontaktierenden Rechnere fest.
- "LocalForward" legt einen gesicherten Tunnel fest.
- "CheckHostIP" setzt eine Option, für die es keinen Befehlszeilenschlater gibt: Der ssh-Client prüft beim Verbinden nicht, ob die IP-Adresse des Rechners dieselbe ist, die in der Datei "~/.ssh/known_hosts" gespeichert ist. Das ist für Rechner mit dynamischer IP-Adresse wichtig, da Openssh sonst bei jeder Änderung die neue IP-Adresse zusätzlich in die Datei "known_hosts" einträgt und diese so unnötig aufbläht.
- "ForwardX11" legt das X-Forwarding fest und entspricht der Befehlszeilenoption "-X".
# Beispieldatei "config" # Allgemeine Einstellungen für alle Sitzungen PreferredAuthentications publickey,password PubkeyAuthentication yes ChallengeResponseAuthentication no HostbasedAuthentication no KerberosAuthentication no RhostsAuthentication no # Zuhause # entspricht dem folgenden ssh-Befehl: # $ ssh -p 56509 -2 -C -L 49580:127.0.0.1:80 abc@sshhost.dyndns.org # dieser Aufruf lässt sich damit verkürzen auf: # $ ssh abc@zuhause # $ scp abc@zuhause:file.txt . Host zuhause HostName sshhost.dyndns.org Port 56509 Protocol 2 LocalForward 49580 127.0.0.1:80 CheckHostIP no User abc
# Sourceforge Shell Host *.sourceforge.net User sfname Protocol 1 PasswordAuthentication no IdentityFile /home/mik/.ssh/sourceforge.key ForwardX11 no # Standardwerte Host * StrictHostKeyChecking yes Compression yes Ciphers blowfish-cbc
Verwendung
Anmeldung als Benutzer "xyz" auf dem entfernten Rechner "remotehost".
$ ssh xyz@remotehost oder $ ssh remotehost -l xyz
Anmeldung als Benutzer "xyz" auf dem entfernten Rechner "remotehost" und direkter Aufruf des Befehls "pwd" (anstatt einer Login-Shell). Alles was nach dem Rechnernamen auf der Befehlszeile steht, wird von ssh als Befehl betrachtet, der auf dem entfernten Rechner ausgeführt werden soll. Die SSH-Verbindung endet nach der Ausführung dieses Befehls automatisch.
$ ssh xyz@remotehost pwd
Drucken der lokalen Datei "file.ps" mit lpr als Benutzer "xyz" über den entfernten Rechner "remotehost".
$ cat file.ps | ssh xyz@remotehost lpr
Prüfen, ob auf dem Rechner ein ssh-Daemon läuft.
$ ps -ef | grep ssh $ netstat -an | grep 22
Manchmal beendet ssh die Verbindung nicht, obwohl man sich auf dem entfernten Rechner abgemeldet hat. Dann hilft die Tastenkombination "~." (Tilde Punkt), die ein Verbindungsende erzwingt.
Mit "~#" (Tilde Raute) werden alle aktuell durch SSH-Tunnel geleiteten Verbindungen angezeigt.
"~?" (Tilde Fragezeichen) zeigt die Online-Hilfe für alle Tilden-Befehle.
Tunnel
Aufbau eines Tunnels zum entfernten Rechner "remotehost", wobei der entfernte Port 4000 getunnelt wird und auf dem lokalen Rechner unter Portnummer 4444 erreichbar gemacht wird.
$ ssh -L 4444:remotehost:4000 remotehost
Aufbau eines Tunnels zum entfernten Rechner "remotehost" über den Rechner "relayhost", wobei der entfernte Port 4000 getunnelt wird und auf dem lokalen Rechner unter Portnummer 4444 erreichbar gemacht wird.
$ ssh -L 4444:relayhost:4000 remotehost
Doppelte Portweiterleitung eines Ports von Rechner "zicke" via Rechner "panda" auf Rechner "emu". Im Anschluss daran können auf dem lokalen Rechner die folgenden URLs aufgerufen werden:
- http://localhost:58080/
- http://panda:7070/
- http://zicke:8080/
mik@emu:~> ssh -C -g -L 58080:panda:7070 sisis@panda sisis@panda:~> ssh -C -g -L 7070:zicke:8080 sisis@zicke Password: sisis@zicke:~>
Portweiterleitung von zwei Ports des Rechners "zicke" auf Rechner "emu". Im Anschluss daran können azf dem lokalen Rechner folgende URLs aufgerufen werden:
- https://localhost:50443/
- http://localhost:58080/
- https://zicke:443/
- http://zicke:8080/
mik@emu:~> ssh -C -g -L 50443:zicke:443 -L 58080:zicke:8080 sisis@zicke Password: sisis@zicke:~>
Auf dem entfernten Rechner "remotehost" läuft ein Proxy auf Port 3128, der für transparentes Proxying konfiguriert ist. Alle HTTP-Anfragen werden dann wie folgt umgeleitet.
$ ssh -o GatewayPorts=yes -L 80:remotehost:3128 remotehost
Das Tunneln funktioniert auch in umgekehrter Richtung. Mit dem folgenden Befehl wird ein Tunnel vom entfernten Rechner "remotehost" zum lokalen Rechner "localhost" aufgebaut.
$ ssh -o GatewayPorts=yes -R 3128:localhost:80 remotehost
Grafische Tunnel
Um das X Window System zu tunneln, emuliert der Openssh-Daemon "sshd" einen X11-Server und besetzt ein Display, standardmässig die Nummer 11. Wenn man sich auf dem Server einwählt, setzt dieser die Umgebungsvariable "DISPLAY" auf diesen Wert, genauer gesagt auf "localhost:11.0", um Kollisionen mit dem lokal laufenden X-Server zu verhindern. Alle Daten, die ein Rechner an dieses Display sendet, wandern verschlüsselt zum lokalen Rechner.
Zum Aktivieren des X11-Forwarding muss in der Server-Konfigurationsdatei "/etc/ssh/sshd_config" die Variable "X11Forwarding yes" gesetzt sein. Die Variable "X11DisplayOffset 10" bestimmt ausserdem den Abstand des virtuellen Displays zum realen Display. Zusätzlich muss auf dem Rechner, der das getunnelte X11 anzeigen soll in der Client-Konfigurationsdatei "/etc/ssh/ssh_config" ebenfalls die Variable "X11Forwarding yes" gesetzt sein.
Anmelden auf dem entfernten Rechner "10.0.5.5" mit X-Weiterleitung. Danach können auf dem Zielrechner grafische Programme aufgerufen werden, deren Programmfenster auf dem lokalen Desktop erscheinen. Durch die aufgeführten Befehle werden auch die Belegung der Variable "DISPLAY", der Prozess und die Netzwerkverbindungen angezeigt.
$ ssh -X abc@10.0.5.5 abc@10.0.5.5$ xclock & [1] 6788 abc@10.0.5.5$ echo $DISPLAY localhost:10.0 abc@10.0.5.5$ ps aux | grep xclock | grep -v grep sisis 6788 0.3 0.5 5048 2872 pts/1 S 16:12 0:00 xclock abc@10.0.5.5$ netstat -tpn | grep xclock tcp 0 0 127.0.0.1:32867 127.0.0.1:6010 VERBUNDEN 6788/xclock
FAQ
Verbindung "friert ein"
Falls die SSH-Verbindung nach einer Weile des Nichtstuns "einfriert, so kann die Aktivierung folgender Parameter helfen:
- ClientAliveInterval in der Datei "sshd_config"
- ServerAliveInterval in der Datei "ssh_config"
Die eingestellte Zeit sollte kürzer sein als es üblicherweise bis zum "Einfrieren" dauert.
ssh hängt bei "debug2: ssh_connect: needpriv 0"
Meist hat das Problem mit DNS zu tun und tritt nicht mehr auf, wenn ein Rechner anstatt über seinen DNS-Namen direkt über seine IP-Adresse angesprochen wird.
In meinem Fall wurde der lästige Hänger durch Einfügen der folgenden Zeile in die Datei "ssh_config" behoben.
# vi /etc/ssh/ssh_config AddressFamily inet
Siehe auch http://linuxnshell.blogspot.ch/2015/02/debug2-sshconnect-needpriv-0-stuck-fix.html
Weblinks
Herausgeber | Sprache | Webseitentitel | Anmerkungen |
---|---|---|---|
![]() |
ger | SSHwbm | |
![]() |
ger | SSH public key-Authentifizierungwbm | |
![]() |
eng | SSH errorswbm | |
![]() |
ger | Secure Shellwbm | Enzyklopädischer Artikel |
![]() |
eng | SSH: the secure shell : the definitive guidewbm | Autor: Daniel J. Barrett, Richard E. Silverman. - 1st edition (2001) |
![]() |
ger | Passwortlose Logins mit SSHwbm | |
![]() |
ger | Openssh, Teil1: Grundlagenwbm | |
![]() |
ger | Openssh, Teil2: SSH-Tunnelswbm | |
![]() |
ger | Openssh, Teil3: Firewalls durchbohrenwbm |