Ssh

ssh ist die Abkürzung für die Anwendung "Secure Shell". Im Prinzip besteht sie aus mindestens zwei Teilen, dem SSH-Server und dem SSH-Client. Da ssh modular aufgebaut ist, gibt es noch weitere Anwendungen für verschiedene Zwecke, z.B. einen sftp-server für den SFTP-Zugriff von entfernten Rechnern aus.

Mit ssh (SSH-Client) kann man sich an einem entfernten Rechner anmelden und dort Befehle ausführen. Vorrausetzung ist, daß auf dem entfernten Rechner ein SSH-Server läuft. Mit ssh wird sichere verschlüsselte Kommunikation zwischen den beiden Hosts ermöglicht. X11-Verbindungen, beliebige TCP-Ports und UNIX-Domain-Sockets können ebenfalls über den sicheren Kanal weitergeleitet werden.

ssh wird in den meisten Fällen mit dem Paket OpenSSH benutzt, deshalb wird hier im folgenden auf dieses Paket Bezug genommen. Es sei nur kurz erwähnt, daß es daneben noch mindestens zwei andere Lösungen gibt, die man in Betracht ziehen kann:

• dropbear
• lsh

Beide verzichten aus Sicherheitsgründen auf die Implementierung des SSH-1-Protokolls und sind schon deshalb leichtgewichtiger als OpenSSH. Allerdings wird lsh wohl seit längerer Zeit nicht mehr weiter entwickelt. dropbear hat den Vorteil, daß es weitgehend kompatibel zu OpenSSH ist.

Installation

Das ursprüngliche ssh-Protokoll wurde wurde 1995 von dem Finnen Tatu Ylönen als Open-Source-Projekt entwickelt. Da T. Ylönen aber bald begann, dies in einer eigenen Firma kommerziell zu vermarkten, wurde aus den letzten freien Sourcen ein neues Projekt entwickelt (geforkt), das sich OpenSSH nennt.

Da wie gesagt, mindestens ein SSH-Server und ein SSH-Client benötigt wird, sollten als Minimum diese zwei Pakete installiert werden:

apt-get install openssh-server
apt-get install openssh-client

openssh-server wird auf dem entfernten Rechner (Server) installiert, openssh-client auf dem eigenen Rechner. Es gibt auch das Meta-Paket ssh, mit dem sowohl der openssh-server als auch der openssh-client in einem Rutsch installiert werden können:

apt-get install ssh

Allerdings ist der openssh-client schon per Default installiert, so daß es bei Bedarf reichen würde, nur openssh-server zu installieren.

Da wie unter Linux üblich, diese Rollen nicht festgelegt sein müssen, können beide Dienste auch auf beiden Rechnern laufen, so daß ein wechselseitigier Zugiff von Rechner A auf Rechner B und umgekehrt möglich wäre.

ACHTUNG: zumindest in den Repos von MX-18 existiert noch das Paket openssh-client-ssh1, das das veraltetete und unsichere Protokoll SSH1 benutzt. Von dessen Installation wird abgeraten.

Nach der Installation stehen folgende Kommandos zur Verfügung:

Kommando	Bedeutung
ssh	das eigentliche Kommando, um sich mit dem entfernten Rechne zu verbinden
sshd	wie ssh, läuft jedoch als Dämon im Hintergund
scp	zum Kopieren von Dateien zwischen den zwei Rechnern
sftp	interaktives File-Transfer-Programm, ähnlich wie FTP, aber verschlüsselte Übertragung
ssh-keygen	dient zur Verwaltung der benötigten Schlüssel
ssh-copy-id	zum sicheren Austausch der für die Authentifizierung benötigten Schlüssel

ssh

grafische Oberflächen (GUIs) für ssh

Name	Beschreibung
hotssh	Grafische Gnome-Oberfläche für Secure Shell (SSH), leider ohne Betreuer
putty	Unix-Portierung des populären Windows-SSH-Clients PuTTY. unterstützt flexible Terminaleinrichtung, Rekonfiguration während der Sitzung mittels Strg-Rechtsklick, mehrere X11-Authentifizierungsprotokolle und weitere interessante Sachen, die von SSH im xterm nicht geboten werden. Installiert gleichzeitig auch die putty-tools (s. sonstige Werkzeuge): Plink (PuTTY Link) PSCP (PuTTY Secure Copy) PSFTP (PuTTY SFTP-Client) PuTTYgen
secpanel	grafisches Interface für SSH und scp

