LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   Added 'exit 0' to the bottom of .bashrc, now what? (https://www.linuxquestions.org/questions/linux-newbie-8/added-exit-0-to-the-bottom-of-bashrc-now-what-4175536213/)

sgrlscz 03-10-2015 06:57 PM

Quote:

Originally Posted by jpollard (Post 5330071)
That was why I suggested using the kernel parameter "init=/bin/bash --noprofile". This should bypass the system startup and allow you to use the initrd to do things (like mount root and fix things).

But that's not the question being asked. The question asked was how to bypass the .bashrc via remote login or why it's not working on Centos.

There are plenty of ways to fix it when you have access to the console and can reboot.

grail 03-11-2015 03:26 AM

Ok ... this worked for me:
Code:

sudo echo "rm /root/.bashrc" > /etc/ssh/sshrc
Then logged in :)

TenTenths 03-11-2015 04:10 AM

Quote:

Originally Posted by grail (Post 5330276)
Ok ... this worked for me:
Code:

sudo echo "rm /root/.bashrc" > /etc/ssh/sshrc
Then logged in :)

Yeah, assuming:
  • You have another user to log in with
  • That user has sudo privilages.
From the OP:
Quote:

Originally Posted by szboardstretcher (Post 5329428)
So,.. I am unable to get back into the system (as root, no other users exist) after adding 'exit 0' to .bashrc

So.... nice try but no cigar. :) :)

jpollard 03-11-2015 05:40 AM

Quote:

Originally Posted by sgrlscz (Post 5330103)
But that's not the question being asked. The question asked was how to bypass the .bashrc via remote login or why it's not working on Centos.

There are plenty of ways to fix it when you have access to the console and can reboot.

There is no bypass. Only a reboot has the necessary access.

TenTenths 03-11-2015 06:26 AM

Quote:

Originally Posted by TenTenths (Post 5329908)
Brain isn't working well today but how about using rsync or scp to copy over an "empty" .bashrc file?

Tried this on my home RasPi and it worked fine, although obviously it's not Redhat/CentOS.

suicidaleggroll 03-11-2015 09:56 AM

Anybody tried sshfs as I suggested on the previous page? I put an echo in my .bashrc so I could see every time it gets sourced, and indeed all of the lines in the OP show it sourcing .bashrc before anything happens, but sshfs does not.

Code:

$ ssh server 'bash --norc -c "/bin/ls .bashrc"'
sourcing .bashrc
.bashrc
$ sshfs server:/home/user tempdir
$ vi tempdir/.bashrc

# removed the echo

$ ssh server 'bash --norc -c "/bin/ls .bashrc"'
.bashrc


grail 03-11-2015 09:57 AM

Quote:

Originally Posted by TenTenths (Post 5330287)
Yeah, assuming:
  • You have another user to log in with
  • That user has sudo privilages.
From the OP:

So.... nice try but no cigar. :) :)

I am not sure I understand?? The sudo command I have run is on my computer. I then ssh'ed into the other computer and the rm command was run there as root.

Is this not the desired affect?

szboardstretcher 04-02-2015 10:49 AM

Lot of good ideas guys. Unfortunately none work on Centos 6.6.

Quote:

Originally Posted by suicidaleggroll (Post 5330434)
Anybody tried sshfs as I suggested on the previous page? I put an echo in my .bashrc so I could see every time it gets sourced, and indeed all of the lines in the OP show it sourcing .bashrc before anything happens, but sshfs does not.

Code:

$ ssh server 'bash --norc -c "/bin/ls .bashrc"'
sourcing .bashrc
.bashrc
$ sshfs server:/home/user tempdir
$ vi tempdir/.bashrc

# removed the echo

$ ssh server 'bash --norc -c "/bin/ls .bashrc"'
.bashrc


when using sshfs:

Code:

sshfs 192.168.1.5:/root tmp
root@192.168.1.5's password:
remote host has disconnected

It still runs the .bashrc exit 0 command and doesnt mount. Any more information or ideas?

This is a tough nut to crack on Centos. I'm not understanding why all of the 'ignore bashrc' commands and switches do not work. I have successfully done this on Ubuntu with no issue. But I'm guessing that the additional user has a lot to do with that. Perhaps 'root' is locked down further when logging in.

szboardstretcher 04-02-2015 10:53 AM

Quote:

