TCP/IP Dienste |
Name Typ Protokoll Wartestatus UserID Server Argumente |
Dabei bedeuten
Hier als Beispiel die Auszüge aus der inetd.conf für ftp und telnet:
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd |
gaston# ps -ax | grep inetd 566 ? S 0:00 /usr/sbin/inetd gaston# kill -SIGHUP 566 |
silver> ftp gaston Connected to gaston.willemer.edu. 220 gaston.willemer.edu FTP server (Version 6.5/OpenBSD, linux port 0.3.2) ready. Name (gaston:arnold): arnold 331 Password required for arnold. Password: 230- Have a lot of fun... 230 User arnold logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> quit 221 Goodbye. silver> |
Daneben kennt ftp noch eine Reihe von Kommandos, die man natürlich in der Manpage findet. Letztlich reichen die vorgestellten Kommandos, um so ziemlich jeder Situation gewachsen zu sein.
Mit der Option -P kann ein anderer Port angesprochen werden. Das ist besonders wichtig bei dem Zugriff über Proxies.
Automatisieren des Einloggens
~/.netrc
In manchen Fällen soll der Austausch von Dateien automatisiert werden, also
beispielsweise durch Programme oder Skripten gesteuert und auch zeitversetzt
durch cron oder at
gestartet werden. In solchen Situationen stört die Passwortnachfrage.
Durch eine Datei namens .netrc im Heimatverzeichnis kann das
Einloggen automatisiert werden. Dabei enthält diese Datei in jeder Zeile die
Einträge:
Host Benutzerkennung Passwort |
Zuerst wird der Host angegeben. Wird dieser Host als Argument des ftp genannt, gilt diese Zeile. Es wird dann automatisch die angegebene Benutzerkennung verwendet und nicht wie sonst, die gleiche, die auf dem lokalen Rechner verwendet wird. Der Eintrag des Passworts ist optional. Ist ein Passwort eingetragen, muss die Datei mit chmod auf 600 gestellt werden. Sie darf also von niemandem gelesen werden können außer dem Besitzer.
# /etc/inetd.conf ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -A # |
Es gibt noch andere FTP-Server, wie beispielsweise der WuFTP-Server, der vor allem sicherheitskritische Einstellungen ermöglicht.
Das Trivial File Transfer Protocol wird auch manchmal Trusted FTP genannt.
Der Grund liegt darin, dass es keine Authentifizierung verlangt.
Der Zugriff ist nur auf Dateien erlaubt, deren Rechte auf dem System den
Zugriff für alle erlauben.
Auf den meisten Systemen ist TFTP in der inetd.conf abgeschaltet.
Seine Hauptbedeutung erlangte TFTP im Zusammenhang mit Workstations, die
keine eigene Festplatte besaßen, den >>diskless workstations<<. Diese
haben per TFTP ihre Grunddaten von anderen Maschinen bezogen.
Heutzutage findet man selten solche Geräte und aus Sicherheitsaspekten
ist TFTP wenig ratsam.
Der größte Unterschied zu FTP ist eigentlich in der Realisierung. TFTP basiert
auf udp, während FTP ein tcp Dienst ist.
Mit dem Programm telnet kann man eine Terminalsitzung über das Netz
auf einem fernen Rechner aufbauen. Aus Sicht des Anwenders unterscheidet sich
solch eine Sitzung kaum von einer Terminalsitzung.
Als Argument wird \verb+telnet+ die Internetnummer oder der Hostname des
Zielrechners angegeben. Auf dem Zielrechner wird ein login wie bei einem
normalen Terminal gestartet. Nach der erfolgreichen Anmeldung wird auf dem
Zielrechner eine Shell eröffnet und der Benutzer kann so
arbeiten, als hätte er eine Terminalsitzung auf der fremden Maschine eröffnet.
Die Sitzung wird durch das Ausloggen auf dem fremden Rechner beendet.
Da das ständige Authentifizieren beim Anmelden innerhalb eines LANs (Local
Area Network) in der
Praxis sehr störend ist, gibt es die Möglichkeit, direkt auf die ferne
Maschine zuzugreifen. Dabei erteilt der Anwender einem Benutzer einer anderen
Maschine die Berechtigung, seinen Zugang zu benutzen. Er erteilt diese
Berechtigung, indem er eine Datei namens .rhosts anlegt und in ihr
die Computer und Benutzer aufzählt, die ein direktes Zugriffsrecht über
die Kommandos rcp, rlogin und rsh haben sollen.
Die Befehle fragen nach der korrekten Konfiguration nicht mehr nach dem
Passwort. Wie immer stehen Bequemlichkeit und Sicherheit umgekehrt
proportional zueinander. Darum sind diese Protokolle auch sinnvollerweise
im LAN und nicht im Internet einzusetzen. Die drei r-Kommandos rcp
(remote copy), rsh (remote shell) und rlogin (remote login)
entstammen dem BSD und sind auf allen UNIX-Derivaten zu finden.
TFTP, schnell und vertrauensvoll
Terminaldienst (telnet)
telnet überträgt im Klartext.
Da telnet alle Tastendrücke und Bildschirmausgaben direkt über das Netz
überträgt, werden auch Passwörter im Klartext
über das Netzwerk übertragen. In sicherheitskritischen Umgebungen
werden darum Zugriffe per telnet ausgeschlossen. Statt dessen wird
ssh (secure shell) verwendet, das die gleiche Leistung bringt, nur dass die übertragenen
Daten verschlüsselt werden.
telnet-Client
Funktionstasten unzuverlässig
telnet leidet unter dem gleichen Problem wie die Terminals, nämlich
dass die Terminalemulationen leider auf den Funktionstasten immer wieder
versagen. In vielen Fällen werden Terminals emuliert, die gar keine
Funktionstasten hatten, als sie gebaut wurden. Wie beim Terminal auch, wird
die Terminalemulation über die Umgebungsvariable TERM und die Einträge in
der termcap oder der terminfo gesteuert.
Testen textorientierter Server
Mit telnet kann man sehr gut textorierentierte Protokolle testen,
wie sie von den meisten Internet-Services verwandt werden
(beispielsweise HTTP oder NNTP).
Beim Aufruf wird hinter dem Hostnamen als weiterer Parameter
die Portnummer des Services angegeben und
man sieht die Meldungen des Servers im Klartext. Man kann Antworten
und so das Protokoll verfolgen.
telnet-Dämon
/etc/securetty
In der Datei /etc/securetty wird hinterlegt, welche Terminals so
sicher sind, dass sich auch der Anwender root dort einloggen darf.
Im Normalfall werden dort die virtuellen Terminals, die telnet
verwendet dort nicht aufgeführt. Aus diesem Grund ist es meist nicht möglich,
sich als root per telnet direkt anzumelden. Statt dessen verwendet der
Administrator eine >>zivile<< Kennung und wechselt per su zum root.
Abschalten des Dämons
Auch der telnet-Server wird über den inetd gestartet. Dementsprechend
gibt es auch einen Eintrag in der inetd.conf. Soll es keinen
Zugriff per telnet auf die Maschine mehr geben, wird der Eintrag
einfach auskommentiert, indem ein # an den Anfang der Zeile gesetzt wird.
r-Kommandos
+gaston willemer +idefix + pm7500 +@awfriends |
Die erste Zeile erlaubt dem Anwender willemer auf gaston den freien Zugriff ohne Passwort. In der zweiten Zeile wird allen Anwendern von idefix der freie Eintritt gestattet.
Die dritte Zeile enthält einen gravierenden Fehler: Hier steht ein Leerzeichen zwischen dem Plus und dem pm7500. Das einzelne + wird so interpretiert, dass jeder(!) Rechner freien Zugriff hat. Dass der alleinstehende pm7500 dieses Recht auch hat, versteht sich dann von selbst.
In der vierten Zeile wird der Netzgruppe awfriends ein solcher Zugriff eingeräumt. Sie muss in der Datei /etc/netgroup definiert sein.
In allen Fällen müssen die Rechnernamen natürlich in der /etc/hosts stehen oder durch einen Namensdienst aufgelöst werden.
rcp Optionen Quelle Ziel |
Lediglich die Argumentbeschreibung ist etwas verändert. Ist Quelle oder Ziel auf einem anderen Rechner, wird vor den Pfadnamen der Rechnername gefolgt von einem Doppelpunkt gesetzt. Dies kann sowohl bei der Quelle als auch beim Ziel erfolgen. Werden bei Quelle und Ziel fremde Rechner angegeben, ist rcp so clever zu erkennen, dass es effizienter ist, die Kopie direkt zwischen den beiden Rechnern auszutauschen, ohne den Umweg über den Auftraggeber zu gehen.
rcp idefix:/etc/hosts* ./test |
Mit diesem Befehl werden vom Rechner idefix alle Dateien, die auf die Maske /etc/hosts* passen, an das im aktuellen Verzeichnis liegende test kopiert. test muss natürlich ein Verzeichnis sein, da zu erwarten steht, dass der Befehl mehrere Dateien kopieren wird. Werden die Dateien auf dem fremden Rechner nicht mit vollständigem Verzeichnis angegeben, wird vom Heimatverzeichnis auf der anderen Seite ausgegangen.
silver> ln -s `which rlogin` gaston silver> gaston Last login: Thu Mar 21 09:52:09 from gaston.willemer.edu Have a lot of fun... gaston> |
In der ersten Zeile wird ein symbolischer Link von dem Dateinamen gebildet, den der Befehl which liefert, mit dem Ziel gaston. Dieser zeigt dann auf den vollständigen Pfad von rlogin. Nun kann man gaston aufrufen. Über den symbolischen Link wird rlogin gestartet. Das Programm rlogin stellt fest, dass der Name unter dem es gerufen wurde, gaston lautet und verbindet zu gaston.
rsh host Befehl |
Mit der Option -l kann der Benutzer angegeben werden, unter dessen Kennung der Befehl ausgeführt werden soll.
PasswordAuthentication yes |
Das Abschalten der Option PasswordAuthentication ist möglich und macht auch Sinn, wenn beispielsweise ein Webserver, der im Zugriff des Internets steht, nicht von außen per ssh ansprechbar sein soll, sondern nur von internen Rechnern der Firma, die man entsprechend ausweist.
Für MS-Windows gibt es das freie Programm PUTTy, das einen ssh-Client mit und einen scp beinhaltet. Quelle:
http://www.chiark.greenend.org.uk/~sgtatham/putty
gaston> ssh-keygen Generating public/private rsa1 key pair. Enter file in which to save the key (/home/arnold/.ssh/identity) Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/arnold/.ssh/identity Your public key has been saved in /home/arnold/.ssh/identity.pub The key fingerprint is: 3b:a2:62:ed:02:ef:30:79:a1:4b:0b:b6:35:21:d8:f1 arnold@gaston gaston> |
silver> cd silver> rcp gaston:.ssh/identity.pub . silver> cat .ssh/identity.pub >> .ssh/authorized_keys silver> rm .ssh/identity.pub |
In hochsicherheitskritischen Umgebungen sollte man die Übertragung nicht unbedingt per rcp durchführen. Wenn die Konfigurationsdateien auf dem Standard stehen, kann sich nun der Benutzer arnold von gaston aus auf dem Rechner silver anmelden, ohne ein Passwort einzugeben.
gaston> ssh silver Last login: Mon Feb 25 00:04:06 2002 from mail.willemer.edu Have a lot of fun... silver> |
gaston> scp silver:/etc/passwd . passwd 100% |*****************************| 2071 00:00 gaston> |
Host * # ForwardAgent no # ForwardX11 no # RhostsAuthentication no # RhostsRSAAuthentication yes # RSAAuthentication yes # PasswordAuthentication yes # FallBackToRsh no # UseRsh no # BatchMode no # CheckHostIP yes # StrictHostKeyChecking yes # IdentityFile ~/.ssh/identity # IdentityFile ~/.ssh/id_dsa # IdentityFile ~/.ssh/id_rsa # Port 22 Protocol 1,2 # Cipher blowfish # EscapeChar ~ |
In der hier aufgestellten Umgebung würde man RhostsRSAAuthentication auf no stellen. Die Werte hinter Host bezeichnen die vom Client ansprechbaren SSH-Server. In diesem Fall sind das alle. Die Werte hinter Protocol bezeichnen, welche SSH Protokollversionen in welcher Reihenfolge unterstützt werden sollen.
IgnoreRhosts yes RhostsAuthentication no RhostsRSAAuthentication no RSAAuthentication yes PasswordAuthentication yes |
Mit diesen Werten ist das Einloggen ohne Passwort nur erlaubt, wenn eine Schlüsselübergabe stattgefunden hat. Alle rhosts-Mischformen sind ausgeschlossen. Ein direktes Einloggen mit der Eingabe eines Passwortes ist aber erlaubt.
silver> ssh gaston -L 2002:gaston:110 Last login: Sun Jul 7 11:32:27 2002 from silver.willemer.edu Have a lot of fun... gaston> |
Sobald diese Sitzung steht, kann auf dem Rechner silver ein Mailclient aufgerufen werden. In der Konfiguration des Mailprogramms wird als Server localhost, also silver angegeben. Der Port wird von 110 auf 2002 umgestellt. Versucht man nun nach Mail zu fragen, wird der Mailclient lokal auf silver den Port 2002 anfragen. Der ist aber über die ssh-Sitzung über eine gesicherte Verbindung mit dem Port 110 von gaston verbunden. Dieser Tunnel bleibt so lange bestehen, wie die ssh-Sitzung besteht. Mit dem Ausloggen ist auch der Tunnel nicht mehr zugreifbar.
Es gibt einen Modus, in dem ssh und scp wie rlogin und rcp über .rhosts konfiguriert werden können. So jedenfalls steht es in der Dokumentation. In der Literatur wird sogar von plug-in kompatibel gesprochen. Interessanterweise schweigt sich die entsprechende Literatur aber auch über die korrekte Konfiguration aus. Ich habe dies einmal schnell aufbauen wollen und nach einiger Zeit aufgegeben. In der Zwischenzeit hatte ich bequem die RSA-Variante konfigurieren können und es dann noch einmal erfolglos mit .rhosts probiert.
Wer also die r-Tools aufgrund von Sicherheitsbedenken durch die s-Tools ersetzen will, sollte sich selbst den Gefallen tun, gleich auf die Konfiguration mit RSA umzuschwenken.
|
Diese Seite basiert auf Inhalten aus dem Buch Arnold Willemer: Wie werde ich UNIX-Guru und dem Nachfolgebuch Arnold Willemer: UNIX - Das umfassende Handbuch Verlagsrechte bei galileo computing |
| Homepage |
(C) Copyright 2002-2009 Arnold Willemer
|