I screwed up, exit in .bashrc

Solution 1:

you can try to abort (ctrl+C) before the exit part of your .bashrc is executed.

I tried by adding the following at the top of a testuser's bashrc, it works, it's just a matter of timing. Very easy in my case:

sleep 3
echo "Too late... bye"
exit 0

Solution 2:

I managed to mess up my .bashrc file too on a new cluster I've been given trial access to. Not wanting to seem like a noob, the last thing I wanted to do was ask for help from the admins, and I couldn't get a well-timed ^+C to work.
What did work however, was to send an 'rm' command as a final argument to ssh. i.e.

ssh -tv user@host rm .bashrc

I couldn't get a 'mv' command to work (tried before without -t), so I think the -t option must have done it, but you can test that if you want. I've now recovered from the .bashrc~ file (made by vim) everything but the dodgy line in question and everything is right in the world! =D

---

Solution 3:

If you can log in as a different user, try this:

su user -s /bin/sh

You'll need your password, of course.

---

Solution 4:

If I recall some bad experiences I have had like this, the ssh, scp, sftp do seem to run the initialization files.

My suggestion is to use simple FTP and then delete or rename file bad file on the FTP command line after logging in. I'm assumming that your system will allow you FTP access. In such a case, be sure to change your password (securely) when you have finished repair.

---

Solution 5:

From man ssh (for OpenSSH_5.6p1 at least, not sure when it was added),

~/.ssh/rc
        Commands in this file are executed by ssh when the user logs in, just
        before the user's shell (or command) is started.  See the sshd(8) manual
        page for more information.

..which means you can create ~/.ssh/rc containing the following:

mv ~/.bashrc ~/bak.bashrc

Then when you ssh in, the problematic bashrc will be moved out the way, before your login shell is started - you can then obviously fix the bak.bashrc and move it back into place