Verwendung

Die Anmeldung (einloggen) auf dem entfernten Rechner erfolgt im einfachsten Fall so (aber beachte auch die sichere Variante mit Public-Key-Zugang):

ssh USER@RECHNER
USER = Username, als der man sich auf dem entfernten Rechner einloggen will. Dieser User muss dort natürlich auch existieren
RECHNER = Name des entfernten Rechners, es kann auch die IP-Adresse sein.

Ist der Username auf beiden Rechnern gleich, kann man ihn auch weglassen.

ssh RECHNER

Bei der ersten Anmeldung bekommt man eine Warnung, daß der Schlüssel des entfernten Rechners nicht bekannt ist und die Anfrage, ob man sich tatsächlich damit verbinden möchte.

The authenticity of host 'server (192.168.1.21)' can't be established.
ECDSA key fingerprint is b4:0b:eb:b6:15:16:d6:14:96:29:08:48:3e:dc:2b:c1.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server' (ECDSA) to the list of known hosts.

Normalerweise sollte man sich vergewissern, ob dies tatsächlich der Schlüssel des entfernten Rechners ist (z.B. durch vorherige Anfrage beim Admin).

Wie auch immer, wird diese Anfrage mit yes beantwortet, so erfolgt eine neuerliche Warnung, daß dieser Schlüssel in die Datei ~/.ssh/known_hosts eingetragen wird, in der sich die Keys der bekannten Rechner (Hosts) befinden.

Warning: Permanently added 'server' (ECDSA) to the list of known hosts.

Damit wird beim neuerlichen Anmelden eine neue Warnung verhindert, da dieser entfernte Rechner nun als bekannt und vertrauenswürdig eingestuft ist.

Ist der Anmeldevorgang erfolgreich bekommt man im Terminal den Prompt des entfernten Rechners und alle Kommandos, die man eingibt, werden auch auf diesem entfernten Rechner ausgeführt, das Ergebnis jedoch im Terminal auf dem eigenen Rechner angezeigt. Die Eingabe z.B. von

ls

zeigt den Inhalt des entfernten Verzeichnisses an. Auf diese Weise kann man jemandem Hilfe leisten, indem man sich z.B. ansieht, wie dessen Konfigurationsdateien aussehen, sie eventuell korrigiert usw.

Die SSH-Verbindung wird entweder durch die Eingabe von

exit

beendet (auf der Client-Seite), oder durch Strg-D auf der Server-Seite. Sollte dies einmal nicht funktionieren (die Verbindung "hängt"), kann man es auf der Client-Seite auch durch die Eingabe einer sogenannten Escape-Sequenz versuchen:

~.

gefolgt von einem Return.

Nach dem Anmeldekommando kann auch ein Befehl oder ein Skript angefügt werden:

ssh USER@RECHNER ls -l

Der Befehl wird ausgeführt, das Ergebnis angezeigt und die Verbindung sofort geschlossen.

Konfiguration

sshd

Der OpenSSH Server Daemon wird in der Datei /etc/ssh/sshd_config konfiguriert. Im Prinzip ist diese frisch installierte Datei voll funktionsfähig, kann also sofort benutzt werden. Trotzdem empfiehlt es sich, einige sicherheitstechnisch relevante Optionen anzupassen.

Nach solchen Veränderungen und unbedingt noch vor dem Neustart des ssh-Servers sollte man mit

sudo sshd -t

einen Testlauf starten, damit eventuelle Fehler in der Konfigurationsdatei angezeigt werden:

$ sudo sshd -t
/etc/ssh/sshd_config line 27: unsupported log level 'INFOX'

noch nicht vorhandene Optionen (z.B. AllowUsers) können einfach eingefügt werden.

