Quote:
There are plenty of ways to fix it when you have access to the console and can reboot. |
Ok ... this worked for me:
Code:
sudo echo "rm /root/.bashrc" > /etc/ssh/sshrc |
Quote:
Quote:
|
Quote:
|
Quote:
|
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"' |
Quote:
Is this not the desired affect? |
Lot of good ideas guys. Unfortunately none work on Centos 6.6.
Quote:
Code:
sshfs 192.168.1.5:/root tmp 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. |
Quote:
|
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? |
So can you confirm that adding to /etc/ssh/sshrc did not work either?
|
Quote:
Quote:
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:
|
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 |
Quote:
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). |
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 |
All times are GMT -5. The time now is 09:04 PM. |