[debian] Probleempje met ssh na crash

[straat]

Ik heb een weekje geleden mijn server (p166mmx, 64MB, 60GB hdd) opnieuw geïnstalleerd na eindelijk mijn harddisk van IBM teruggehad te hebben. Ik heb er debian Woody op gezet, zooi progjes ge-apt-get, nieuwe kernel gebakken en alles werkte perfect. Maar nu merkte ik net opeens dat ik niet meer met ssh kon inlogen.

Dus even een monitor en keyboard aangesloten en ingelogd. Nu kreeg ik echter bij alles wat ik probeerde te starten een melding met een inhoud van "cannot fork". Zelfs rebooten wilde niet meer (INIT: cannot fork..). Ik kijk snel even naar mijn phpsysinfo page, daar zie ik dat het geheugen helemaal vol zit en de swap (300MB) ook. De load-averages waren ook niet laag om het even zacht uit te drukken (324.00 324.00 323.94). Na een druk op de resetknop leek alles weer te werken, echter sshd wil niet meer opstarten. Ik heb toen even "dpkg-reconfigure ssh" gedaan, zonder resultaat. Daarna helemaal verwijderd en de package opnieuw geïnstalleerd, wat ook niet hielp.

Ik heb even alle files in /var/log doorgespit maar kon niets vinden wat de oorzaak van mijn probleem zou kunnen zijn. Wel zag ik dat er sinds 11.40 vanmorgen al meldingen in kwamen "cannot fork".

Het moge duidelijk zijn dat ik er op dit moment even niets meer van begrijp, heeft iemand een idee waar ik de oorzaak van dit probleem zou kunnen zoeken?

[Verwijderd]

Welke kernel heb je gecompileerd?

[straat]

ik heb kernel 2.4.19

[Verwijderd]

Erg vreemd, kan je aan `top` niet zien welke processen geheugen staan te eten?

[LollieStick]

kijk even of er geen root-kits geinstalleerd zijn. Ook even ps aux bekijken of er geen vreemde taken draaien.

Cannot fork usually would indicate you are out of memory

Hoeveel geheugen heb je vrij? (commando 'free')

[straat]

normaal zit het geheugen niet vol, nu ook niet. Ik zou niet weten hoe het kwam dat het geheugen dus die ene keer zo vol zat. top geeft nu:

code:

Mem:     62304K total,    52080K used,    10224K free,     5580K buffers
Swap:   289160K total,     7340K used,   281820K free,    23856K cached

ps auxf geeft op zich nix vreemds aan lijkt het, maar misschien is dat wel het geval..

code:

