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)