Originally Posted by AlucardZero (Post 5329441)
If all of those failed to let you edit .bashrc or remove it, then you have a different problem than just an exit.
Also, hi from Reddit (though that guy says he fixed it).

He fixed it from another account. In this lab setup, this is a minimal Centos 6.5 install with no additional users. Root only. Perhaps this is added security, and I would applaud that - but only with an explanation. If you provide root's password, then you should be in control of the box for better or for worse. Being able to control your login scripts seems like a logical leap from that circumstance.

szboardstretcher 04-02-2015 11:16 AM

Update: A friend of mine - a developer - hit CTRL-C at the proper moment in the ssh login, and it broke out of the .bashrc file and allowed the login.

While this works - I still would like the answer to my question. WHY are all these ssh flags and parameters being ignored for root?

grail 04-02-2015 11:28 AM

So can you confirm that adding to /etc/ssh/sshrc did not work either?

suicidaleggroll 04-02-2015 03:02 PM

Quote:

Originally Posted by szboardstretcher (Post 5341479)
Lot of good ideas guys. Unfortunately none work on Centos 6.6.



when using sshfs:

Code:

sshfs 192.168.1.5:/root tmp
root@192.168.1.5's password:
remote host has disconnected

It still runs the .bashrc exit 0 command and doesnt mount.

You're right, it must have just been suppressing the echo. I set up a VM to test this and I haven't been able to find a way in yet.

Quote:

Originally Posted by szboardstretcher (Post 5341479)
This is a tough nut to crack on Centos. I'm not understanding why all of the 'ignore bashrc' commands and switches do not work. I have successfully done this on Ubuntu with no issue. But I'm guessing that the additional user has a lot to do with that. Perhaps 'root' is locked down further when logging in.

Because those aren't switches for ssh, they're switches for bash. So ssh is launching a bash session, and inside that bash session it runs "bash --norc" or whatever else you set. The problem is it's the first session that's kicking you out, before it even gets a chance to run "bash --norc".

What you need is a flag to ssh itself that tells it not to source .bashrc when it establishes the connection. Nothing you add or run in the "command" section of ssh is going to make a difference, since it's already sourced .bashrc before any of that is run.

Quote:

Originally Posted by grail
So can you confirm that adding to /etc/ssh/sshrc did not work either?

It does not. It must be sourcing the remote .bashrc before the contents of sshrc are executed on the remote system, because it doesn't seem to make a difference.

joe_2000 04-02-2015 03:08 PM

I had that very problem the other day and I remember I was able to bypass bashrc by using /bin/sh as the shell. I am not sure what the exact syntax was but I think it was something like
Code:

ssh -t /bin/sh user@remotehost
EDIT: Just tried this and it aborts with an error. On second thought I think the problem was with su to root, not the actual remote login.

jpollard 04-02-2015 03:19 PM

Quote:

Originally Posted by szboardstretcher (Post 5341500)
Update: A friend of mine - a developer - hit CTRL-C at the proper moment in the ssh login, and it broke out of the .bashrc file and allowed the login.

While this works - I still would like the answer to my question. WHY are all these ssh flags and parameters being ignored for root?

It is being ignored because of the way the commands are being interpreted:

An ssh to a remote host ALWAYS does the following:

1. verify user (by whatever means)
2. if a command is being passed (ANY command):
2a. executes /bin/sh to interpret the command. Guess what, this is done BEFORE the command is interpreted, and thus processes the .rc file FIRST. An exit there terminates the connection before the command is interpreted. And that includes sshfs or scp.
2b. if the command is an scp, then the scp command is executed with local properties (the "remote file" is now a local file.

I'm not exactly certain of the sequence for sshfs, but I think it is similar - the local sshfs command makes a connection to the sshd service on the remote host, which then executed /bin/sh to interpret a sshfs command with the given target directory - and uses an internal flag to identify it is to provide remote filesystem functions (an RPC service).

As I said, there is no real bypass. You can try the "control C" interrupt - but that depends on a race condition (the interrupt is received before the exit command is processed).

grail 04-03-2015 01:55 AM

Well I am not sure why my method does not work for others, but I guess I should contact the developers and tell them that the following line should be removed from the man page:
Code:

      /etc/ssh/sshrc
              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.

At least the part in red should be removed if only works on some computers.


All times are GMT -5. The time now is 09:04 PM.