Hi,
This is my first post here. Hopefully it is in the right part of this forum.

The problem.
I have a remote server FC3 protected with APF firewall and bastille.
Firewall set to block IP addresses after 20 failed access attempts and allow access from my fixed IP address.
Remote root login disallowed, su to root required.
Bastille set up to prevent console root access.

All worked well until I changed broadband provider and hence had a new fixed IP address,this combined with me getting muddled with passwords APF jumped and I am now locked out.

Went away, did some reading, sent following mail to the hosting company.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++
Please boot system from FC3 disc 1
Enter "linux rescue" as command
Choose 'english' for language
Choose UK for keyboard
Do not setup network

at prompt type chroot /mnt/sysimage

Then:

type nano /etc/shadow. (I am presuming the pw is in the shadow file)

In the /etc/shadow file please enter the password string below as the encrypted password (between the two colons to replace existing entry) for root.

root:this is the password:13181:0:99999:7:::
('this is the password' was in fact a copy of password obtained from my FC3 local test machine, changed for posting to this board)

Type ctrl-x to exit, Y to agree to changes and enter to save.

If encryption is machine dependent then

Copy the password element of the entry for admin in the shadow file into the root entry.

Finally with reference to the APF firewall:

Type nano /etc/apf/allow_hosts.rules

please place my home IP address 12.234.45.57 (changed for posting)

in the file, remove existing contents and save as above.

Please empty /etc/apf/deny_hosts.rules

Then reboot and hopefully this will get me back in.

+++++++++++++++++++++++++++++++++

The response I have had is :-

I tackled this last night/this morning. I managed to clear the root password, then get access to single-user mode to change it. That all went well, however as soon as I boot into normal mode, the password appears to be changed - I can't then get back in to single user mode again. I'm wondering if either the firewall or DA is doing some sort of password sync that's designed to stop other people from changing the password. Have you got any ideas?

++++++++++++++++++++++++++++++++++

I have no ideas of my own! From research I wonder if it could be to do with PAM and how it handles passwords, I don't know if DirectAdmin or Bastille alter the way passwords are created/tested, it could be something to do with crypt vs. hash. I don't even know if the default install of FC3 uses PAM authentication.

I have come across the following instructions at linuxgazette . net/issue50/tag/4.html which may do the trick but would like advice on whether or not they are likely to work; are there known features of Bastille and DirectAdmin likely to defeat attempts from the console?

Quoting from the above link:
For Linux all you have to do is:
1. Reboot
(try [Ctrl]+[Alt]+[Delete])
2. During the LILO prompt type:
(kernel/image name) init=/bin/sh rw
... note that's usually going to be just:
linux init=/bin/sh rw
3. This should start the Linux kernel,
with the root filesystem mounted in read/write mode. The cool thing is that none of your normal init processes (like the gettys that ask for your name and call the login program) will be started.
4. (Maybe) mount your /usr filesystem with a command like:
mount /usr
5. Change your root password with a command like:
passwd
6. Flush the cache buffers:
sync; sync; sync
7. (Maybe) unmount /usr:
umount /usr
8. Remount the root fs in readonly mode:
mount -o remount,ro /
9. Let init clean up and reboot the system:
exec /sbin/init 6
... there is a "6" (six) at the end of that command.
+++++++++++++++++++++++++++++++

Any help would be gratefully received,
Many thanks,
Tony

The only thing I have ever done is delete the password in /etc/passwd and then logout and reboot. Then the password is blank and you should be able to login as root without a password and set a new one.

Thanks but empty password is disallowed and verification fails
Tony

Can you boot into "single user" mode and just passwd root?

Is single user the same as rescue mode? I forget...

Anyway, from rescue mode can you do something like

#chroot /mnt/sysimage
#passwd

It looks like that does not work, something is causing the password to change back or change to something else, the hosting guys did not tell me which.
I will see how to enable a blank password and see if that helps but it wont if the system is somehow retaining a memory for the old password.
Tony

I will suggest they try the passwd root approach but I fear the system is locked down pretty well to defeat just such attempts; I locked the system up in response to a very destructive hack last year. Paranoia rules!!
Tony

If you locked it down really well, not sure I'm much help... But this seems to be the general process on a normal system...

# mount /dev/hda3 /mnt/temp0
# chroot /mnt/temp0 /bin/bash
# passwd

where /dev/hda3 would be your root partition.

Thanks,
I will get them to try that and report back so people know.
If anyone has ideas as to why the current approach has not worked I would like to hear.
Many thanks,
Tony

In fact it looks like they have tried the 'passwd' approach
"I managed to clear the root password, then get access to single-user mode to change it. "
But the password changed when they went back to normal mode.
Very frustrating... I sense a reload coming on, thats hours of restoration
Tony

One other thing to check is to see if there is a script that is rewriting the /etc/passwd file on boot (or if you know what security program might be doing it). Not sure how long it would take to grep the entire system for /etc/passwd, but you might be able to find if there's some script locking you out...

Good idea, not sure if the guy at the company would have the time / inclination but they really are truly helpful so they might do it. Worth a try, many thanks,
Tony

I would ask them exactly how they did this. Did they boot with Knoppix or some other LiveCD? If so, and they changed the root password without using chroot as has already been mentioned in previous replies, then the password would not have stuck past a reboot. They would have been changing the Knoppix root password (only stored in memory) and NOT the password stored on disk by the regular OS.

From Knoppix (or other LiveCD) the procedure is to mount your root partition rw, then use chroot to change the password.

e.g., assuming for illustration that /dev/hda3 is your root partition,
If they didn't chroot, then changing the password was for naught. Another possibility is that if they booted into this single-user or rescue mode to change the password, was your root partitoin mounted read-write? It's possible that it was mounted read-only depending on what "rescue mode" means on your system. You'd think changing a password on a read-only root filesystem would generate an error message, but maybe it didn't, or they inadvertantly ignored/didn't_notice the error message.

I don't know if the above is the answer to your problem, or part of the answer, but it's worth investigating if you haven't already.

Thanks for a really helpful reply.
the techie has responded this evening as follows (I sense a degree of irritation... I'm not surprised poor guy.

+++++++++++++
Tony,

Here is exactly what has been done this time:

Reboot to rescue mode.
Change shadow entry to the hash in your e-mail below.
Change APF (I missed this before)
Reboot

I still cannot log in to the console as root....or admin for that matter. We've never had this much trouble resetting a password!
++++++++++++

I will test the result and if still no joy I will summon some courage and pass him a copy of your post. Its 23:27 and I expect he wants to go home.

Tony

Following the manual copying of the 'admin' encrypted password to the root location in the shadow file and the resetting of entries in the firewall files I now have full access again. We rebooted immediately after making the changes to the shadow file.
So success ... I need a drink
thanks for everyone's suggestions
Tony

case closed ... or so it appears ... but you never know for sure !