[root@pinchi] /home/straat > ps auxf
USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.6  1272  432 ?        S    Nov10   0:03 init [2]
root         2  0.0  0.0     0    0 ?        SW   Nov10   0:00 [keventd]
root         3  0.0  0.0     0    0 ?        SWN  Nov10   0:00 [ksoftirqd_CPU0]
root         4  0.0  0.0     0    0 ?        SW   Nov10   0:01 [kswapd]
root         5  0.0  0.0     0    0 ?        SW   Nov10   0:00 [bdflush]
root         6  0.0  0.0     0    0 ?        SW   Nov10   0:00 [kupdated]
root         7  0.0  0.0     0    0 ?        SW   Nov10   0:00 [i2oevtd]
root         8  0.0  0.0     0    0 ?        SW   Nov10   0:00 [kjournald]
root        68  0.0  0.0     0    0 ?        SW   Nov10   0:00 [kjournald]
root        91  0.0  0.0     0    0 ?        SW   Nov10   0:00 [eth0]
daemon     100  0.0  0.4  1384  300 ?        S    Nov10   0:00 /sbin/portmap
root       415  0.0  1.5  2820  996 ?        S    Nov10   0:00 /sbin/mount.smbfs //night/data /data2 -o rw credentials /etc/passwords/night-data
root       481  0.0  1.1  2036  744 ?        S    Nov10   0:02 /sbin/syslogd
root       484  0.0  0.6  1360  428 ?        S    Nov10   0:00 /sbin/klogd
root       489  0.0  0.8  1444  512 ?        S    Nov10   0:00 /sbin/rpc.statd
root       498  0.0  0.8  1992  540 ?        S    Nov10   0:00 /usr/sbin/inetd
telnetd   3126  0.0  1.1  1460  700 ?        S    13:57   0:00  \_ in.telnetd: night
straat    3127  0.0  1.9  2208 1236 pts/0    S    13:58   0:00      \_ -bash
root      3130  0.0  2.0  2224 1256 pts/0    S    13:58   0:00          \_ bash
root      4510  0.0  2.4  3516 1520 pts/0    R    15:09   0:00              \_ ps auxf
root       502  0.0  1.0  2044  628 ?        S    Nov10   0:00 /usr/sbin/lpd
root       509  0.0  1.4  2180  896 ?        S    Nov10   0:00 /bin/sh /usr/bin/safe_mysqld
mysql      544  0.0  1.2 36452  808 ?        S    Nov10   0:00  \_ /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-locking
mysql      546  0.0  1.2 36452  808 ?        S    Nov10   0:00      \_ /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-locking
mysql      547  0.0  1.2 36452  808 ?        S    Nov10   0:00          \_ /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-locking
mysql      548  0.0  1.2 36452  808 ?        S    Nov10   0:00          \_ /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-locking
root       559  0.0  1.2  2704  788 ?        S    Nov10   0:00 /usr/sbin/nmbd -D
root       561  0.0  1.0  3576  660 ?        S    Nov10   0:00 /usr/sbin/smbd -D
root      3109  0.6  3.0  4020 1884 ?        S    13:53   0:28  \_ /usr/sbin/smbd -D
root       564  0.0  1.8  3776 1148 ?        S    Nov10   0:05 /usr/sbin/snmpd -s -l /dev/null
root       566  0.0  1.1  2712  692 ?        S    Nov10   0:00 /usr/sbin/snmptrapd -s
nobody     576  0.0  1.3  3628  812 ?        S    Nov10   0:00 proftpd (accepting connections)
root       581  0.0  0.9  1652  596 ?        S    Nov10   0:00 /usr/sbin/cron
root       585  0.0  5.4 74232 3416 ?        S    Nov10   0:01 /usr/sbin/apache
www-data  2126  0.0  4.9 74280 3084 ?        S    06:25   0:00  \_ /usr/sbin/apache
www-data  2127  0.0  6.4 74624 4012 ?        S    06:25   0:00  \_ /usr/sbin/apache
www-data  2128  0.0  5.0 74280 3124 ?        S    06:25   0:00  \_ /usr/sbin/apache
www-data  2129  0.0  4.9 74280 3088 ?        S    06:25   0:00  \_ /usr/sbin/apache
www-data  2130  0.0  4.9 74280 3088 ?        S    06:25   0:00  \_ /usr/sbin/apache
www-data  2919  0.0  6.0 74280 3744 ?        S    12:22   0:00  \_ /usr/sbin/apache
www-data  4494  0.0  5.9 74280 3696 ?        S    15:06   0:00  \_ /usr/sbin/apache
www-data  4497  0.0  5.9 74280 3696 ?        S    15:06   0:00  \_ /usr/sbin/apache
root       595  0.0  0.7  1256  448 tty1     S    Nov10   0:00 /sbin/getty -f /etc/issue.linuxlogo 38400 tty1
root       596  0.0  0.6  1256  396 tty2     S    Nov10   0:00 /sbin/getty 38400 tty2
root       597  0.0  0.6  1256  396 tty3     S    Nov10   0:00 /sbin/getty 38400 tty3
root       598  0.0  0.6  1256  396 tty4     S    Nov10   0:00 /sbin/getty 38400 tty4
root       599  0.0  0.6  1256  396 tty5     S    Nov10   0:00 /sbin/getty 38400 tty5
root       600  0.0  0.6  1256  396 tty6     S    Nov10   0:00 /sbin/getty 38400 tty6

Als ik sshd op probeer te starten, krijg ik verder geen output op het scherm oid dat er iets mis is, gewoon helemaal nix.

En hoe weet ik of ik een rootkit heb?

[Buffy]

Straat schreef op 11 November 2002 @ 15:11:
[..]

En hoe weet ik of ik een rootkit heb?

Niet door met 'ps' naar verdachte processen te kijken. als je een rootkit hebt kan je ps en consorten namelijk niet meer vertouwen.

Probeer eens http://www.chkrootkit.org

[straat]

Dawns_sister schreef op 11 november 2002 @ 15:40:
[...]


