telnet (Connection closed by foreign host)

[curdegn]

Hallo,

bin dabei ein minimales Linuxsystem (fürs Ram) zusammenzustellen. Die so zu entstehende Minidistribution soll per telnet erreichbar sein. Dazu habe ich folgende Dateien dazugepackt:

Binaries:
/usr/sbin/in.telnetd
/usr/sbin/inetd
/usr/sbin/tcpd

libraries:
alle die gebraucht werden (mit ldd ermittelt)

Config-files
-------------
/etc/hosts
/etc/hosts.allow (leer)
/etc/hosts.deny (leer)
/etc/inetd.conf (telnet-Zeile vom Komentarzeichen befreit)

Auf den so entstandenen Mini-telnet-server starte ich den inet-Daemon von Hand (inetd)

Problem:
Es sind keine telnet-Verbindungen möglich! (auch nicht lokal)
Fehlermeldung:
# telnet 192.168.0.1
Trying 192.168.0.1.....
Connected to 192.168.0.1 (also verbunden!)
Escape character is '^]'.
Connection closed by foreign host (auch bei "telnet localhost"!!!!)
#

Ich frage mich jetzt wo das Problem Liegt:
- eine wichtige Datei vergessen?
- ist inetd richtig gestartet? (ps zeigts an)
- kann der tcpd von inetd nicht gestartet werden?
- kann in.telnetd von inetd nicht gestartet werden?

Ich währe sehr froh um einige Tips zweks Eingrenzung des Problems.

Besonderheit:
Dieses Minilinuxsystem hat keine user nur root.

ÄNDERUNG WEGEN SCHREIBFEHLER (IN.TELNETD)

[DerLipper[TuX]]

und du weisst das bei telnet per default kein root login möglich ist?

Greetings,
Marko

[curdegn]

Ist mir bekannt. (kann man das umgehen?)

Die Verbindung bricht aber bereits vor der user- und Passwortabfrage ab.
Daher vermute ich den Knopf an einer anderen Stelle.

cucu

[Jinto]

Hast du Telnet in der inetd.conf freigeschaltet bzw. eingerichtet?

[curdegn]

Hast du Telnet in der inetd.conf freigeschaltet bzw. eingerichtet?

habe einfach die entsprechende Zeile vom Komentarzeichen befreit.

[unex]

Wenn keine Connection zum localhost geht:
Ist das Loopback Device up?

Poste mal bitte den Auszug von ifconfig.

[curdegn]

Ist das Loopback Device up?

Yep, ist up.

ping localhost:
----------------
PING localhost(127.0.0.1) from 127.0.0.1 : 56(84) bytes of data.
.........
...................... 0% loss

ifconfig:
---------
eth0 .......

lo
Link encap:Lokal Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:16 errors:0 dropped:0 overruns:0 frame:0
TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1344 (1.3kb) TX bytes:1344 (1.3 Kb)


Achtung Tipfehler!

cucu

[curdegn]

ich muss mich korrigieren. Meine kleine Minidistribution kennt überhaupt keine user (mit byld gemacht).

Könte es sein, dass in.telnetd unbedingt als ein user laufen will? (übrigens genau das gleiche problem mit in.ftpd)

cucu

[curdegn]

Hallo,
denke das Problem liegt an den fehlenden user (ein "whoami" ergibt "0").

Es ist mir gelungen den proftpd von Hand zu starten und Verbindungen dazu aufzunehmen (aber als wen soll ich mich anmelden wenn ja keine user existieren???). Den proftpd vom inetd starten zu lassen (mit oder ohne tcpd) ist mir jedoch nicht gelungen. Ich nehme an dass inetd versucht proftpd als ein bestimmter user zu starten, was ja nicht gelingen kann. Genau das gleiche vermute ich auch bei in.telnetd.

Was meint ihr zu dieser Diagnose?

cucu

PS:
Weiss jemand wie man root-user erzeugt (bzw. was gehört alles dazu)?

