Client - Telnet & Co. |
Übersicht |
Die in diesem Abschnitt vorgestellten Client-Anwendungen arbeiten alle auf der Konsole. Ihre Gemeinsamkeit liegt im Versuch, die Ausführung von Kommandos auf entfernten Rechnern dem lokalen Verfahren anzugleichen. Der wesentliche Unterschied aus Sicht eines Anwenders ist die Sicherheit der einzelnen Mechanismen.
Telnet ermöglicht dabei »nur« eine Sitzung auf dem entfernten Rechner, während die r-Utilities und die Secure Shell auch Kommandos zum Kopieren zwischen Rechnern und zum entfernten Ausführen von Programmen beinhalten.
Etwas genauer werden die dahinter stehenden Prinzipien im Abschnitt Server - Telnet&Co beleuchtet.
Telnet |
Telnet ermöglicht das Eröffnen einer Sitzung auf einem entfernten Rechner. Das zu Grunde liegende Protokoll TELNET wurde so entworfen, dass es auch in heterogenen Umgebungen zuverlässig arbeiten kann. Als Folge daraus ist die Arbeit über telnet halt doch nicht ganz so, als würde man lokal seine Eingaben tätigen.
In der Hauptsache ist es die Verfügbarkeit einiger Tastenkombinationen, die bei lokalem Aufruf eventuelle Sonderfunktionen implementieren, während einer Telnet-Sitzung allerdings als Steuerzeichen interpretiert werden und damit dort in der gewohnten Terminologie nicht zur Verfügung stehen.
Das Mapping zwischen den lokalen Einstellungen und denen auf dem Server wird daher auch als Terminalemulation bezeichnet und es existieren eine Reihe von Standards (bspw. vt100, vt220, xterm), die alle Clients und Server unterstützen sollten.
Zahlreiche Optionen des Telnet-Clients telnet beschäftigen sich daher auch mit den Einstellungen der Emulation und bei Initiieren einer neuen Telnet-Sitzung handeln Client und Server zunächst die Sitzungsparameter aus:
user@sonne> telnet telnet> toggle options Will show option processing. telnet> open localhost Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. SENT DO SUPPRESS GO Ahead SENT WILL TERMINAL TYPE SENT WILL NAWS SENT WILL TSPEED SENT WILL LFLOW SENT WILL LINEMODE SENT WILL NEW-ENVIRON SENT DO STATUS SENT WILL XDISPLOC RCVD DO TERMINAL TYPE RCVD DO TSPEED RCVD DO XDISPLOC RCVD DO NEW-ENVIRON RCVD WILL SUPPRESS GO Ahead RCVD DO NAWS SENT IAC SB NAWS 0 80 (80) 0 22 (22) RCVD DO LFLOW RCVD DONT LINEMODE RCVD WILL STATUS RCVD IAC SB TERMINAL-SPEED SEND SENT IAC SB TERMINAL-SPEED IS 38400,38400 RCVD IAC SB X-DISPLAY-LOCATION SEND SENT IAC SB X-DISPLAY-LOCATION IS "sonne.galaxis.de:0" RCVD IAC SB NEW-ENVIRON SEND SENT IAC SB NEW-ENVIRON IS VAR "PRINTER" VALUE "lp" \ VAR "DISPLAY" VALUE "sonne.galaxis.de:0" RCVD IAC SB TERMINAL-TYPE SEND SENT IAC SB TERMINAL-TYPE IS "XTERM" RCVD DO ECHO SENT WONT ECHO RCVD WILL ECHO SENT DO ECHO Welcome to Linux (i386) - Kernel 2.4.18 (pts/3). sonne login: |
Anhand der Ausgaben ist das Frage-Anwort-Spiel zwischen Client und Server leicht nachzuvollziehen. Der Client sendet »SENT« zum einen, bittend »WILL« (ich möchte...), zum anderen, fordernd »DO« (ich mache...) oder auch ablehnend »WONT« (ich möchte nicht...) seine Verhandlungspositionen zum Server, welcher antwortet und seinerseits Vorschläge zur Sitzungsgestaltung einbringt. Im Beispiel strebt der Client den »Linemode« an (SENT WILL LINEMODE), der Server lehnt den Wunsch ab (RCVD DONT LINEMODE)... Sind alle Parameter der Sitzung geklärt, sendet der Server die Login-Aufforderung.
Das Anmelden mit der Nutzerkennung »root« wird in den meisten Fällen scheitern, da der Terminal-Zugang nicht als sicher einzustufen ist. Die Terminals für das Root-Login müssen explizit in der Datei /etc/securetty benannt sein.
Während einer Sitzung kann die Terminalemulation des Servers beeinflusst werden, indem die dortige Shellvariable $TERM mit einem neuen Wert exportiert wird, auch kann der Kommandomodus von telnet über das so genannte Fluchsymbol [Ctrl][AltGr][9] erreicht werden. Nach Eingabe der meisten Kommandos gelangen Sie zur aktuellen Sitzung zurück:
user@sonne> telnet localhost -a Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Password: Last login: Wed Jun 21 09:18:40 from localhost user@sonne> export PS1="user@telnet> " user@telnet> [Ctrl][AltGr][9] telnet> status Connected to localhost. Operating in single character mode Catching signals locally Remote character echo Local flow control Escape character is '^]'. <Enter> user@telnet> logout Connection closed by foreign host. user@sonne> |
telnet [-a] [-d] [-x] [-l <Benutzername>] [Servername] [Portnummer] |
Wichtige Optionen beim Start von telnet sind neben der Angabe des Zielrechners eine nachfolgende Portnummer, falls Telnet sich nicht an den Standardport 23 des Zielrechners verbinden soll. Diese Möglichkeit spielt vor allem zum Debuggen bestimmter Dienste eine Rolle, allerdings lassen sich nicht alle Dienste auf so einen interaktiven Plausch ein.
Das nachfolgende Beispiel zeigt eine andere Art Mails zu versenden, den direkten Dialog mit Sendmail (SMTP an Port 25)...
user@sonne> telnet sonne smtp Trying 192.168.10.101... Connected to sonne.galaxis.de Escape character is '^]'. 220 sonne.galaxis.de ESMTP Sendmail 8.12.2/8.12.2; Tue, 2 May 2002 14:44:05 +0200 HELO galaxis.de 250 sonne.galaxis.de Hello user@sonne.galaxis.de [192.168.10.101], pleased to meet you HELP 214-This is Sendmail version 8.8.8 214-Topics: 214- HELO EHLO MAIL RCPT DATA 214- RSET NOOP QUIT HELP VRFY 214- EXPN VERB EtrN DSN 214-For more info use "HELP <topic>". 214-To report bugs in the implementation send email to 214- sendmail-bugs@sendmail.org. 214-For local information send email to Postmaster at your site. 214 End of HELP info MAIL FROM:user@galaxis.de 250 user@galaxis.de... Sender ok RCPT TO:root@sonne.galaxis.de 250 root@sonne.galaxis.de... Recipient ok DATA 354 Enter mail, end with "." on a line by itself <ENTER> Date: Mon Apr 1 11:11:11 MEST 2000 From: <user@sonne.galaxis.de> To: <root@sonne.galaxis.de> Subjects: demonstration this is the mail body. . 250 OAA01356 Message accepted for delivery QUIT 221 sonne.galaxis.de closing connection Connection closed by foreign host. |
Mit der Option -a wird das automatische Anmelden beim Server versucht, d.h. der lokale oder der mit der Option -l Name angegebene Nutzername wird automatisch als Loginname gesetzt (indem die Variable $USER gesetzt und exportiert wird) und es erscheint nur noch die Passwortabfrage. Bei Eingabe eines falschen Passwortes erscheint ein neues Login-Prompt. Wie viele Fehlversuche zulässig sind, bevor der Server die Verbindung kappt, hängt von dessen Konfiguration ab.
Zum Debuggen einer Sitzung kann die Option -d angegeben werden, sie erfordert allerdings Root-Rechte.
Neuere Telnet-Versionen sollen auch verschlüsselte Sitzungen unterstützen, indem sie mit der Option -x initiiert werden, allerdings erntete ich bislang immer die Ausschrift «telnet: Warning: -x ignored, no ENCRYPT support.«.
Um innerhalb einer Telnet-Sitzung Verbindung zu einem Server aufzunehmen, dient das Kommando open:
telnet> open sonne.galaxis.de 25 |
Die Kommandos logout und close besitzen dieselbe Bedeutung und beenden die aktuelle Verbindung. Ein quit beendet zusätzlich die Telnet-Sitzung.
Mit set bzw. unset lassen sich Variablen von Telnet setzen bzw. löschen. Variablen beeinflussen u.a. die Wirkungsweise von Kommandos oder sie steuern die Behandlung von Sonderzeichen. Geben Sie innerhalb von Telnet »set ?« ein und Sie erhalten eine Liste der unterstützten Variablen nebst kurzer Erläuterung.
telnet> set ? echo character to toggle local echoing on/off escape character to escape back to telnet command mode rlogin rlogin escape character tracefile file to write trace information to The following need 'localchars' to be toggled true flushoutput character to cause an Abort Output interrupt character to cause an Interrupt Process quit character to cause an Abort process eof character to cause an EOF ... |
Das Kommando status wurde im letzten Beispiel schon benutzt und zeigt die wichtigsten Eigenschaften der aktuellen Sitzung an. Auch toggle war bereits in Erscheinung getreten. Es schaltet einfach die Flags des Arguments um (zwischen TRUE und FALSE). Zwei interessante Argumente zur Überwachung des Datenaustauschs zwischen Client und Server sind options, das die Protokollbearbeitung veranschaulicht, und netdata, womit der Netzwerkverkehr in hexadezimaler Form überwacht werden kann.
Die r-Utilities |
Die r-Utilities sind eine Sammlung von Netzwerkkommandos, die einige wichtige Unix-Kommandos um die Netzwerkfähigkeit erweitern. Zu den Kommandos zählen: rlogin, rsh, rcp, ruptime, rwho und rexec. Trotz der mit den Kommandos verbundenen Sicherheitsrisiken ist ihr Einsatz in geschlossenen Unix-Netzwerken weit verbreitet.
Vorab sei bemerkt, dass die in Form der Manuals beiliegenden Dokumentationen zu den nachfolgenden Kommandos nicht mit den Möglichkeiten dieser übereinstimmen. Rufen Sie »<Kommando> --help« auf und vergleichen Sie die Liste der Argumente mit denen aus dem Manual.
Diese Möglichkeit betrifft die Kommandos rlogin, rsh und rcp und erlaubt bei entsprechender Konfiguration das passwortfreie Anmelden auf dem Zielrechner. Die Authentifizierung eines Benutzers erfolgt dabei anhand von Tabellen, die Paare von Rechnernamen und Benutzerkennzeichen enthalten. Der Administrator des Servers kann hierzu eine global gültige Datei /etc/hosts.equiv anlegen, so dass ein in ihr enthaltener Benutzer, der vom benannten Rechner aus die Anmeldung unter dem selben Benutzernamen versucht, sofortigen Zugang erhält. Einziges Benutzerkennzeichen, dem niemals passwortfreier Zugang gewährt wird, ist root.
Sollte in der Datei »/etc/hosts.equiv« keine Übereinstimmung eines Rechner-Benutzer-Paares gefunden werden, so wird im Heimatverzeichnis des Benutzers nach einer Datei .rhosts gesucht. Der Inhalt der Datei ist allerdings nur relevant, wenn diese Datei root oder dem Benutzer selbst gehört und sie nur vom Eigentümer beschreibbar ist. Der Aufbau dieser Datei ist analog zum Aufbau der /etc/hosts.equiv:
user@sonne> cat ~/.rhosts localhost user erde.galaxis.de tux melmac.outside.all tux melmac.outside.all alf |
Der Benutzer »tux« erhält von den Rechnern »erde.galaxis.de« und »melmac.outside.all« aus passwortfreien Zugang unter der Kennung »user« auf dem Rechner »sonne.galaxis.de«. »alf« darf nur von »melmac.outside.all« aus ohne Angabe des Passwortes zugreifen und damit es auch lokal für den Benutzer selbst funktioniert, ist auch ein lokaler Eintrag enthalten.
Remote Login gleicht funktioniell sehr stark dem Kommando telnet. Es verbindet sich zu einem Server (rlogind, TCP-Port 513), der eine Login-Prozedur startet und die Verbindung über ein Pseudoterminal betreibt. Im Unterschied zu telnet kennt rlogin kein Protokoll, um Übertragungsparameter mit dem Server auszuhandeln.
Verbinden Sie sich recht häufig mit einunddemselben Server, so lässt sich der Tippaufwand verringern, indem Sie einen Link unter dem Rechnernamen des Servers auf das Programm rlogin angelegen:
user@sonne> ln -s /usr/bin/rlogin localhost user@sonne> ./localhost Last login: Sat Jul 8 16:42:56 from localhost Have a lot of fun... user@sonne> ~. rlogin: closed connection. |
Zum Beenden einer rlogin-Sitzung geben Sie entweder [Ctrl][D] oder das Escape-Zeichen (Voreinstellung ist die Tilde) gefolgt von einem Punkt ("~.") ein. Alternativ endet die Sitzung, sobald Sie die Shell auf dem Server beenden (exit).
Wichtigste Kommandozeilenoptionen sind -l <Nutzername>, das die Anmeldung auf dem Server unter dem angegebenem Namen versucht, und -e <Escape-Zeichen<, um ein anderes Zeichen (als die Tilde) als »Fluchtsymbol« zu vereinbaren.
Remote Shell ermöglicht das Ausführen von Kommandos auf einem anderen Rechner. Serverseitig wartet der Dämon rshd auf TCP-Port 514. Wird rsh ohne Argumente aufgerufen, so ruft das Kommando implizit rlogin auf, um eine Sitzung auf dem Server einzuleiten. rsh wird normalerweise mit dem Servernamen und dem zu startenden Kommando aufgerufen. Letzterem können beliebig viele Argumente folgen, die direkt dem Server übergeben werden. Vergessen Sie nicht, enthaltene Sonderzeichen vor der Interpretation durch die lokale Shell zu schützen.
tux@erde> rsh sonne w user 5:09pm up 9:33, 3 users, load average: 0.16, 0.10, 0.02 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT user tty2 - 4:10pm 50:49 0.20s 0.13s -bash |
rsh bedingt den passwortfreien Zugang auf dem Server, sonst hagelt es nur ein »Permission denied«. Mit der Option -l <Nutzername> können Sie sich unter einem anderen Namen anmelden.
Einschränkungen: Ein paar Unterschiede zum lokalen Kommandostart gibt es dann doch... Zum einen geht der Rückgabewert des Kommandos verloren. Auch sollten Sie keine Editoren oder andere interaktiv arbeitende Kommandos entfernt starten, da Sie keine Möglichkeit haben, diese mit Eingaben zu füttern (der Start gelingt schon...).
Remote Copy ist das Netzwerkpedant zum lokalen cp. Nahezu alle Optionen (die im Netzwerk sinnvoll sind) des lokalen Vorbildes sind implementiert, u.a. auch -r zum rekursiven Kopieren ganzer Verzeichnisstrukturen. rcp vermag Dateien vom lokalen Rechner zu einem anderen zu übertragen, ebenso kann der umgekehrte Weg gegangen werden und es besteht sogar die Möglichkeit, den Kopiervorgang zwischen zwei entfernen Rechnern von der lokalen Konsole aus zu veranlassen.
Der Aufruf des Kommandos lautet:
rcp [[user1@]host1:]<Quelle(n)> [[user2@]host2:]<Ziel> |
»user« ist nur anzugeben, wenn sich das Nutzerkennzeichen des lokalen Benutzers von denen auf den entfernen Rechnern unterscheidet. Ist der lokale Rechner Ort der Quellen oder des Zieles, so kann auch die Angabe dessen Namens entfallen. Quelle und Ziel können die üblichen Metazeichen enthalten, jedoch müssen diese vor der Interpretation durch die Shell geschützt werden. Wird bei der Angabe der Dateinamen auf die Pfade verzichtet, bezieht sich diese immer auf das Heimatverzeichnis.
Remote Execute ist eine weitere Möglichkeit, um Kommandos auf einem anderen Rechner auszuführen. Im Unterschied zu rsh wird hier mit einer Login-Prozedur begonnen und ein verschlüsseltes Passwort gesendet. Das Kommando selbst ist mit Vorsicht zu genießen, da das permanente Prozedere mit dem Anmeldevorgang oft verleitet, die Option -p <Passwort> zu verwenden. Dieses Passwort muss auf der Kommandozeile im Klartext angeben werden, d.h. ggf. für in der Nähe befindliche Personen lesbar!
Um die Abfrage des Loginnamens zu unterdrücken, kann dieser mit der Option -l <Nutzername> als Argument angegeben werden.
user@sonne> rexec -l tux -p SchAuT_weG erde.galaxis.de
pwd /home/tux |
Remote Who und Remote Uptime erweitern die gleichnamigen Kommandos auf die Netzwerkumgebung, d.h. mit rwho erhalten Sie Informationen über alle im lokalen Netzwerk angemeldeten Benutzer (analog zum lokalen who) und ruptime zeigt u.a. die Laufzeit aller Rechner des Netzes an (Zeit seit dem letzten Systemstart).
Beide Kommandos werten die Informationen der Dateien im Verzeichnis »/var/spool/rwho« aus.
Diese Datei wird in regelmäßigen Abständen vom rwhod aktualisiert, der die lokalen Informationen per Broadcast ins Netz entlässt und die Nachrichten anderer Dämonen empfängt. In großen Netzen kann dadurch die Netzlast enorm anwachsen. Deshalb und auch aus Sicherheitgründen werden diese Dienste meist deaktiviert.
Secure Shell |
Solange wie es die Secure Shell schon gibt, sollte man meinen, angesichts der gravierenden Sicherheitslücken von Telnet und Remote Shell, sie hätte mit den Altlasten von Unix schon längst aufgeräumt. Doch leider ist Ihr Einsatz, trotz hoher Verfügbarkeit, noch nicht zur Selbstverständlichkeit erhoben worden.
Dabei sind verschlüsselte Übertragungen und passwortfreies Anmelden auf entfernten Rechnern doch genau das, was der Anwender sich wünscht. In diesem Abschnitt lernen Sie die Belange des ssh-Clients kennen.
Die default-Einstellungen zum Secure Shell Client legt der Systemverwalter in der Datei /etc/ssh_config fest, dem Benutzer bleibt es überlassen, eigene Konfigurationen in einer Datei ~/.ssh/config vorzunehmen. Existiert letztere Datei im Heimatverzeichnis des Benutzers, so wird das Kommando ssh diese beim Start einlesen, ansonsten entnimmt es die Informationen der globalen Datei.
user@sonne> cat /etc/ssh_config # Site-wide defaults for various options # Host * # ForwardAgent yes # ForwardX11 yes # RhostsAuthentication yes # RhostsRSAAuthentication yes # RSAAuthentication yes # PasswordAuthentication yes # FallBackToRsh yes # UseRsh no # BatchMode no # StrictHostKeyChecking no # IdentityFile ~/.ssh/identity # Port 22 # Cipher idea # EscapeChar ~ |
In der Beispieldatei sind alle Zeilen auskommentiert. In den allermeisten Fällen sollte dies die praktischen Bedürfnisse auch abdecken. Was sich hier dennoch konfigurieren lässt, möchten wir Ihnen nicht vorenthalten (eine Beschränkung auf ausgewählte Einträge sei uns gestattet):
Host
BatchMode
Cipher
Compression
FallBackToRsh
ForwardAgent
ForwardX11
IdentityFile
PasswordAuthentication
Port
RhostsAuthentication
RhostsRSAAuthentication
RSAAuthentication
StrictHostKeyChecking
TISAuthentication
UseRsh
Es ist an der Zeit, eine ssh-Sitzung zu eröffnen. Um einen Eindruck vom Ablauf das Anmeldens zu erhalten, schalten wir die erweiterte Ausgabe ein (Option -v):
user@sonne> ssh localhost -v SSH Version 1.2.27 [i686-unknown-linux], protocol version 1.5. Standard version. Does not use RSAREF. sonne: Reading configuration data /etc/ssh_config sonne: ssh_connect: getuid 500 geteuid 0 anon 0 sonne: Allocated local port 1023. sonne: Connecting to 127.0.0.1 port 22. sonne: Connection established. sonne: Remote protocol version 1.5, remote software version 1.2.27 sonne: Waiting for server public key. sonne: Received server public key (768 bits) and host key (1024 bits). sonne: Forcing accepting of host key for localhost. sonne: Host '127.0.0.1' is known and matches the host key. Creating random seed file ~/.ssh/random_seed. This may take a while. sonne: Encryption type: idea sonne: Sent encrypted session key. sonne: Installing crc compensation attack detector. sonne: Received encrypted confirmation. sonne: Remote: Server does not permit empty password login. sonne: No agent. sonne: Doing password authentication. user@127.0.0.1's password: |
Angenommen, unser Passwort besitzt nur 3 Zeichen...:
user@sonne> ssh localhost user@127.0.0.1's password: Permission denied. |
Offensichtlich verfügt der Server über eingebaute Regeln bezüglich der Passwort-Sicherheit. Ein Zugangsversuch mit »starkem« Passwort provoziert folgende Reaktion:
user@sonne> ssh localhost user@127.0.0.1's password: Last login: Fri Mar 31 21:45:35 2000 from localhost Have a lot of fun... No mail. user@sonne> |
Die folgende Sitzung läuft analog zur Arbeit am lokalen Terminal ab. Sämtlicher Datenverkehr geht verschlüsselt übers Netz.
Die Optionen zum Start von ssh sind vielfältig und die meisten werden Sie vermutlich niemals benutzen. Eine kleine Auswahl stellt die folgende Tabelle zusammen:
-l Nutzer
-p port
-f
-i Datei
-n
Prinzipiell ist eine derartige Konfiguration auf drei Wegen möglich. Zum einen über die Gleichsetzung von Nutzerkennungen über Rechnergrenzen hinweg (analog dem Vorgehen in der »/etc/hosts.equiv«) und zum anderen durch die Authentifizierung mittels der Hostschlüssel und zum dritten durch eine Kombination aus beiden. Die Konfiguration der beiden erstgenannten Methoden sei nun vorgestellt:
Diese Methode gilt als unsicher und wird deswegen in der Standardkonfiguration des Servers nicht unterstützt. Dennoch sei das Vorgehen auf Clientseite hier skizziert:
Root hat nun die Möglichkeit, in einer Datei »/etc/shosts.equiv« Paare aus Rechner- und optionalem Nutzernamen einzutragen. Einem Nutzer, der sich unter einem solchen Namen vom entsprechenden Rechner aus anmeldet, wird der Zugang ohne Angabe eines Passwortes gewährt. Er gilt als »vertrauenswürdig«. Der Aufbau der Datei »/etc/shosts.equiv« ist analog zur »/etc/hosts.equiv«.
Der gewöhnliche Nutzer kann ein analoges Verhalten durch Anlegen einer Datei ».shosts« in seinem Heimatverzeichnis auf dem Zielrechner erreichen. Dazu trägt er in dieser Datei Paare von Rechner- und Nutzernamen ein. Von einem solchen Rechner aus ist das passwortfreie Anmelden unter der spezifizierten Nutzerkennung möglich.
Das Vorgehen ist einfach:
Der Nutzer generiert ein Paar aus öffentlichem und privaten Hostschlüssel:
user@sonne> ssh-keygen Initializing random number generator... Generating p: ............................++ (distance 502) Generating q: ........................++ (distance 364) Computing the keys... Testing the keys... Key generation complete. Enter file in which to save the key (/home/user/.ssh/identity): Enter passphrase: Enter the same passphrase again: Your identification has been saved in /home/user/.ssh/identity. Your public key is: 1024 33 144548000807386124839939532430378957162277213079174901455237068977\ 13993164454787934083112964351134658543398198173290652861110361504461204252\ 86082551580924057298394318368461834360161039475113029221975820200295146587\ 33721792996155067287672215631707383807208031906784470444967930777546158765\ 712311197196260549233 user@sonne Your public key has been saved in /home/user/.ssh/identity.pub |
Tipp: Drücken Sie bei der Frage nach den Passphrasen [ENTER]. Wenn Sie dort etwas eingeben, müssen Sie die Eingabe bei jedem Login über ssh wiederholen. Somit ermöglichen Sie ein von Ihrem eigentlichen Passwort unabhängiges Passwort.
Der Nutzer meldet sich auf dem Zielrechner an:
user@sonne> ssh erde Last login: Sat Apr 1 11:38:19 2000 Have a lot of fun... No mail. |
Den öffentlichen Schlüssel ~/.ssh/identity.pub des lokalen Rechners (sonne) fügt der Nutzer an die Datei ~/.ssh/authorized_keys in seinem Heimatverzeichnis auf dem Zielrechner (erde) an.
Zum Kopieren zwischen den Rechnern existieren zahlreiche Möglichkeiten:
user@erde> scp user@sonne:~/.ssh/identity.pub user@erde:~/temp.key user@erde> cat temp.key >> .ssh/authorized_keys |
Zukünftige Sitzungen sollten ohne Angabe eines Passwortes möglich sein.
Während einer Secure Shell Sitzung würde der Aufruf des Kommandos cp nur das Kopieren von Dateien innerhalb des Dateisystems des Zielrechners ermöglichen. Um dennoch Daten zwischen Ziel- und Heimatrechner auszutauschen, ohne auf FTP oder rcp zurückgreifen zu müssen, steht das Kommando scp zur Verfügung.
scp verwendet zum Datentransfer die Secure Shell und bietet damit dieselben Authentifizierungsmechanismen und dieselbe Sicherheit. Der Aufruf besitzt folgendes Format:
Aufruf: scp [OPTIONEN] [[user@]host1:]filename1... [[user@]host2:]filename2 |
Die Angabe der Dateinamen unterscheidet sich nicht vom Vorgehen des »lokalen« cp, auch lassen sich wie gewohnt Verzeichnisse rekursiv mit der Option -r kopieren. Allerdings kommen nun noch die Namen der Nutzer und Rechner hinzu.
Der Nutzer (user) ist anzugeben, wenn sich das Nutzerkennzeichen auf dem Quell- bzw. Zielrechner vom lokalen Nutzerkennzeichen unterscheidet. Sonst kann die Angabe entfallen.
Der Rechnername (host) ist anzugeben, wenn es sich nicht um den lokalen Rechner handelt.
Im nachfolgenden Beispiel kopieren wir eine Datei vom Rechner »erde« unter dem dortigen Login »tux« auf den lokalen Rechner. Es sei vorausgesetzt, dass uns das passwortfreie Anmelden auf »erde« als »tux« möglich ist (falls dem nicht so ist, würden wir zur Eingabe eines Passwortes aufgefordert werden:
user@sonne> scp tux@erde:~/beispiel.txt . beispiel.txt 3 KB | 3.1 kB/s | ETA: 00:00:00 | 100% |
Neben dem schon genannten -r zum rekursiven Kopieren sind noch die Optionen -q und -C nützlich, die die Statistikausgabe verhindern bzw. eine Komprimierung der zu übertragenen Daten vornehmen.