rlogind / rlogin / rsh Konfiguration bei SLES 10

[DunklerRabe]

Ahoi,

ist hier jemand etwas älter als ich und kennt rlogin noch aus seiner aktiven Linux Zeit? Ich bräuchte eine Erklärung wie man das Geraffel vernünftig konfiguriert (und eigentlich auch benutzt ), mir würde auch ein Link zu einem halbwegs aktuellen (!) HowTo für Linux (!) reichen. Hab nur ein paar alte gefunden für ältere Unixe, die treffen nicht wirklich zu.
Der Dienst ist installiert und schon mit dem xinetd gestartet, es geht also nurnoch um Konfiguration und Benutzung.
Schonmal vorab besten Dank!

 

[Sannyboy111985]

Mal ganz erhlich, was willst du heute noch mit den r-Diesnten?!
Wärst du mit einem SSH nicht viel besser aufgehoben.

Abgesehen davon gibt es da nicht viel zu Konfigurieren, soweit ich weiß. Läuft alles über PAM und die User.

 

[DunklerRabe]

Glaubst du ich würde nach dem Mist fragen, wenn ich das nicht wirklich bräuchte?

 

[ekin06]

Kann auch nur von rlogin abraten und ssh(d) benutzen. Wer heutzutage noch rlogin oder telnet benutzt handelt imo schon grob fahrlässig. Besser sshd installieren (falls noch nicht drauf) und die Möglichkeit des einloggens über rlogin abschalten.

Was die Konfiguration angeht kann ich mich Sannyboy111985 nur anschliessen.

 

[DunklerRabe]

Das ist ja toll das du davon abrätst, davon hab ich aber GARNICHTS. Warum nicht? Weil die uralte Terminalemulation kein SSH kann sondern nur rlogin und es keine aktuellere Version gibt.

 

[Sannyboy111985]

Wenn der Rlogin über xinetd läuft muss der User sich einloggen dürfen.
Der Rest hängt von der lokalen Sicherheitseinstellung ab.
Vielleicht beschreibst du mal dein Problem etwas genauer.

 

[DunklerRabe]

Das hätte ich getan, ist aber garnicht so einfach. Der Server steht hier lokal, der Client entzieht sich aber meines Zugriffs Ich schätze es wird einfach ein "Connection refused" oder ähnliches geben. Die Menschen am anderen Ende sich auch fachlich nicht versiert genug um das genau zu beschreiben, geschweige denn auf einen anderen Login Mechanismus zu wechseln. Ich bin noch dabei, mir ein passendes Tool zu besorgen, dass mit rlogin umgehen kann um selber testen zu können.

 

[Sannyboy111985]

In die /var/log/messages und /var/log/secure bzw allgemein in die Login-Logs haste mal geschaut, nehm ich an.
Möglicherweise gibt es auch eine Firewall die blokiert.

Grundsätzlich ist das zum Debuggen aber schlecht. Jede Linuxbox kann im zweifel rlogin nutzen.

 

[DunklerRabe]

Firewall gibts auf dem System nicht. Wenn man über putty connected (ganz verdrängt das der rlogin kann ) spuckt die messages folgendes aus:
Jun 30 13:43:18 Ziel-Host in.rshd[14838]: connect from Quell-IP
Jun 30 13:43:18 Ziel-Host rshd[14838]: rsh denied to user@Quell-Host as : Permission denied.
Jun 30 13:43:18 Ziel-Host rshd[14838]: rsh command was 'xterm/38400'

Ich hab dem User, der für die remote Verbindung, eine .rhosts in sein homedir gelegt und den Quellhost und Zieluser angegeben. Ich weiß aber nicht, ob das überhaupt korrekt ist.

 

[Sannyboy111985]

Schau mal was in der /etc/security/access.conf steht
und ansonsten hilft wohl auch ein "man rlogin"

 

[DunklerRabe]

Die Manpages sind nicht grad der Kracher, hab ich natürlich schon reingeschaut.
Wir haben uns jetzt schonmal drauf geeinigt erstmal telnet zu nehmen. Das ist nicht besser, geht aber einfacher. Nimmt aber den Zeitdruck etwas weg.
In die access.conf schau ich morgen mal rein!

 

[ekin06]

Das ist ja toll das du davon abrätst, davon hab ich aber GARNICHTS. Warum nicht? Weil die uralte Terminalemulation kein SSH kann sondern nur rlogin und es keine aktuellere Version gibt.

Sorry aber woher soll ich das wissen? Du hast weder Angaben zum System noch zum Client gemacht.

 

[DunklerRabe]

Davon sollte man ausgehen, ich frag ja nicht umsonst nach so einem Krempel, den ich eigentlich selbst nicht will
Ist aber auch egal, es wurde entschieden bei telnet zu bleiben. Naja...

 

[Sannyboy111985]

Schön das dein Problem gelöst ist, auch wenn es vielleicht nur ein Workaround ist

Im übrigen gibt es hier viele Leute die nach Lösugen fragen wie etwas geht, obwohl es eine bessere und vielleicht auch einfache Lösung geben könnte.