Option	Beschreibung
AllowUsers user1 user2	nur noch die user1 und user2 dürfen sich mit ssh verbinden
AllowGroups group1 group2	nur noch User der Gruppen group1 und group2 dürfen sich mit ssh verbinden
Port 39901	ssh lauscht nicht mehr auf Port 22, sondern auf Port 39901. Hierbei kann ein beliebiger, aber noch nicht belegter Port angegeben werden. Eine Liste standardisierter Ports findet man hier, aber auch in der Datei /etc/services
PasswordAuthentication no	verhindert das Anmelden mit Passworteingabe. Vorher sollte man testen, ob die Anmeldung mittels Public-Key-Zugang auch funktioniert
PermitRootLogin no	verhindert root-Zugang über ssh (sehr empfehlenswert)
PermitRootLogin prohibit-password	weniger strenge Vaiante von "PermitRootLogin no". Root darf per ssh einloggen, aber nur mit Public-Key-Zugang (public key authentication), damit sind Brute-Force-Angriffe nicht möglich
PermitRootLogin forced-commands-only	root darf sich einloggen, aber nur für bestimmte Kommandos. Diese Kommandos stehen in der Datei ~/.ssh/authorized_keys (chmod 600), die folgenden (minimalen) Aufbau hat: from="IP-ADRESSE",command="KOMMANDO" -Optionen",ssh-rsa <SSH-KEY> Zeilen mit # am Anfang können als Kommentare benutzt werden. Damit lassen sich Skripte wie z.B. Backups, für die root-Rechte erforderlich sind, sicher durchführen.
Protocol 2	ssh benutzt nur noch das sichere Protokoll 2
ListenAddress 192.168.178.100	ssh kann nur noch von der Adresse 192.168.178.100 erreicht werden. Diese Option kann mehrfach angeführt werden. Statt IP-Adressen sind auch Hostnamen möglich

ssh-client

WICHTIG: hier ist von der Konfiguration des Clients die Rede, nicht von der Konfiguration des ssh-Servers!

Sowohl der ssh-Client als auch scp und sftp lesen Konfigurationsdaten aus den folgenden Quellen in dieser Reihenfolge:

1. Kommandozeilen-Optionen
2. die Konfigurationsdatei des Benutzers (~/.ssh/config)
3. systemweite Konfigurationsdatei (/etc/ssh/ssh_config)

Für jeden Parameter wird der erste erhaltene Wert verwendet. Das bedeutet, daß sich jeder User mit ~/.ssh/config eine eigene Konfiguration anlegen kann (und auch sollte), die nur für ihn gilt. Die Konfigurationsdateien enthalten Abschnitte, die durch Host-Namen getrennt sind, und dieser Abschnitt wird nur auf Hosts angewendet, die einem der in der Spezifikation angegebenen Muster entsprechen.

Da es sehr viele Konfigurationsparameter gibt und die meisten unverändert aus /etc/ssh/ssh_config übernommen werden können wird hier nur auf solche Parameter eingegangen, die z.B. sicherheitstechnisch wichtig sind.

Eine brauchbare Minimalkonfiguration könnte z.B. so aussehen:

Host meinhost
   HostName meinhost.beispiel.lokal
   User gosia
   Port 9898

Die Einrückung der Parameter nach Host ist nicht erforderlich, hat sich aber wegen der Lesbarkeit bewährt.

Die Bezeichnung nach Host (hier lokal) steht in keinem Zusammenhang mit dem tatsächlichen Hostnamen. Es empfiehlt sich allerdings dafür eine Bezeichnung zu wählen, die in irgendeiner Weise an den Hostnamen erinnert. Theoretisch könnte man also diese Konfigurationsdatei benutzen:

Host foo
   HostName meinhost.beispiel.lokal
   User gosia

Da ssh mit der Bezeichnung nach Host aufgerufen wird, also für das erste Beispiel mit

ssh meinhost

und für das zweite Beispiel mit

ssh foo

ist es wohl leicht entscheidbar, welche Variante besser merkbar ist.

In der Hostbezeichnung sind auch Wildcards mit * möglich:

Host haus
  HostName meinserver.lokal
Host sohn
  HostName peter.lokal
Host arbeit
  HostName foo.fabrik.de
  user abt_chef
  port 22
Host *
  user gosia
  Port 9898

In diesem Fall meldet man sich bei Host haus und peter als User gosia und beim Port 9898 an, beim Firmeneigenen Server jedoch als User abt_chef auf dem Default-Port 22.

Der ssh-Server akzeptiert per Default Verbindungen auf Port 22, sicherheitstechnisch macht es jedoch Sinn, dafür einen anderen Port zu wählen. Dies muss jedoch zuerst in der Konfigurationsdatei des ssh-Servers, also in /etc/ssh/sshd_config, verändert werden und dann die Konfiguration des Clients wie im obigen Beispiel angepasst werden.

Authentifizierung

ssh-keygen und ssh-copy-id