Niet door met 'ps' naar verdachte processen te kijken. als je een rootkit hebt kan je ps en consorten namelijk niet meer vertouwen.

Probeer eens http://www.chkrootkit.org

chkrootkit kan nix vinden dat geïnfecteerd is...

de oorzaak van het probleem is dus nog steeds niet duidelijk
de oplossing helaas ook niet

[Verwijderd]

Zet anders een cron jobje op wat om de 10 mins een ps axuww wegschrijft naar een file. De volgende keer dat het gebeurd heb je dan tenminste de offender, en kun je het probleem oplossen...

[Buffy]

Of top te laten lopen in console. Als INIT niet meer kan forken doet cron het ook niet meer.

[Verwijderd]

*heh* top ook niet (of meer correct, hij zal niet meer updaten)

imo is de cron oplossing beter, vooral om dat die informatie logt naar de disk, ipv top, die alleen maar output op de console laat zien. Op het moment dat je VM volzit, dan zal deze melding als een gek over je scherm heenscrollen, en is dus ook je top output weg ...

[straat]

mja ik heb nu wel een cronjobje ingesteld, maar dat zorgt er natuurlijk niet voor dat sshd weer werkt...

Ik kan me vaag herinneren dat ik hetzelfde wel eens eerder heb gehad (niet op-willen-startende sshd). Toen had ik het er bij laten zitten en later, toen ik debian woody een upgrade naar unstable gad, deed ie het weer, maar na een reboot ofzo ook niet meer. Wat toen de oorzaak was ben ik helaas vergeten, maar ik dacht dat het iets met geheugen te maken had maar dat weet ik helemaal niet zeker...

Ik heb net ook nog even de originele 2.4.18-bf24 kernel geboot die standaard geïnstalleerd word, wat geen effect had helaas Ik heb verder nog geen één enkal ander programma gevonden wat het opeens ook niet meer doet, sshd is echt de enige...

[Verwijderd]

nog ff snel voordat ik naar huis ga:

/path/to/sshd -d 3

Nu zal je sshd in debugging mode opstarten, en moet je in je system logs verbose logging zien.

[straat]

hmmz, in debug mode doet sshd het wel gewoon, ook met de -D optie doet ie het wel

code:

-D         Do not fork into daemon mode

Hier komt dat "fork" ook weer terug, wat is dat nou eigenlijk precies? Blijkbaar gaat er daar iets mis...

[Buffy]

Verwijderd schreef op 11 november 2002 @ 17:53:
*heh* top ook niet (of meer correct, hij zal niet meer updaten)

imo is de cron oplossing beter, vooral om dat die informatie logt naar de disk, ipv top, die alleen maar output op de console laat zien. Op het moment dat je VM volzit, dan zal deze melding als een gek over je scherm heenscrollen, en is dus ook je top output weg ...

Een proces dat eenmaal draait hoeft niet meer te forken en zal dus blijven draaien zolang het geen extra geheugen nodig heeft. Cron moet telkens een nieuw proces opstarten wat dus niet zal lukken.

Maar wat betreft het scrollen van het scherm met de foutmeldingen zou je wel eens gelijk in kunnen hebben. Dat kan je alleen oplossen door foutmeldingen niet meer naar console te laten loggen (en dat is mij nog nooit gelukt).

[active2]

Jij dat probleem ook al

Waarschijnlijk is je stack limit te laag.

Voor dat je ssh start moet je dit eens doen:

code:

ulimit -s unlimited

[deadinspace]

Straat schreef op 11 november 2002 @ 19:43:
hmmz, in debug mode doet sshd het wel gewoon, ook met de -D optie doet ie het wel

code:

-D         Do not fork into daemon mode

Hier komt dat "fork" ook weer terug, wat is dat nou eigenlijk precies? Blijkbaar gaat er daar iets mis...

fork() is een systemcall die het huidige process dupliceert. Als sshd start, dan fork()t het, waarna je twee sshds hebt. De ene gaat in de achtergrond en luistert naar netwerkconnecties, en de andere doet wat controle en sluit dan af (en zegt evt nog op de terminal "yo, daemon draait!" ofzo).

Waarschijnlijk is elk proces m.u.v. init op jouw bak ontstaan van uit een fork() (okok, je hebt ook nog vfork(), en zowel fork() als vfork() zijn een wrapper om clone(), maar whatever), dus de kans dat fork() kapot is is erg klein

