On Wed, 15 Nov 2000 15:00:29 -0800 (PST), you wrote:
As there is no keyboard / monitor on the machine I don't know if this is an ssh problem, or a more general problem. Does anyone know what might have happened to this system, and is there any way I can get back into it?
When remote administration is the only solution (no physical/local access to the machine), you have to take care of certains "critical" changes you could make in order to NOT take the machine into an isolated state :-) For instance, if you want to touch SSH, you could have (temporaly) enabled telnet access (at port 23354, e.g, if you're so paranoid ;-)). Doing so, if SSH crashes when updating, you have the chance to enter machine via telnet and undo changes. The above applies to other similar cases, like managing firewalls. It's a good idea to open a backdoor in fw, at testing/installation phase. I usually include this code at my fw init script: [Definitions] ALL_RELY="192.168.66.66" # Total access for this host (secure mode) SECURE_ADMIN="yes" # Secure mode: yes / no [Begin of fw rules] if [ $SECURE_ADMIN = yes ]; then ipchains -A input -s $ALL_RELY -j ACCEPT ipchains -A input -d $ALL_RELY -j ACCEPT ipchains -A output -s $ALL_RELY -j ACCEPT ipchains -A output -d $ALL_RELY -j ACCEPT ipchains -A forward -s $ALL_RELY -j ACCEPT ipchains -A forward -d $ALL_RELY -j ACCEPT fi In a deny-policy fw, these lines can save your machine from becoming isolated, due to a config error in your fw rules... (deny-fws are specially dangerous because you must specifically grant access to the services you want to provide; all the rest is filtered out. Take care. Anyway, it's the more secure one). Of course, when the test phase finishes, you can turn off "Secure_admin" and the backdoor is closed. Regards. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ** RoMaN SoFt / LLFB ** roman@madrid.com http://pagina.de/romansoft ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~