Statt der Passworteingabe bei der Verbindungsaufnahme mit ssh sollte man die sichere Authentifizierung mit Hilfe eines Schlüsselpaares (öffentlicher und privater Schlüssel = Public-Key-Zugang) verwenden. Zur Erzeugung und Verwaltung dieser Schlüssel dient das Kommando ssh-keygen. Zuerst wird dieses Schlüsselpaar mit ssh-keygen erzeugt:

ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/kb/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/gosia/.ssh/id_rsa.
Your public key has been saved in /home/kb/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:yPKgsr6rmkq9lmsOy8v6wUatGPttnJEuKtWRiVTd7hj gosia@mypc.fritz.lokal
The key's randomart image is:
 +---[RSA 4096]----+
 |                 |
 |      +-         |
 |     .           |
 |   .+. .         |
 |.+.oo.. S        |
 |+*o.+-           |
 |=A*+.o.          |
 |o%A-c+           |
 |A..Xco           |
 +----[SHA256]-----+

-b Schlüssellänge in bit (Default = 2048 bits)

Die Datei-Vorgaben (~/.ssh/id_rsa und ~/.ssh/id_rsa.pub) zur Abspeicherung des privaten und öffentlichen Schlüssels sollten übernommen werden. Es ist möglich andere Dateinamen anzugeben, dies kompliziert jedoch alles unnötig.

Man sollte auch eine Passphrase angeben, um Angreifern die Arbeit zu erschweren. Wenn jemand in den Besitz des privaten Schlüssels gelangt, so ist noch zusätzlich diese Passphrase notwendig, um Zugriff auf den Server zu erhalten. Dies ist wie immer eine Abwägung zwischen Bequemlichkeit und Sicherheit.

Anschliessend überträgt man den öffentlichen Schlüssel mit ssh-copy-id auf den Server (entfernten Host)

ssh-copy-id -i .ssh/id_rsa.pub gosia@pcname

Unbedingt darauf achten, daß man den Dateinamen des öffentlichen Schlüssels angibt = .ssh/id_rsa.pub

Dabei wird man noch einmal nach seinem Passwort gefragt.

gosia@pcname's password: 
Number of key(s) added: 1
Now try logging into the machine, with:   "ssh 'gosia@pcname'"
and check to make sure that only the key(s) you wanted were added.

Den Ratschlag, sich gleich mit ssh gosia@pcname einzuloggen, um sich zu überzeugen ob der Public-Key richtig übertragen wurde, sollte man unbedingt befolgen:

ssh gosia@pcname
Enter passphrase for key '/home/gosia/.ssh/id_rsa':

Die dabei angeforderte Passphrase ist dabei nicht mehr das Passwort des entfernten Users, sondern die Passphrase, die man bei der Erzeugung des Schlüsselpaares mit ssh-keygen angegeben hat.

ssh-agent und ssh-add

Möchte man verständlicherweise auch die Eingabe der Passphrase vermeiden, so kann dazu ssh-add benutzt werden.

ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/gosia/.ssh/id_rsa: 
Identity added: /home/gosia/.ssh/id_rsa (/home/gosia/.ssh/id_rsa)

Damit dies funktioniert, muss auch ssh-agent im Hintergrund laufen. Dies ist normalerweise der Fall, im Zweifelsfall kann man sich aber durch diese Eingabe davon überzeugen:

ps -fC ssh-agent

im Erfolgsfall erscheint diese Ausgabe, die natürlich je nach Umgebung variiert:

UID        PID  PPID  C STIME TTY          TIME CMD
gosia      5575  5512  0 20:41 ?           00:00:00 /usr/bin/ssh-agent env TMPDIR=/tmp/user/1000 /usr/bin/openbox-session

Hat man ssh-add ~/.ssh/id_rsa ausgeführt, so kann man zumindest für die laufende Sitzung sich mit ssh auf dem entfernten Rechner anmelden, ohne die Passphrase eingeben zu müssen.

Dies lässt sich auch durch ein kleines Skript im Autostart automatisieren:

# eval ssh-agent
ssh-add ~/.ssh/id_rsa

Die erste Zeile muss nur auskommentiert werden, wenn ssh-agent wider Erwarten nicht selbst startet.

Fehlerbehebung