fork() kan wel falen, de gangbare oorzaken daarvoor zijn:
* geen vrij geheugen
* het maximale aantal PIDs (voor de huidige user of het huidige systeem) is bereikt
Dit is waarom een "ps auxf" output op het moment van brakkigheid zo nuttig zou zijn.

Maar als je het systeem geboot hebt, hoe controleer je dan of sshd gestart is of niet? Als je /etc/init.d/ssh start doet, wat verschijnt er dan zoal in /var/log/daemon.log (en evt /var/log/syslog)?

[Verwijderd]

Dawns_sister schreef op 11 november 2002 @ 21:13:
Een proces dat eenmaal draait hoeft niet meer te forken en zal dus blijven draaien zolang het geen extra geheugen nodig heeft. Cron moet telkens een nieuw proces opstarten wat dus niet zal lukken.

Ja en nee, Ja, top hoeft idd niet te forken, maar op het moment dat er niet meer geforked kan worden is het toch al te laat. Met de cron methode heb je dan iig een processlisting van net voor de laatste hd sync. (nog afgezien van het feit dat ps heel wat minder resource intensive is)

Maar wat betreft het scrollen van het scherm met de foutmeldingen zou je wel eens gelijk in kunnen hebben. Dat kan je alleen oplossen door foutmeldingen niet meer naar console te laten loggen (en dat is mij nog nooit gelukt).

Hangt ervan af hoe de messages gelogged worden. Komt het van syslog? Zie je syslog.conf. Komt het uit de kernel (waarschijnlijk) dan doe je "dmesg -n 1" om alle messages te blocken; "dmesg -n 8" om het weer aan te zetten (al heb je dit met de cron methode niet nodig)

[straat]

active2 schreef op 11 november 2002 @ 21:39:
Jij dat probleem ook al

Waarschijnlijk is je stack limit te laag.

Voor dat je ssh start moet je dit eens doen:

code:

ulimit -s unlimited

Dit werkt helaas niet

deadinspace schreef op 11 November 2002 @ 22:08:

[...]

fork() is een systemcall die het huidige process dupliceert. Als sshd start, dan fork()t het, waarna je twee sshds hebt. De ene gaat in de achtergrond en luistert naar netwerkconnecties, en de andere doet wat controle en sluit dan af (en zegt evt nog op de terminal "yo, daemon draait!" ofzo).

Waarschijnlijk is elk proces m.u.v. init op jouw bak ontstaan van uit een fork() (okok, je hebt ook nog vfork(), en zowel fork() als vfork() zijn een wrapper om clone(), maar whatever), dus de kans dat fork() kapot is is erg klein

fork() kan wel falen, de gangbare oorzaken daarvoor zijn:
* geen vrij geheugen
* het maximale aantal PIDs (voor de huidige user of het huidige systeem) is bereikt
Dit is waarom een "ps auxf" output op het moment van brakkigheid zo nuttig zou zijn.

ah, dat verduidelijkt het wel allemaal een beetje

Maar als je het systeem geboot hebt, hoe controleer je dan of sshd gestart is of niet? Als je /etc/init.d/ssh start doet, wat verschijnt er dan zoal in /var/log/daemon.log (en evt /var/log/syslog)?

in /var/log/syslog komt nix te staan, en in /var/log/daemon ook niet (in daemon.log staan alleen wat meldingen van snmp, imapd, telnetd en proftpd).

Nadat ik het systeem heb geboot, zie ik met "ps auxf" dat sshd niet draait.

[Verwijderd]

-1 overbodig

[deadinspace]

En als sshd niet draait, en je doet (als root), gewoon "sshd", dan returnt dat commando niet? Dat maak ik uit een van je eerdere posts op.

[straat]

deadinspace schreef op 11 november 2002 @ 22:58:
En als sshd niet draait, en je doet (als root), gewoon "sshd", dan returnt dat commando niet? Dat maak ik uit een van je eerdere posts op.

dat klopt ja. het werkt wél als ik em niet in deamon mode start met -D optie of in debug mode met -ddd optie

[Verwijderd]

Je hebt toch nog wel het /dev/random & /dev/urandom device?
Ik zag dat je een niet kernel gebakken had; misschien heb per ongeluk het PRNG-device (of entropy) uitgezet. Zonder deze zal (ligt aan de distrib) ssh niet werken ivm SSL.
Controleer even of je 'cat /dev/urandom' kunt doen en of je daarmee war 'random' waarden krijgt. SSH kan ook werken zonder PRNG, echter zil je de libs zelf moeten compileren.