[maconey]

wie sieht die zeile im inetd aus die du auskommentiert hast?!

hast du auch sowas wie ein protokoll/bzw. ne fehlermeldung??

normalerweise werden inetd programme auch als root gestartet.
hast du den ftp server so konfiguriert das er über den inetd läuft?!

hm, ich halte von der diagnose erstmal gar nix, zu wenig infos :-)

[curdegn]

Guten morgen,
Vielen Dank für eure Antworten, dann werde ich mal das Problem ausführlich darstellen.

Situation
Wie gesagt bin ich dabei eine Mini-Linux-Distribution (zur Zeit 20 MB) zu erstellen. Die Basic-Unixbefhle (ls, mount etc.) sind bereits enthalten und funktionieren. Weit mehr Probleme habe ich mit dem telnetserver "in.telnetd". Dieser kann nicht von Hand gestartet werden und muss somit vom "inetd" ausgeführt werden. Dieser wiederum leitet die Verbindungsanfrage zuerst an den "tcpd" (zwecks Filterung ala hosts.allow bzw hosts.deny) weiter. Also zusammengefasst:
Telnetanfrage -> inetd -> tcpd -> in.telnetd -> antwort auf Anfrage

Problem
Irgendwo in dieser Kette ist der Wurm drin.

#
telnet 192.168.0.1
Trying 192.168.0.1.....
Connected to 192.168.0.1 (also verbunden!)
Escape character is '^]'.
Connection closed by foreign host (auch bei "telnet localhost"!!!!)
#

Vereinfachung
Um nicht gleichzeitig mit drei Dämonen (inetd, tcpd, in.telnetd) kämpfen zu müssen probiere ich zuerst einen FTP-server zum laufen zu bringen. Dabei habe ich mich für den "proftpd" entschieden weil dieser auch von Hand (ohne inetd) gestartet werden kann (es gibt leider keine Möglichkeit "in.telnetd" von Hand zu starten--darum dieses Ausweichmanöver).

proftpd ohne inetd
- kein inetd gestartet
- proftpd von Hand gestartet
Es funktioniert! Der Verbindungswunsch wird mit einer Loginaufforderung vom "proftpd" erwiedert. Aber als wen soll ich mich anmelden? Das System kennt keine User (ein "whoami" gibt einfach den wert 0 zurück)!
Grundsätzlich aber ein Erfolg und darum probiere ich nun den "proftpd" vom "inetd" starten zu lassen.

Auschitt aus "/etc/proftpd.conf" ohne "inetd"

....
#ServerType inetd
ServerType standalone
......
# Set the user and group that the server normally runs at.
#User nobody
#Group nogroup
...

proftpd mit inetd
- "proftpd" umkonfiguriert (/etc/proftpd.conf)
- "inetd" angepasst (/etc/inetd.conf)
- "inetd" von Hand gestartet
nmap zeigt daraufhin folgendes an:

# nmap 192.168.0.1
.........
Port State Service
21/tcp open ftp
23/tcp open telnet
37/tcp open time

Also "inetd" scheint zu funktionieren.
Eine FTP-Verbindung aufubauen gelingt jedoch nicht:

# ftp 192.168.0.1
Connected to 192.168.0.1.
421 Service not available, remote server has closed connection
ftp>

Dabei macht es keinen Unterschied ob "tcpd" dazwischengeschaltet wird oder nicht (hosts.allow und hosts.deny existieren und sind leer).

"/etc/proftpd.conf":

....
ServerType inetd
#ServerType standalone
.....

"/etc/inetd.conf" ohne "tcdp"

....
# ftp stream tcp nowait root /usr/sbin/tcpd wu.ftpd -a
ftp stream tcp nowait root /usr/sbin/proftpd proftpd
#ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd

"/etc/inetd.conf" mit "tcdp"

....
# ftp stream tcp nowait root /usr/sbin/tcpd wu.ftpd -a
ftp stream tcp nowait root /usr/sbin/tcpd proftpd
#ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd

