Rennie deGraaf wrote: > A few minutes ago, I discovered that I can't log into my firewall > > If I try SSH from inside, it gives me my login banner and immediately > disconnects, without prompting for a password. This suggested to me that > when trying to clean up the mess left by upgrading the shadow package > yesterday (and first removing pam-login) as reccomended by a > GLSA-200606-02, I left something incorrectly configured. > > If I try SSH from outside, the connection times out. I don't know why > this happens - the iptables configuration should allow SSH connections > from outside, and the timing suggests a problem before reaching the > login or pam code. > > If I try to log in via a virtual TTY on a serial port, I get the message > "*** glibc detected *** double free or corruption (!prev): 0x142e1cc8 > ***" (the address varies) after entering a username, but before entering > a password. This suggests a problem with either the login or pam > software; I can't see how a configuration error could cause this. > > If I try to log in via the system console, I get the same error as with > the serial line. > > My firewall is running a tightly locked-down minimal install of Gentoo > 2005.1 with the hardened kernel and toolkit and all relavant security > updates applied. I think that the kernel is 2.6.11-hardened-r15. Other > than my inability to log in, it seems to be working - the DNS server is > still responding, and it still seems to be forwarding packets correctly. > The system has been up since some time in late august or early > september 2005. > > I guess that the only way to get into the system and try to fix it is to > reboot into single-user mode, but before I take it down for maintenance, > I'd like to know if I'm dealing with a software problem or a > configuration problem (since with my firewall down, I will have no way > to look up more information from the Internet). Does anyone know what > this error signifies in this context, or have any suggestions on how to > recover? > > Thanks, > Rennie deGraaf > Hi, Just reboot and try again. IIRC the solution was to rebuild "openssh" after the new "shadow" package within the same ssh-session (assuming that's the way you do it). HTH.Rumen
smime.p7s
Description: S/MIME Cryptographic Signature
