Hallo, Andreas Pakulat <[EMAIL PROTECTED]>:
>> Um die .rhosts Semantik von rlogin/rsh/rcp nachbilden zu können. >> >> Diese besagt, dass sich User unter gleichem Benutzernamen auf der >> Zielmaschine ohne Passwort einloggen können, wenn die Zielmaschine der >> Quellmaschine entsprechend vertraut. > >Das klingt nach ssh public-key authentication und erfordert keinen >Port < 1024 auf der Quellmaschine. Lass mich raten: Du bist unter 25 und hast noch nie auf einem System ohne SSH mit rlogin, rsh und rcp gearbeitet? >> Das setzt authentische >> Informationen über den Benutzernamen auf der Quellmaschine >> voraus. Verbindungen von Quellports >= 1024 sind dazu nicht geeignet, >> da prinzipiell jeder Benutzer einem modifizierten rlogin Client mit >> gefaktem Benutzernamen selber compilieren könnte. > >Das verstehe ich nicht so ganz, was hat ein Benutzername mit Ports zu >tun, mal abgesehen davon dass man als Normalouser nur Ports >1024 >kriegt? Es war einmal, in grauer Vorzeit, ein Betriebssystem namens UNIX, welches sich in Universitäten großer Beliebtheut erfreute. Computer waren teuer; kein Student, Assistent und auch kein Professor konnte sich einen eigenen leisten. Also loggten sich die Benutzer auf dem UNIX-Cluster ihrer Universität ein, verfassten ihre Diplomarbeiten, Doktorarbeiten und Vorlesungsmanuskripte mit ed, vi, troff und TeX, programmierten in C und sh, schrieben E-Mails mit mail und msg und unterhielten sich über talk. Um sich auf einem anderen Rechner im Cluster einzuloggen, gab es Telnet. Nach Eingabe des Benutzernamens und des Passwortes konnte man auf dem anderen Rechner weiter arbeiten. Dass das Passwort und die Nutzdaten im Klartext übertragen wurden, störte keinen, denn das Netzwerk wurde ohnehin von den gleichen, wenigen Personen verwaltet wie der Rechnercluster selbst. Die Eingabe von Benutzernamen und Passwort war aber lästig, denn die Accounts und Passwörter und Homeverzeichnisse waren sowieso überall im Cluster die selben. Wer einmal auf einem Rechner eingeloggt war, der hatte seine Identität bereits nachgewiesen. Dies brachte findige Köpfe an der Universität zu Kalifornien in Berkeley auf die Idee, ein Protokoll namens rlogin zu entwerfen, was dieses Problem löst. Der Client überträgt beim Login den Benutzernamen des lokalen Benutzers. Wenn die Gegenstelle der Meinung ist, dass der Rechner des Clients zum Cluster gehört (identifiziert über die IP-Nummer) und damit vertrauenswürdig ist, dann wird der Login auf dem Zielrechner erlaubt, ohne dass eine erneute Authentifikation notwendig ist. Problematisch daran war aber, dass es Studenten gab, die, anstatt ihre Seminararbeiten zu schreiben und auf die Prüfungen zu lernen, lieber Programme schrieben, mit denen sich die Authentifikation von rlogin austricksen lies. Genauer gesagt programmierten sie einen Client, der das genaue Protokoll von rlogin sprach und damit von der Gegenseite nicht vom echten rlogin zu unterscheiden war. Er übertrug aber anstelle des eigenen Login-Namens den des Professors. Die Gegenseite war der Meinung, dass der Professor auf dem Quellhost bereits eingeloggt war, und erlaubte ein Login ohne Authentifikation auf dem Zielhost. Hier fanden die Studenten dann die Prüfungsfragen oder modifizierten die Gutachten für ihre Diplomarbeiten. Sie bestanden das Examen mit Auszeichnung und sind heute Politiker, Richter, Anwälte oder Aufsichtsräte. Da eine Volkswirtschaft sich nur eine begrenzte Anzahl Nieten in führenden Positionen leisten kann, ohne aufzufallen, musste eine Lösung her. So ersannen die findigen Köpfe an der Universität Berkeley, dass der rlogin-Daemon auf dem Zielhost auch die Quell-Portnummer des rlogin Clients als Authentifikationsmerkmal verwenden kann. Verbindungen mit Portnummern >= 1024 können von potenziell gefälschten rlogin Clients stammen, die einen falschen Benutzernamen angeben. Das unverfälschte Original-rlogin, welches vertrauenswürdig ist und immer den richtigen Benutzernamen übergibt, wird setuid-root gesetzt und öffnet damit seine Verbindungen immer von einer privilegierten Quellportnummer. Kein Student kann einen gefälschten rlogin-Client selber schreiben, der auch setuid-root läuft. Die Universitäten wurden wieder sicher und das Vertrauen in die Dekokratie kehrte zurück. Heute, viele Jahre nach dieser Idylle, reichen die Konzepte von rlogin, Telnet und Verwandten schon lange nicht mehr aus. Computer sind erschwinglich geworden; jeder Erstsemester bringt sein eigenes Notebook mit, auf dem er beliebige TCP-Verbindungen mit beliebigem Quellport erzeugen kann. Falls er selber nicht weiss, wie das geht, ergoogelt er sich ein Skript, zieht es von einem IRC Bot oder shared es in einer Tauschbörse. Merkmale wie Quellports oder auch IP-Nummern sind nicht mehr zu Zwecken der Authentifikation geeignet. Statt dessen gibt es Verschlüsselung, Public Key Authentifikation, Fingerprints und Zertifizierungshierarchien, die jede theoretische Angriffsmöglichkeit im Keim ersticken und allenfalls noch wegen ihrer ständigen Implementierungsfehler anfällig sind. Die Administratoren haben längst alle Vorkommen von rlogin, rsh und rcp auf ihren Systemen eliminiert und durch SSH ersetzt. Dennoch gibt es alternde Doktoranden und Habilitanten, die, anstelle endlich ihre Arbeit zzum Abschluss zu bringen, eine Arbeitsumgebung wie in den Anfängen erwarten. Daher unterstützt SSH die Semantik des Einloggens ohne Passwort zwischen Maschinen im selben Rechnercluster weiterhin. Natürlich unterwandert von Public Key Verschlüsselung mit Host Keys und anderem modernen Schnickschnack, aber für den Benutzer transparent. Nur taucht auch hier das selbe Problem von damals auf: ein SSH Client, der von Quellports >= 1024 kommuniziert, kann potenziell gefälscht sein; dem Usernamen, den er überträgt, kann nicht vertraut werden. Also setzt man den systemweit zur Verfügung gestellten Original-SSH-Client setuid-root; denn dieses Merkmal kann kein Benutzer fälschen. Die Zeiten haben sich geändert, und die Manpage von OpenSSH sagt dazu: [Note to the administrator: /etc/hosts.equiv, $HOME/.rhosts, and the rlogin/rsh protocol in general, are inherently insecure and should be disabled if security is desired.] Dennoch, sollten die Studenten, Assistenten, Habilitanten und Professoren von damals nicht gestorben, emeritiert oder exmatrikuliert sein, dann leben sie noch heute, loggen sich auf dem universitären UNIX-Cluster per rlogin ein und merken von der Migration auf SSH genau nichts. Gruß, Harald -- Harald Weidner [EMAIL PROTECTED] -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)