35

I put "exit" in my .bashrc file. I don't have physical access to the machine so to connect to it I use ssh. I don't have root privileges. Every time I connect to the server, the connection automatically closes.

So far, I've tried:

  • Overwriting .bashrc with scp and sftp. The connection closes before I can do anything.
  • Using a few different GUI programs to access ssh (connection closes)
  • Overwriting the file with ftp. (can't use ftp)
  • From my home computer
    • $ ssh host "bash --noprofile --norc" (connection closes)
    • $ ssh host "mv .bashrc bashrc_temp" (connection closes)
    • $ ssh host "rm .bashrc" (same thing)
    • $ ssh host -t (connection closes)

Is there anything I can do to disable .bashrc or maybe overwrite the file before .bashrc is sourced?

UPDATE

@ring0

I tried your suggestion, but no luck. The bashrc file still runs first.

Another thing I tried was logging in with another account and sudo editing the .bashrc, but I don't have sudo privileges on this account.

I guess I'll contact the admin.

EDIT

@shellholic

I can't believe it, but this approach worked! Even though "exit" occurs within the first few lines (composed only of a few if blocks and export statements) in the .bashrc file, I still managed to Ctrl-c interrupt it successfully within twenty tries (took about 3 minutes). I removed the offending line in the .bashrc and everything is in working order again.

Improve this question
4
  • 2
    darwinawards.com you should have (temporary) an access as a user who can overwrite your .bashrc file, or change your default shell to something else. "Ask your system Administrator" as MS says. Commented Nov 27, 2010 at 9:05
  • 2
    man 8 sshd says that it 9. Runs user's shell or command. as the ninth step... :-/ Commented Nov 27, 2010 at 9:17
  • 2
    scp will also stop working because the shell still gets opened and .bashrc gets called Commented Nov 28, 2010 at 2:51
  • 1
    FYI the reason most of these suggestions do not work is because ssh executes any command by by passing it as an argument to the user's shell. Search for execve in session.c. There is no way to modify/add/delete the arguments of this invocation of the user's shell. Commented May 11, 2018 at 17:18

12 Answers 12

Reset to default
46

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
Improve this answer
9
  • 9
    +1, because it's probably the only solution that doesn't require help from the system administrator. However, a lot of luck is required to have correct timing (ssh -v host might help a bit). Commented Nov 27, 2010 at 20:38
  • Actually the ctrl+C did work. Even without the sleep. I placed "exit" into my bashrc and was able to recover with a quick ctrl+C after about 4 tries. Please make some edit the answer so I can change the "-1" to "+1". Commented Nov 28, 2010 at 2:49
  • @Aleksandr Levchuk done Commented Nov 28, 2010 at 2:54
  • 5
    I very much appreciate the combination of pathetically ridiculous low-tech and brutal effectiveness here. Commented Jun 11, 2013 at 16:06
  • 1
    I'm laughing like crazy, that rush when it finally works. Thanks @JooMing, I tried all methods from here serverfault.com/questions/94503/… even the one with pressing Ctrl+C, but it only worked after adding the -v option! Commented Oct 12, 2017 at 20:02
15

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

Improve this answer
2
  • 2
    ssh -tv user@home mv .bashrc .bashrc-old worked for me Commented Jul 15, 2015 at 16:10
  • If you remember a pattern on the faulty .bashrc you can just ssh user@host sed -i '/problematicPattern/d' .bashrc, less drastic than directly rm Commented May 28, 2020 at 6:45
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.

Improve this answer
1
  • Filezilla worked perfectly for this. Just have to drop-down "Server" menu and select "Force show hidden files" setting. Commented Aug 31, 2015 at 1:57
3

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

su user -s /bin/sh

You'll need your password, of course.

Improve this answer
1
  • 1
    you could try different, not sh based shell: ksh or csh Commented Nov 27, 2010 at 17:41
2

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

Improve this answer
2

A couple of suggestions that worked for me from this Reddit thread:

ssh [email protected] /bin/bash --noprofile --norc ssh -t [email protected] vi ./.bashrc
Improve this answer
0

Connect via SCP or SFTP and edit/rename/delete your .bashrc file that way. Edit - D'oh, I see you said you tried that. Oh well.

Improve this answer
0

I've had the same problem, and somehow was able to solve it. I used ssh to access the system, and pressed and held Ctrl+c as soon as I logged into the system. Then, ~/.bashrc was not read, and I was able to modify it.

Improve this answer
1
  • 1
    Exact duplicate of the most upvoted answer here Commented Feb 18, 2011 at 22:57
0

If you're using Homestead Vagrant...

Here is how I got myself out of this pickle.

(Using Git Bash on Windows 10)

cd ../Homestead/ mv ~/.ssh/known_hosts ~/.ssh/known_hosts_OLD ssh [email protected] -p 2222 mv ./.bashrc ./.bashrc_OLD

Note: the default password is "vagrant"

These articles helped me:

Improve this answer
0
  1. Interrupt grub bootloader by pressing e ... again press e to enter grub loading lines, again press e to edit the kernel line,
  2. go to end of line;
  3. add init=/bin/bash at the end of line, 1 .enter to return, b to boot,
  4. it will open a bash shell,
  5. open vim /root/.bashrc and edit accordingly.

exit and now you will be able to login

Improve this answer
0

I wrote a Python script to automate the ctrl+c thing because I really cannot success using bare hands...

import pyautogui import time def countdown(seconds): print("Counting down before moving your mouse to the terminal:", end=" ") for i in range(seconds, 0, -1): print(i, end=" ") time.sleep(1) print("Script starts!") def clear(): pyautogui.typewrite("clear") pyautogui.press("enter") def stop(): pyautogui.hotkey("ctrl", "c") pyautogui.FAILSAFE = True countdown(5) total_retry = 1 sleep_ms = 230 host = None # could be "user@host" or "ssh_host" defined in ~/.ssh/config for i in range(total_retry): stop() pyautogui.click() clear() pyautogui.typewrite(f"ssh -v {host}") pyautogui.press("enter") time.sleep(sleep_ms / 1000) for i in range(5): stop()

All you need to do is:

  1. Change the host variable to yours
  2. Run the script and move your mouse to the terminal in 5 seconds (as written in countdown)
  3. The script will try to ssh to your host and then press ctrl+c after sleep_ms milliseconds
  4. Run this script for several times to adjust the sleep_ms variable that may stop early or late (in my case, it's 230ms). You can manually do binary search for this empirical value
  5. Once you find a proper sleep_ms, change total_retry to any number (e.g. 100) to start automating this
  6. It may take dozens of times to finally work (at least for myself, but I believe it will finally succeed in only a few minutes tops), and once it works, stop the script (don't worry about the side effect of running this script in your remote machine, because it will simply fail repeatly and won't change anything in your remote machine)

NOTE: Don't forget to enable the accessibility for your code editor (e.g., VSCode) if you are using MacOS.

Improve this answer
1
  • More details: with the proper sleep_ms, you will find sometimes ctrl+c ends after Connection closes but sometimes before it. The script is just used to get the proper time once exactly stops after Last login but before Connection closes. Commented Mar 15 at 8:27
0

If you can log in as another user, you can switch to root(or user you want) without triggering any profile or rc files by running:

su root -c "bash --noprofile --norc"
Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.