Bei der Verbindungsaufnahme mit ssh oder sftp kann es passieren, daß die Verbindung mit folgender Warnung abgelehnt wird:

 $ ssh foo
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
 Someone could be eavesdropping on you right now (man-in-the-middle attack)!
 It is also possible that a host key has just been changed.
 The fingerprint for the ECDSA key sent by the remote host is
 SHA256:WMGKD3Gh8Iyly6GLTyDKkDUMJwXm6pnxPoTe2fGU1VB.
 Please contact your system administrator.
 Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
 Offending ECDSA key in /home/user/.ssh/known_hosts:11
   remove with:
   ssh-keygen -f "/home/user/.ssh/known_hosts" -R foo
 ECDSA host key for foo has changed and you have requested strict checking.
 Host key verification failed.

Der ssh-Prozess hat erkannt, daß etwas mit dem abgespeicherten Key der Gegenstelle nicht in Ordnung ist, er stimmt nicht mehr mit den Werten in der Datei ~/.ssh/known_hosts überein. Ursache kann tatsächlich ein sogenannter "Man-in-the-Middle-Angriff" sein, bei dem sich ein Angreifer zwischen den lokalen und den entfernten Host legt, damit vorgibt der entfernte Host zu sein und somit den Datenverkehr mitlesen könnte.

Steht der remote Host allerdings gar nicht so "remote", sondern als Server im Privatkeller oder sonstwo in der Wohnung ist der Grund aber meist ein anderer. Man hat ihn mit einer neuen Netzwerkkarte versehen, die IP hat sich verändert (möglicher Grund DHCP) oder es wurde schlicht und einfach ein neuer Rechner angeschafft.

Wie dem auch sei, freundlicherweise wird die Lösung gleich mitgeliefert, man soll den neuen, geänderten Schlüssel in die Datei ~/.ssh/known_hosts eintragen (s.o.) Zuvor muss aber der beanstandete Schlüssel entfernt werden:

ssh-keygen -f "/home/user/.ssh/known_hosts" -R foo

Die Option -f mit dem Pfad zur Datei known_hosts muss nur angeben werden, wenn sich diese Datei an einem anderen Ort befindet. Somit reicht in der Regel dieser Befehl:

ssh-keygen -R foo

Überflüssig zu bemerken, daß statt foo der echte Name des entfernten Hosts benutzt werden muss. Anschliessend befindet man sich sozusagen wieder im Urzustand und kann wie oben beschrieben den Schlüssel neu einfügen.

scp

scp (Secure Copy) dient zum verschlüsselten Übertragen von Dateien zwischen zwei Computern. Dabei ist auch das Kopieren zwischen zwei entfernten Rechnern möglich. Die Syntax entspricht weitgehend der von cp.

Kopieren der Datei beispiel.txt vom Host auf den entfernten Rechner:

scp beispiel.txt USER@RECHNER:Verzeichnis/beispiel.txt

Kopieren der Datei beispiel.txt vom entfernten Rechner auf den Host:

scp USER@RECHNER:Verzeichnis/beispiel.txt beispiel.txt

für USER und RECHNER gelten die gleichen Werte wie unter ssh angeführt.

Optionen

Option	Bedeutung
-1	benutze das ältere und unsichere SSH-Protokoll 1 (SSH-1)
-2	benutze das SSH-Protokoll 2 (SSH-2)
-3	Kopien zwischen zwei entfernten Hosts werden über den lokalen Host übertragen. Ohne diese Option werden die Daten direkt zwischen den beiden entfernten Hosts kopiert. Mit dieser Option ist keine Fortschrittsanzeige möglich
-4	nur IPv4-Adressen
-6	nur IPv6-Adressen
-B	Stapelverarbeitung zur Benutzung mit Skripten
-C	die übertragenen Dateien werden komprimiert
-c Kryptographie	wähle das Kryptographie-Verfahren (cipher) z.B. blowfish (Default: Triple-DES = 3DES). Weitere mögliche Verfahren: AES, IDEA oder SEED
-F ssh_config	benutzt die User-eigene Konfigurationsdatei ssh_config
-i identity_file	liest aus der Datei identity_file den benötigten privaten Schlüssel (private key)
-l Limit	begrenzt die benutzte Bandbreite auf Limit kbit/s
-P Port	Port für die Verbindung mit dem entfernten Rechner (ACHTUNG: -P = grosses P)
-p	behält beim Kopieren den Zeitstempel und die Zugriffsrechte der Ursprungsdatei
-q	"stiller Modus", keine Fortschrittsanzeige, keine Fehler- und Diagnosemeldungen
-r	Ganze Verzeichnisse rekursiv kopieren. scp folgt dabei auch symbolischen Links
-T	Deaktiviert die strenge Prüfung von Dateinamen. Standardmäßig prüft scp beim Kopieren von Dateien von einem entfernten Host in ein lokales Verzeichnis, ob die empfangenen Dateinamen mit den auf der Befehlszeile angeforderten übereinstimmen, um zu verhindern, dass der entfernte Host unerwartete oder unerwünschte Dateien sendet. Aufgrund der Unterschiede in der Art und Weise, wie verschiedene Betriebssysteme und Shells Platzhalterzeichen für Dateinamen interpretieren, können diese Prüfungen dazu führen, dass gewünschte Dateien abgelehnt werden. Diese Option deaktiviert diese Prüfungen. Dies setzt voraus, daß man darauf vertraut, daß der Server keine unerwarteten Dateinamen sendet.
-v	ausführlicher (verboser) Modus. Gibt zusätzliche Meldungen zum Debuggen aus.