Meine Diagnose
Ich glaube das "inetd" den "proftpd" nicht starten kann weil er diesen als 'root' ausführen will. Wie gesagt existieren auf diesem Minisystem keine user, nicht mal 'root' ('whoami' gibt '0' zurück). Auch das Ersetzen von 'root' mit '0' in "/etc/inetd.conf" hat nichts gebracht.

Was haltet ihr davon, bzw seht ihr das Problem an einer anderen Stelle?

uffff,
Curdegn

[Jasper]

Original geschrieben von curdegn
Meine Diagnose
Ich glaube das "inetd" den "proftpd" nicht starten kann weil er diesen als 'root' ausführen will. Wie gesagt existieren auf diesem Minisystem keine user, nicht mal 'root' ('whoami' gibt '0' zurück). Auch das Ersetzen von 'root' mit '0' in "/etc/inetd.conf" hat nichts gebracht.
[/B]

'whoami' gibt die id zurück, wenn es keinen namen dazu findet. es existiert immer ein user mit id==0, aber der muss nicht root heissen.

inetd erwartet aber einen usernamen. schreib doch einfach in /etc/passwd einen eintrag rein:

superhero:x:0:0:SuperHero:/:/bin/sh

und gib 'superhero'oder einen anderen dusslichen namen in inetd.conf an.

damit klappt dann auch getpwnam und inetd sollte zufrieden sein.

-j

[curdegn]

Aha, /"etc/passwd" hat damit was zu tun.

Habe nun den alten Inhalt von "/etc/passwd" (root::0:0::/:/bin/sh) durch (superhero:x:0:0:SuperHero:/:/bin/sh) ersetzt.

Leider gibt "whoami" immer noch '0' und nicht 'superhero' aus. Auch der Versuch den 'proftpd' vonHand als user 'superhero' zu Starten schlug fehl (- no such user 'superhero' ).

Der User 'superhero' existiert also trotz dem Eintrag in "/etc/passwd" immer noch nicht.
Was fehlt noch?
Hat jemand ein Tip?
Muss ich vielleicht was mit "pam" etc. tun?

cucu

[Jasper]

Original geschrieben von curdegn
Aha, /"etc/passwd" hat damit was zu tun.

Habe nun den alten Inhalt von "/etc/passwd" (root::0:0::/:/bin/sh) durch (superhero:x:0:0:SuperHero:/:/bin/sh) ersetzt.

Leider gibt "whoami" immer noch '0' und nicht 'superhero' aus. Auch der Versuch den 'proftpd' vonHand als user 'superhero' zu Starten schlug fehl (- no such user 'superhero' ).

Der User 'superhero' existiert also trotz dem Eintrag in "/etc/passwd" immer noch nicht.

wenn du bereits einen eintrag in /etc/passwd drin hattest, haettest du den superhero nicht reinsetzen müssen. wie weit hast du das system abgespeckt? welche glibc? glibc mit nss-support compiliert? nss-libs installiert? mach mal auf einem 'normalen' system ein 'strace whoami'. wiederhol das ganze auf deinem minisystem. anhand der unterschiede solltest du rausfinden, wo es klemmt.

-j

[curdegn]

Vielen, vielen tausend Dank!
Das mit den vergessenen nss-libs war ein Volltreffer! Warum werden diese von "ldd" nicht angezeigt?!

Nun geht es voran, es erscheinen endlich Fehlermeldungen(freu) die sagen was
noch fehlt (bin/login, /etc/logi.defs, etc. ).

-Habe also noch zu tun.
-Melde mich bei Erfolg (und vorallem bei nichterfolg:-)

cucu

PS
Falls sich jemand für mein Minifilesystem interessiert (aus Suse 7.3 extrahiert):
ftp://insieme.serveftp.org/insieme-d.../byld-1.0/root
ist aber noch in Arbeit!!!