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
ssh -t username@hostname /bin/sh
works for me.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.
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: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.
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.
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
, plainssh
just runs your shell.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_profilessh 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.
Something like:
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.
try
^C there is control-v then c