sftp

sftp ist ein interaktives Dateiübertragungsprogramm, ähnlich wie ftp, das alle Operationen über einen verschlüsselten ssh-Transfer durchführt. Es kann auch viele Funktionen von ssh nutzen, wie z.B. Authentifizierung mit öffentlichem Schlüssel und Komprimierung. sftp verbindet sich mit dem angegebenen Host, loggt sich dort ein und geht dann in einen interaktiven Befehlsmodus über.

Mit der Option -b ist jedoch auch eine skriptgesteuerte, automatisierte Sitzung möglich. Dazu muss jedoch mittels sshd und ssh-keygen eine nicht-interaktive Authentifizierung eingerichtet werden.

Kommandos für den interaktiven Modus von sftp

Diese Kommandos entsprechen in der Regel denen von FTP. Wird in der folgenden Übersicht eine Variable DATEI erwähnt, so kann dies auch ein ganzer Pfad zur entsprechenden Datei sein. Auch die üblichen Zeichen wie * oder ? (glob) sind möglich. Angaben in eckigen Klammern [PFAD] sind optional.

Befehl	Beschreibung
bye	Quit sftp
cd PATH	auf dem entfernten Host zum Verzeichnis PATH wechseln
chgrp GP DATEI	Gruppenzugehörigkeit der Datei zu GRP ändern (GRP = numerische GID)
chmod MODUS DATEI	Zugriffsberechtigung ändern
chown USER DATEI	Eigentümer der Datei ändern
df [-hi] [PFAD]	zeigt den verfügbaren Platz auf den Dateisystemen an. Option -h Größen in Potenzen von 1024 ausgeben (z.B. 123M) Option -i Inode‐Informationen ausgeben
exit	Quit sftp
get ENTFERNTER_PFAD [LOKALER-PFAD]	kopiert den Inhalt des entfernten Pfades nach dem lokalen Pfad
help	Anzeige eines Hilfetextes
lcd PFAD	wechselt zum lokalen Pfad. Entspricht dem Bash-üblichen Kommando cd
lls [PFAD]	listet die Dateien auf. Entspricht dem Bash-üblichen Kommando ls, es können auch die ls-Optionen angegeben werden
lmkdir DIR	erzeugt lokales Verzeichnis DIR (wie mkdir)
ln [-s] ALTERPFAD NEUERPFAD	erzeugt einen Link von ALTERPFAD auf NEUERPFAD. Option -s = Softlink, sonst Hardlink
lpwd	Ausgabe des lokalen Verzeichnisses
ls [DIR]	listet Inhalt des entfernten Verzeichnisses auf (es können auch die üblichen ls-Optionen angegeben werden)
mkdir DIR	erzeugt entferntes Verzeichnis DIR (wie mkdir)
progress	Anzeige über den Fortschritt des Kopiervorgangs
put LOKALER-PFAD [ENTFERNTER_PFAD]	kopiert den Inhalt des lokalen Pfades nach dem entfernten Pfad
pwd	Ausgabe des entfernten Verzeichnisses
quit	Quit sftp
reget ENTFERNTER_PFAD [LOKALER-PFAD]	versucht abgebrochene Dateiübertragungen (get) wieder aufzunehmen
reput LOKALER-PFAD [ENTFERNTER_PFAD]	versucht abgebrochene Dateiübertragungen (put) wieder aufzunehmen
rename ALTERPFAD NEUERPFAD	Umbenennung von ALTERPFAD zu NEUERPFAD
rm DATEI	löscht die entfernte Datei
rmdir VERZEICHNIS	löscht entferntes Verzeichnis
symlink ALTERPFAD NEUERPFAD	erzeugt einen symbolischen Link von ALTERPFAD auf NEUERPFAD
version	Anzeige der sft Protokoll-Version
!Kommando	führt Kommando in der lokalen Shell aus
!	wechselt zur lokalen Shell
?	Hilfe