[straat]

Verwijderd schreef op 11 november 2002 @ 23:03:
Je hebt toch nog wel het /dev/random & /dev/urandom device?
Ik zag dat je een niet kernel gebakken had; misschien heb per ongeluk het PRNG-device (of entropy) uitgezet. Zonder deze zal (ligt aan de distrib) ssh niet werken ivm SSL.
Controleer even of je 'cat /dev/urandom' kunt doen en of je daarmee war 'random' waarden krijgt. SSH kan ook werken zonder PRNG, echter zil je de libs zelf moeten compileren.

op mijn console verschijnen allemaal vage tekentjes enzo, mijn putty window resized ook steeds. op tty1 console krijg ik ook allemaal vage tekentjes en veel gepiep uit mijn pc-speaker

En ik heb het al eerder gezegd, sshd werkt dus wel, maar niet in deamon mode

[deadinspace]

Doe voor de gein eens "strace sshd" dan. Dat zal waarschijnlijk erg veel output geven, met "strace sshd 2> sshd-strace.log" redirect je die output naar een file, die file kun je dan ergens online zetten of je kunt stukken ervan (vooral de laatste 50 or so regels zijn waarschijnlijk interessant) hier pasten.

[straat]

deadinspace schreef op 12 november 2002 @ 00:08:
Doe voor de gein eens "strace sshd" dan. Dat zal waarschijnlijk erg veel output geven, met "strace sshd 2> sshd-strace.log" redirect je die output naar een file, die file kun je dan ergens online zetten of je kunt stukken ervan (vooral de laatste 50 or so regels zijn waarschijnlijk interessant) hier pasten.

hehe ik snap er vrij weinig van, maar ik zal wel even wat pasten dan

code:

