Login without running bash_profile or bashrc

Question

So let's say one typoed something in their .bashrc that prevents him (or her) from logging in via ssh (i.e. the ssh login exits because of the error in the file). Is there any way that person could login without executing it (or .bashrc since the one runs the other), or otherwise delete/rename/invalidate the file?

Suppose you don't have physical access to the machine, and this is the only user account with the ability to ssh in.

For Reference: .bash_profile includes .bashrc:

[[ -f ~/.bashrc ]] && . ~/.bashrc

Edit: Things I have tried:

ssh user@host "rm ~/.bashrc"

scp nothing user@host:/RAID/home/tom/.bashrc

ssh user@host  "/bin/bash --norc"

All give the error:

/RAID/home/tom/.bashrc: line 16: /usr/local/bin/file: No such file or directory
/RAID/home/tom/.bashrc: line 16: exec: /usr/local/bin/file: cannot execute: No such file or directory

Answer 1

ssh -t username@hostname /bin/sh works for me.

Answer 2

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.

Answer 3

You need to a) start bash without source'ing either ~/.bashrc or ~/.bash_profile and b) since such a shell wouldn't be a full login shell / have no tty attached, force ssh to attach a tty:

ssh -t user@host bash --norc --noprofile

Answer 4

I think your only options are:

• ssh in as another user and su to your account;

• use something like ftp or smbclient, if the relevant services are enabled on the host;

• find an open vulnerability in an open network service and exploit it :).

• get an admin to fix the problem.

Answer 5

I used a published CVE to execute a command as root through a web interface in a network monitoring software I had installed. rm /RAID/home/tom/.bashrc

Then I could login and svn revert the changes I made.

Answer 6

You're out of luck.

All ssh commands run your login shell. ssh $COMMAND runs $SHELL -c $COMMAND, scp runs $SHELL -c /path/to/sftp-server, plain ssh just runs your shell.

Answer 7

None of the above answers can bypass the login shell of ssh. You can pass a full command line, and so it runs the remote shell to process the command and set the working environment for the command. That's what shells are for and it's the Unix way. You would have all sorts of compatibility problems if you tried to run something without a shell. Likewise, trying a control-C should do the same as calling exit which is the behavior you are trying to avoid. If bash continues its a bug. Why people keep saying that the man page says something different need to quote it because it says nothing of the sort in my man page.

Additionally, on most linux systems, specifying /bin/sh does NOTHING since this is just a symlink to bash!

Wanna test? Add "echo" statements to you .bashrc and .profile and see which is run. I did. Here's the results.

ssh user@host will execute .bash_profile ssh user@host /bin/bash will execute .bashrc, but it thinks its non-interactive (no prompt). ssh -t user@host /bin/bash executes .bashrc twice ... once at login, once for the passed command, so specifying ANY shell will always run the first. ssh -T user@host is the same as not specifying -T or -t at all.

Now, if you notice, MY system isn't running both files, only one or the other. But the original poster has a line in .bash_profile running .bashrc, so .bashrc will always get run no matter what. Shouldn't have put that line there! If that line didn't exist, you wouldn't have had a problem.

You'll need to find another way in or find an admin. This is what admins are for.

Answer 8

Something like:

ssh host "/bin/bash --norc"

which seems to work, but note that PS1 is not set so you'll be typing commands without a prompt.

This has the advantage of being non-destructive.

Answer 9

ssh -t user@host "bash --norc --noprofile -c '/bin/rm .bashrc'"

Answer 10

try

echo ^C | ssh <hostname> ' rm .bashrc'

^C there is control-v then c

Answer 11

Mashing ctrl-C works as long as you can get a ctrl-C in before the .bashrc exits. Unfortunately, this can be difficult to do if exit is early in the .bashrc.

You can put in a ctrl-C as soon as possible by piping it to ssh directly:

{ echo ^C; cat /dev/tty; } | ssh -tt user@host

Note that ^C is typed like ctrl-V followed by ctrl-C.

This pipes a single ctrl-C followed by input from the controlling terminal, while -tt forces a psuedo-terminal to be allocated. All told this gives you a (somewhat malformed) shell on the remote machine while bypassing as much of .bashrc as is possible.

Answer 12

That's works for me

$ ssh <hostname> bash --rcfile /dev/null

Answer 13

Simply move the old .bashrc out of the way:

ssh user@wherever mv /home/ubuntu/.bashrc /home/ubuntu/.bashrc_old

Now ssh in normally :)

(since you don't run .bashrc when running commands; this worked great for me :) )

Answer 14

I think you can modified /etc/passwd file.

for example for

user:x:1015:1015::/home/user

So you hasnt access to bash

Answer 15

UH='user@host'; ssh $UH 'mv ~/.bashrc ~/letmein'; ssh $UH

Please don't cut and run, change user and host, then edit letmein and save as .bashrc

Answer 16

Kudos to user60069, it worked for me, but I use the shell-specific startup file .bashrc, so logging in with /bin/sh worked for me.

However, if you are in the "no such luck" situation, I offer this solution, based on user60069's and Dennis W's solutions:

ssh -t you@host  /bin/bash --noprofile  --norc

Dennis W offered the --norc option, which someone said did not work for them.

Run "man bash" or "man (your shell)" for options to disable the start up files. You only need to use an abhorrent shell for the time it takes to fix the problem.

Answer 17

Other way to login to server is without profile, please find below command
ssh -t user@host bash --noprofile

For AWS using pem file and no other user
ssh -ti "YOUR-PEM-FILE-NAME.pem" ec2-user@YOUR-IP-ADDRESS bash --noprofile

Hope this helps!

Answer 18

You can try to overwrite the .bash_profile with an empty file using the scp command. From what I have googled, scp use a non-interactive login that does not read .bash_profile.

Answer 19

You can also just delete the bashrc file:

ssh <hostname> rm ~/.bashrc

Answer 20

If you system is setup normally, .bash_profile won't be run for a non-interactive shell (such as running a command).

Since you state the problem is in the .bash_profile file, try moving it out of the way:

ssh user@host "mv ~/.bash_profile ~/.bash_profile_broken"

Answer 21

From the suggestions and responses given above, I'd say it's not the .bashrc or .bash_profile files. Also ssh manpage says that if you specify a command to be executed then your profile files won't be read.

I'd suggest try executing a different login shell (ksh? csh? sh?) from the absolute path; also, beware that it might be a totally different problem (quota? execute and read permission on your home directory?), so a side approach would be better. Can you ask another user to do a ls -la $YOUR_HOME_DIR and mail you the result?