sonstige Werkzeuge

Auflistung verschiedener nützlicher Tools zu Benutzung mit ssh

Da manche Tools in einem Sammelpaket enthalten sind wird in der zweiten Spalte das betreffende Paket aufgeführt. Ist diese Spalte leer, so ist der Tool-Name gleich dem Paketnamen.

Name	Paket	Beschreibung
autossh		SSH-Sitzungen und -Tunnel automatisch neu starten
mosh		Shell (nicht nur) für Mobilgeräte, unterstützt Roaming und intelligentes lokales Echo. Da stabiler als das ssh-eigene Terminal (versucht abgebrochene Verbindungen wieder aufzunehmen) kann sie gut als Ersatz eingesetzt werden
mussh		ermöglicht die gleichzeitige Ausführung von Kommandos oder Skripten über ssh auf mehreren Hosts
Plink (PuTTY Link)	putty-tools	verbindet sich mit einem entfernten System mittels SSH, Telnet oder rlogin und startet entweder eine interaktive Sitzung oder einen Batch-Prozess. Es unterstützt die üblichen SSH-Möglichkeiten wie Port-Weiterleitung, X11-Weiterleitung, SOCKS und Komprimierung
pnuke (parallel-nuke)	pssh	killt parallel Prozesse auf mehreren entfernten Hosts
prsync (Parallel rsync)	pssh	kopiert mittels rsync gleichzeitig Dateien auf mehrere Hosts
PSCP (PuTTY Secure Copy)	putty-tools	überträgt Dateien sicher zwischen Systemen über eine SSH-Verbindung. Es arbeitet sowohl mit SSH-Protokoll 1 als auch mit Protokoll 2
pscp (parallel-scp)	pssh	kopiert gleichzeitig Dateien auf mehreren Hosts
PSFTP (PuTTY SFTP-Client)	putty-tools	überträgt Dateien sicher zwischen Systemen über das SSH File Transfer Protocol (SFTP), welches spezifisch für das SSH-Protokoll 2 ist. Im interaktiven Modus ähnelt seine Oberfläche dem traditionellen Unix-FTP-Client, obwohl es auch im Batch-Modus betrieben werden kann
pslurp (parallel-slurp)	pssh	kopiert gleichzeitig Dateien von mehreren entfernten Hosts auf einen zentralen Host
pssh (parallel-ssh)		parallele Ausführung von Kommandos auf mehreren Hosts
PuTTYgen	putty-tools	generiert öffentliche und private SSH-Schlüsselpaare in einer beliebigen Anzahl von Formaten, einschließlich derjenigen, die PuTTY, OpenSSH und ssh.com nutzen können
restricted-ssh-commands		ermöglicht es, daß User nur eine begrenzte Zahl von Kommandos über SSH ausführen können. Was User dürfen, bzw. nicht dürfen, wird in einer Konfigurationsdatei festgelegt
rssh		User dürfen nur die Kommandos scp, sftp, cvs, svnserve (Subversion), rdist und rsync ausführen
rush		eingeschränkte Shell für Standorte, die nur begrenzten Zugriff auf Ressourcen für entfernte Benutzer bieten. Alternative zu rssh
TakTuk		gleichzeitige Ausführung von Kommandos auf mehreren entfernten Hosts
zssh		zum Übertragen von Dateien zwischen entfernten Rechnern, als Alternative zu scp besonders für schwächere Rechner und langsame Verbindungen geeignet

Weblinks

• OpenSSH Befehls-Übersicht
• So konfigurieren Sie benutzerdefinierte Verbindungsoptionen
• Wie kannst du SSH sicherer machen?
• Login als technischer User mit ssh forced commands geht auf die Option PermitRootLogin forced-commands-only ein und zeigt ein Wrapper-Shellscript, daß die Starrheit dieser Option beseitigt