Client - Telnet & Co.

Übersicht Weiter

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 Zurück Anfang Weiter

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>

Die wichtigsten Optionen beim Start

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.«.

Die wichtigsten Kommandos im interaktiven Modus

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 Zurück Anfang Weiter

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.

Gleichsetzung von Benutzerkennungen

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.

rlogin

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.

rsh

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...).

rcp

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.

rexec

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

rwho und ruptime

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 Zurück Anfang

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 Konfiguration des Clients

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

Alle nachfolgenden Einstellungen, bis zur nächsten mit »Host« beginnenden Zeile betreffen einzig den/die angegebenen Rechner. Die Angabe kann die Wildcards »?« und »*« enthalten. Hiermit lassen sich also verschiedene Einstellungen für einzelnen Rechner und für Rechner eines Netzwerks treffen.

BatchMode

Die Abfrage nach dem Passwort oder der Passphrase (siehe später) wird unterbunden, somit lassen sich z.B. Kommandos in Shellscripts ausführen. Mögliche Werte sind »yes« oder »no«.

Cipher

Hier wird der zu verwendende Verschlüsselungsalgorithmus angegeben. Allerdings sollten Sie aus idea, des, 3des, blowfish, arcfour bzw. none nur den wählen, der sowohl von Ihrem Client als auch vom Server unterstützt wird.

Compression

Schaltet die Komprimierung der zu übertragenden Daten ein bzw. aus. Mögliche Werte sind »yes« oder »no«.

FallBackToRsh

Scheitert der Verbindungsaufbau zum Server (weil diese eventuell nicht aktiv ist), kann eine Verbindung über rsh versucht werden. Den Wert auf »yes« zu setzen, beschwört den ganzen Ärger der unsicheren rsh-Verbindung herauf...

ForwardAgent

Die Authentifizierung kann über einen »Vermittler« vorgenommen werden. Um dieses automatisch zu veranlassen, kann ForwardAgent auf »yes« gesetzt werden. Dieser Vermittler wird meist das Programm ssh-agent sein. Das Kommando sollte unmittelbar in der Login-Shell gestartet werden. Damit werden alle weiteren Prozesse automatisch Nachfahren des ssh-agent-Prozesses, letztlich auch der Aufruf eines ssh-Kommandos.

ForwardX11

X11 Verbindungen können automatisch über einen sicheren Kanal umgeleitet und die Variable $DISPLAY gesetzt werden. Mögliche Werte sind »yes« oder »no«.

IdentityFile

Die Datei enthält den geheimen RSA-Schlüssel des Benutzers. In den meisten Fällen wird der Benutzer nur ein IdentityFile (~/.ssh/identity) verwenden, dann kann auf die Angabe verzichtet werden. Weicht der Dateiname davon ab, muss das Schlüsselwort gesetzt werden. Dabei muss der Dateiname mit der Tilde beginnen!

PasswordAuthentication

Hier wird festgelegt, ob eine Abfrage des Passwortes durchgeführt werden soll oder nicht. Steht der Wert auf »no«, ist ein Anmelden auf einem entfernten Rechner nur möglich, wenn der eigene öffentliche Schlüssel dort bekannt ist.

Port

Die Portnummer, an die sich ssh verbinden soll.

RhostsAuthentication

Hier wird festgelegt, dass bei der Authentifizierung die Dateien rhosts und /etc/hosts.equiv ausreichen. Dieser Rückfall in die rhost-Zeiten ist eine Sicherheitslcke und sollte demensprechend auf »no« bleiben.

RhostsRSAAuthentication

Hier können die Benutzung von rhosts und /etc/hosts.equiv erlaubt werden, allerdings nur wenn die RSA-HOST-Authentifizierung erfolgreich war. Standardeinstellung ist »yes«.

RSAAuthentication

Hiermit kann die Authentifizierung mittels RSA-Verschlüsselung an- bzw. abgeschalten werden. Steht der Wert auf »yes«, sollte die Datei »~/.ssh/identity« oder ein Authentifizierungsagent existieren.

StrictHostKeyChecking

Ein »yes« verschärft die Sicherheit, indem das Anmelden nur auf Rechnern gestattet wird, die in den Datenbanken »/etc/known_hosts« bzw. »~/.ssh/known_hosts« enthalten sind. Steht hier »no« (Voreinstellung) werden neu besuchte Rechner automatisch der privaten Datei hinzugefügt.

TISAuthentication

Hier wird festgelegt, ob Authentifizierung ber TIS erlaubt ist. Diese Methode wird bei der Gauntlet Firewall und bei dem freie Firewall Toolkit (FWTK) der Firma Trusted Information Systems (TIS) verwendet.

UseRsh

Steht der Wert auf »yes«, wird ssh sofort eine Verbindung über rsh aufbauen und alle Optionen mit Ausnahme des Host-Feldes ignorieren.

Die Verwendung des Clients

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

Auf dem Zielrechner meldet man sich unter dem Kennzeichen von »Nutzer« an, anstelle des lokalen Nutzerkennzeichens.

-p port

Es wird sich beim Zielrechner zum angegebenen Port verbunden anstatt zum Port 22. An diesem Port sollte allerdings auch ein ssh-Server lauschen. ssh kann nicht zum Debuggen anderer Dienste genutzt werden.

-f

ssh geht nach dem Verbindungsaufbau in den Hintergrund. Gleichzeitig wird die Standardeingabe von /dev/null lesen (Vergleiche Option »-n«).

-i Datei

Anstatt der Datei ~/.ssh/identity wird die angegebene als privater Schlüssel verwendet

-n

Die Standardeingabe wird von /dev/null lesen. Das ist notwendig, wenn die ssh ein X-Programm auf dem entfernten Rechner starten soll, da dieses die Eingaben von der Standardeingabe lesen soll und nicht die ssh (Beispiel: »ssh erde -n xemacs &«).

Passwortfreies Login

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:

Gleichsetzung von Nutzerkennungen

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.

Authentifizierung mittels Hostschlüssel

Das Vorgehen ist einfach:

  1. 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.

     

  2. 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.

     

  3. 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:

Zukünftige Sitzungen sollten ohne Angabe eines Passwortes möglich sein.

Secure Copy

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.