Sstrhsrtj

so I have this problem, I can't login to my server with SSH.
See:

ssh -v myuser@myserver

debug1: Authentication succeeded (password).

debug1: channel 0: new [client-session]

debug1: Requesting no-more-sessions@openssh.com

debug1: Entering interactive session.

debug1: Sending environment.

debug1: Sending env LANG = en_US.UTF-8

Last login: Sun Jul  5 20:10:54 2015 from x.x.x.x

-bash: KSH_VERSION: unbound variable

debug1: client_input_channel_req: channel 0 rtype exit-status reply 0

debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0

debug1: channel 0: free: client-session, nchannels 1

Connection to x.x.x.x closed.

Transferred: sent 2264, received 2800 bytes, in 0.2 seconds

Bytes per second: sent 13241.8, received 16376.8

debug1: Exit status 1

The problem is the "-bash: KSH_VERSION: unbound variable", this kills the connection I think.
I know why is it happening…I was working on a script placed in /etc/profile.d, and this script has "set -euo pipefail" (ouch) in it...
The "o" option is "nounset" and that exaplains the "unbound variable"...
When the script sets the options, it make the vim.sh there failing on the unbound variable.

Now, how get around this? I can't send just a command there over ssh, to remove the file for example, I can't login as another user, I can't use another shell, the "--noprofile" and "--norc" options for bash doesn't work…no trick I tried worked…

Any ideas, pretty please?

You have about 1/3 chance (at least I get 1/3) to interrupt (hit Ctrl+C) the login process before /etc/profile is sourced:

$ ssh -v localhost

OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013

........

Authenticated to localhost ([::1]:22).

debug1: channel 0: new [client-session]

debug1: Requesting no-more-sessions@openssh.com

debug1: Entering interactive session.

debug1: Sending environment.

debug1: Sending env LANG = en_US.UTF-8

Last login: Tue Jul  7 19:46:42 2015 from localhost

^C-bash-4.2$ 

Edit to clarify a few things:

When sshd opens a session on the server, it does so by reading the user shell (that is /bin/bash in this case).

It does not matter whatever option is given on bash or ssh command to run (including sftp). That ssh command (including sftp) or bash option is passed to a bash instance after a session is opened. You have no control on what that instance does. For example:

client$ ssh localhost bash --noprofile --norc

strace output on the server:

[pid 60047] execve("/bin/bash", ["bash", "-c", "bash --noprofile --norc"], [/* 16 vars */]) = 0

[pid 60047] execve("/usr/bin/bash", ["bash", "--noprofile", "--norc"], [/* 28 vars */]) = 0

As you can see the ssh command ("bash --noprofile --norc") is passed on the first execve as an argument to "bash" with the "-c" option.

That first bash instance that you have no control on with read ~/.bashrc which in turn will read /etc/bashrc which will load the scripts under /etc/profile.d/ (at least on a Red Hat system - I don't know about others).

[pid 60047] open("/home/user/.bashrc", O_RDONLY) = 3

[pid 60047] open("/etc/bashrc", O_RDONLY) = 3

The only way I can think of is the above, been quick enough to abort the login process before the scripts are loaded (but not to quick as to abort the session). - You might want to increase the load on the system (if it's possible) to give you more time during the login process.

ps. if you find the answer useful please mark it

I had the same problem and finally found a solution.

As @nkms mentioned:

You have about 1/3 chance (at least I get 1/3) to interrupt (hit Ctrl+C) the login process before /etc/profile is sourced

To raise you chances i've used the following loop:

$ (trap '' INT; while true; do ssh myuser@myserver; done)

The script starts subshell '(' and deactivates the ctr-c command for that subshell (with the trap command). Then it loops over the ssh command.
If you continuously press ctrl-c or hold down ctrl-c, you raise you chances to hit the right moment.

... works like a charm!

Does sftp also fail ? If doesn't, you could make use of that to place a good /etc/profile.d file there.

I have two problems with your question.

ps -A|grep bash|wc -l

and the same command in

ssh localhost 'csh -l'

give the same number.

So it does not seem that a bash is run before 'csh -l'.

On the other hand csh does not use /etc/profile.

strace -eopen csh -l

does not show any entry of /etc/profile*.

So I am not sure the problem you have is in /etc/profile*.

Am I missing something?