[root@pinchi] /var/log > strace sshd
execve("/usr/sbin/sshd", ["sshd"], [/* 19 vars */]) = 0
uname({sys="Linux", node="pinchi", ...}) = 0
brk(0)                                  = 0x8092660
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=14478, ...}) = 0
old_mmap(NULL, 14478, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000
close(3)                                = 0

[...]

open("/etc/ssh/ssh_host_rsa_key", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0600, st_size=887, ...}) = 0
getuid32()                              = 0
_llseek(3, 0, [887], SEEK_END)          = 0
_llseek(3, 0, [0], SEEK_SET)            = 0
brk(0x8096000)                          = 0x8096000
read(3, "-----BEGIN RSA PRIVATE KEY-----\n"..., 887) = 887
_llseek(3, 0, [0], SEEK_SET)            = 0
fcntl64(3, F_GETFL)                     = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fstat64(3, {st_mode=S_IFREG|0600, st_size=887, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000
_llseek(3, 0, [0], SEEK_CUR)            = 0
read(3, "-----BEGIN RSA PRIVATE KEY-----\n"..., 4096) = 887
close(3)                                = 0
munmap(0x40014000, 4096)                = 0
open("/etc/ssh/ssh_host_dsa_key", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0600, st_size=672, ...}) = 0
getuid32()                              = 0
_llseek(3, 0, [672], SEEK_END)          = 0
_llseek(3, 0, [0], SEEK_SET)            = 0
read(3, "-----BEGIN DSA PRIVATE KEY-----\n"..., 672) = 672
_llseek(3, 0, [0], SEEK_SET)            = 0
fcntl64(3, F_GETFL)                     = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fstat64(3, {st_mode=S_IFREG|0600, st_size=672, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000
_llseek(3, 0, [0], SEEK_CUR)            = 0
read(3, "-----BEGIN DSA PRIVATE KEY-----\n"..., 4096) = 672
close(3)                                = 0
munmap(0x40014000, 4096)                = 0
socket(PF_UNIX, SOCK_STREAM, 0)         = 3
connect(3, {sin_family=AF_UNIX, path="/var/run/.nscd_socket"}, 110) = -1 ENOENT (No such file or directory)
close(3)                                = 0
open("/etc/nsswitch.conf", O_RDONLY)    = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=465, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000
read(3, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 465
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x40014000, 4096)                = 0
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=14478, ...}) = 0
old_mmap(NULL, 14478, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000
close(3)                                = 0
open("/lib/libnss_compat.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\25"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0644, st_size=40152, ...}) = 0
old_mmap(NULL, 43256, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4025d000
mprotect(0x40267000, 2296, PROT_NONE)   = 0
old_mmap(0x40267000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x9000) = 0x40267000
close(3)                                = 0
munmap(0x40014000, 14478)               = 0
uname({sys="Linux", node="pinchi", ...}) = 0
open("/etc/passwd", O_RDONLY)           = 3
fcntl64(3, F_GETFD)                     = 0
fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=1026, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000
_llseek(3, 0, [0], SEEK_CUR)            = 0
read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1026
close(3)                                = 0
munmap(0x40014000, 4096)                = 0
stat64("/var/run/sshd", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
setgroups32(0, 0)                       = 0
fork()                                  = 2563
--- SIGCHLD (Child exited) ---
_exit(0)                                = ?

[deadinspace]

En dat returnt wel? Dus na "strace sshd" krijg je je prompt wel terug, maar na "sshd" niet? Weird.
Verschijnt er nu (nu sshd binnen die strace draait en wel normaal je prompt teruggeeft) wel wat in je logs?

Wat ook vreemd is is het volgende:

code:

fork()                                  = 2563
--- SIGCHLD (Child exited) ---

sshd forkt. Niks raars. Maar de child exit vrij snel al weer, en dat hoort niet. De child moet naar de achtergrond gaan en connecties luisteren enzo. Doe eens "strace -f sshd", dan strace-t hij de child ook (met als gevolg nòg meer output). Zien we misschien waarom de child zo snel weer exit.

[straat]

deadinspace schreef op 12 november 2002 @ 02:09:
En dat returnt wel? Dus na "strace sshd" krijg je je prompt wel terug, maar na "sshd" niet? Weird.
Verschijnt er nu (nu sshd binnen die strace draait en wel normaal je prompt teruggeeft) wel wat in je logs?

Wat ook vreemd is is het volgende:

code:

fork()                                  = 2563
--- SIGCHLD (Child exited) ---

sshd forkt. Niks raars. Maar de child exit vrij snel al weer, en dat hoort niet. De child moet naar de achtergrond gaan en connecties luisteren enzo. Doe eens "strace -f sshd", dan strace-t hij de child ook (met als gevolg nòg meer output). Zien we misschien waarom de child zo snel weer exit.

euhm, wat bedoel je precies met de prompt terug krijgen? Als ik "sshd" intyp verschijnt er niets op het scherm maar komt er op de volgende regel gewoon weer een prompt en is er dus eigenlijk nix gebeurd. Als ik "strace sshd" intyp dan krijg ik dus die hele zooi output en daarna weer mijn prompt

anyway, ik heb de output van "strace -f sshd" even online gezet op mijn servertje (nu maar hopen dat ie het blijft doen ).

[straat]

ik zat net te denken, is het wel goed dat ie deze file niet kan vinden?

code:

open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)

Ik ben nog nix verder gekomen met het probleem de laatste dagen

[Verwijderd]

Zet dan ook even je /etc/sshd_config online; kunnen we die ook even bekijken. De 'strace' ziet er niet fout uit; volgens mij zit het hem in de config en geven de laatste 2 regels aan:

fork() = 2563
--- SIGCHLD (Child exited) ---

dat er een foutje in de config zit. Naar mij idee probeert hij een LISTNER te starten maar kan dat niet omdat de gegevens niet kloppen (bv. IP om naar te luisteren)

[straat]

ik gebruikt de standaard debian config file, heb er zelf nix aan veranderd.

code:

# Package generated configuration file
# See the sshd(8) manpage for defails

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# ...but breaks Pam auth via kbdint, so we have to turn it off
# Use PAM authentication via keyboard-interactive so PAM modules can
# properly interface with the user (off due to PrivSep)
PAMAuthenticationViaKbdInt no
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 600
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# rhosts authentication should not be used
RhostsAuthentication no
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Uncomment to disable s/key passwords
#ChallengeResponseAuthentication no

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes


# To change Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no

# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes

X11Forwarding no
X11DisplayOffset 10
PrintMotd no
#PrintLastLog no
KeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net
#ReverseMappingCheck yes

Subsystem       sftp    /usr/lib/sftp-server

[eth0]

Probeer eens je oude standaard debian kernel 2.4.18-bf ofzo, ipv je huidige 2.4.19. Kijken of dan het probleem zich dan ook nog voor doet als je ssh start, het kan zijn dat er een verkeerde optie in je huidige kernel zit of een juiste niet zit mee gecompileerd.

[straat]

eth0 schreef op 15 November 2002 @ 21:05:
Probeer eens je oude standaard debian kernel 2.4.18-bf ofzo, ipv je huidige 2.4.19. Kijken of dan het probleem zich dan ook nog voor doet als je ssh start, het kan zijn dat er een verkeerde optie in je huidige kernel zit of een juiste niet zit mee gecompileerd.

dat had helaas geen effect

[Verwijderd]

Of je hebt een erg nieuwe versie (=> 3.2) van ssh of de optie 'UsePrivilegeSeparation yes' staat er per ongeluk in. Type 'sshd --V' (bestaat wel niet maar werkt toch) om daat achter te komen.

PS: Indien je Webmin gebruikt; dit is gefixt.

[deadinspace]

Straat schreef op 12 November 2002 @ 12:59:
euhm, wat bedoel je precies met de prompt terug krijgen? Als ik "sshd" intyp verschijnt er niets op het scherm maar komt er op de volgende regel gewoon weer een prompt en is er dus eigenlijk nix gebeurd. Als ik "strace sshd" intyp dan krijg ik dus die hele zooi output en daarna weer mijn prompt

Dat er niks verschijnt en je je prompt terugkrijgt is normaal. De geforkte child die als ssh daemon gaat werken doet dat in de achtergrond en houdt je terminal dus niet bezet.

Als je "sshd" doet, weet je dan zeker dat sshd niet gewoon gestart is? Wat geeft "ssh localhost" dan?

anyway, ik heb de output van "strace -f sshd" even online gezet op mijn servertje (nu maar hopen dat ie het blijft doen ).

code:

connect(3, {sin_family=AF_UNIX, path="/dev/log"}, 16) = 0
send(3, "<34>Nov 12 12:56:12 sshd[4755]: "..., 63, 0) = 63

Hmm, weet je zeker dat er niks in een van je logs verschijnt? Potentieel boeiend zijn messages, daemon.log, syslog en auth.log, en misschien nog wel meer (anders even greppen).
[nohtml][quote]Straat schreef op 14 november 2002 @ 16:17:
ik zat net te denken, is het wel goed dat ie deze file niet kan vinden?

code:

open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)

Nee, die levert geen problemen op. Die file is voor als je bepaalde libraries wilt preloaden, bijvoorbeeld omdat je een andere libc6 wilt gebruiken voor sshd dan voor andere programma's (een soort van per-programma override van libraries). Heb je onder normale omstandigheden niet nodig.

Straat schreef op 15 november 2002 @ 16:57:
ik gebruikt de standaard debian config file, heb er zelf nix aan veranderd.

Hmm, ziet er idd vrij standaard uit.
Je zou kunnen proberen

code:

UsePrivilegeSeparation yes

Uit te zetten, al verwacht ik niet dat die de problemen veroorzaakt (als het niet helpt kun je hem beter weer aanzetten).

code:

PermitRootLogin yes

Heeft niks met je probleem te maken, maar je kunt overwegen deze uit te zetten (uit security overwegingen).

[straat]

deadinspace schreef op 16 november 2002 @ 21:24:
[...]

Dat er niks verschijnt en je je prompt terugkrijgt is normaal. De geforkte child die als ssh daemon gaat werken doet dat in de achtergrond en houdt je terminal dus niet bezet.

Als je "sshd" doet, weet je dan zeker dat sshd niet gewoon gestart is? Wat geeft "ssh localhost" dan?

code:

[root@pinchi] /home/straat > sshd
[root@pinchi] /home/straat > ssh localhost
ssh: connect to address 127.0.0.1 port 22: Connection refused

code:

connect(3, {sin_family=AF_UNIX, path="/dev/log"}, 16) = 0
send(3, "<34>Nov 12 12:56:12 sshd[4755]: "..., 63, 0) = 63

Hmm, weet je zeker dat er niks in een van je logs verschijnt? Potentieel boeiend zijn messages, daemon.log, syslog en auth.log, en misschien nog wel meer (anders even greppen).

code:

Nov 10 17:31:47 pinchi sshd[6603]: error: fork: Resource temporarily unavailable
Nov 18 13:03:04 pinchi sshd[25573]: fatal: daemon() failed: Success

Dit zijn enkele interessante regeltjes uit mijn auth.log. Die eerste error is van vorige week toen de computer zo vaag deed, die tweede error komt er steeds in als ik sshd probeer te starten.

Je zou kunnen proberen

code:

UsePrivilegeSeparation yes

Uit te zetten, al verwacht ik niet dat die de problemen veroorzaakt (als het niet helpt kun je hem beter weer aanzetten).

code:

PermitRootLogin yes

Heeft niks met je probleem te maken, maar je kunt overwegen deze uit te zetten (uit security overwegingen).

Dit werkt helaas ook niet.

[Verwijderd]

Wat staat er in je /etc/hosts ?

[deadinspace]

Hmm, longshot: geef eens de output van "ls -l /dev/null" ?

[straat]

/etc/hosts

code:

127.0.0.1       localhost
10.0.1.1        pinchi.straat.nu        pinchi
10.0.0.138      ADSL-modem
10.0.1.10       night

# The following lines are desirable for IPv6 capable hosts
# (added automatically by netbase upgrade)

::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

ls -l /dev/null

code:

[root@pinchi] /home/straat > ls -l /dev/null
-rw-r--r--    1 root     root       219223 Nov 19 09:55 /dev/null

[deadinspace]

Juich! Khad nog gelijk ook

code:

rm /dev/null; mknod /dev/null c 1 3

En dan ssh starten.

[No13]

Hier had ik dus laatst ook last van

ik had ook de oplossing die staat beschreven geprobeert en inderdaad hij werkte....tot ik ging rebooten

ik heb het toen opgegeven (schaam schaam) en een nieuwe install erover gegooit

[straat]

woei hij doet het weer

t heeft even geduurd maar hij lijkt het nu weer normaal te doen

[deadinspace]

No13 schreef op 20 November 2002 @ 12:30:
ik heb het toen opgegeven (schaam schaam) en een nieuwe install erover gegooit

Herinstall was waarschijnlijk ook makkelijker geweest, maar dan hadden we nooit geweten wat er fout was

Straat schreef op 18 November 2002 @ 13:18:

code:

Nov 18 13:03:04 pinchi sshd[25573]: fatal: daemon() failed: Success

Dat vond ik dus erg vreemd. daemon() failed, schijnbaar met de foutmelding: "success" (op de plaats van "success" staat doorgaans een nuttigere foutmelding).
Een blik in daemon()'s manpage gaf verheldering:

code:

NOTES
       The glibc implementation can also return -1 when /dev/null  exists  but
       is  not  a  character device with the expected major and minor numbers.
       In this case errno need not be set.

Bah, brakke manier om een error te returnen Misbruik dan een bestaande errorcode ofzo...
Maar dat zou wel de vreemde foutmelding verklaren. En inderdaad:

Straat schreef op 19 November 2002 @ 10:01:

code:

[root@pinchi] /home/straat > ls -l /dev/null
-rw-r--r--    1 root     root       219223 Nov 19 09:55 /dev/null

Geen character device, maar een gewone file.
En de reden daarvoor is ook duidelijk:

Straat schreef op 10 november 2002 @ 19:24:
Na een druk op de resetknop leek alles weer te werken

Door die reset heeft het filesystem een klap gekregen, wat blijkbaar als gevolg had dat /dev/null pleite was. En als een programma vervolgens naar /dev/null wil kalken wordt daar een file aangemaakt die niet /dev/null is. Veel programma's nemen daar genoegen mee, maar de daemon() systemcall blijkbaar niet.

Dan blijft dus alleen de vraag wat de oorzaak was van hetgene dat dit alles startte:

Dus even een monitor en keyboard aangesloten en ingelogd. Nu kreeg ik echter bij alles wat ik probeerde te starten een melding met een inhoud van "cannot fork". Zelfs rebooten wilde niet meer (INIT: cannot fork..). Ik kijk snel even naar mijn phpsysinfo page, daar zie ik dat het geheugen helemaal vol zit en de swap (300MB) ook. De load-averages waren ook niet laag om het even zacht uit te drukken (324.00 324.00 323.94).

Oja, check je /lost+found. Misschien zit je vorige /dev/null daarin. Mogelijk ook fragmenten van andere files.