O sftp também falha? Se não, você poderia fazer uso disso para colocar um arquivo bom /etc/profile.d lá.
então eu tenho esse problema, não consigo logar no meu servidor com o SSH. Veja:
ssh -v myuser@myserver
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
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 [email protected] 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
O problema é o "-bash: KSH_VERSION: unbound variable", isso mata a conexão que eu acho. Eu sei porque está acontecendo ... Eu estava trabalhando em um script colocado em /etc/profile.d, e este script tem "set -euo pipefail" (ai) nele ... A opção "o" é "nounset" e que examina a "variável não ligada" ... Quando o script define as opções, faz com que o vim.sh falhe na variável não ligada.
Agora, como contornar isso? Não consigo enviar apenas um comando para o ssh, para remover o arquivo por exemplo, não consigo fazer login como outro usuário, não posso usar outro shell, as opções "--noprofile" e "--norc" para o bash não funciona… nenhum truque eu tentei trabalhado…
Alguma idéia, por favor, por favor?
O sftp também falha? Se não, você poderia fazer uso disso para colocar um arquivo bom /etc/profile.d lá.
Você tem cerca de 1/3 de chance (pelo menos 1/3) de interromper (pressionar Ctrl + C) o processo de login antes do / etc / profile ser originado:
$ 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 [email protected]
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$
Edite para esclarecer algumas coisas:
Quando o sshd abre uma sessão no servidor, ele o faz lendo o shell do usuário (ou seja, / bin / bash neste caso).
Não importa qual opção é dada no comando bash ou ssh para executar (incluindo sftp). Essa opção do comando ssh (incluindo sftp) ou bash é passada para uma instância do bash após uma sessão ser aberta. Você não tem controle sobre o que essa instância faz. Por exemplo:
client$ ssh localhost bash --noprofile --norc
saída strace no servidor:
[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
Como você pode ver o comando ssh ("bash --noprofile --norc") é passado no primeiro execve como um argumento para "bash" com a opção "-c".
Essa primeira instância bash sobre a qual você não tem controle lê ~ / .bashrc que por sua vez lerá / etc / bashrc que irá carregar os scripts sob /etc/profile.d/ (pelo menos em um sistema Red Hat - Eu não sei sobre os outros).
[pid 60047] open("/home/user/.bashrc", O_RDONLY) = 3
[pid 60047] open("/etc/bashrc", O_RDONLY) = 3
A única maneira que eu posso pensar é o que foi dito acima, foi rápido o suficiente para abortar o processo de login antes dos scripts serem carregados (mas não para abortar a sessão). - Você pode querer aumentar a carga no sistema (se for possível) para lhe dar mais tempo durante o processo de login.
ps. Se você achar a resposta útil, marque-a
Eu tenho dois problemas com sua pergunta.
ps -A|grep bash|wc -l
e o mesmo comando em
ssh localhost 'csh -l'
indique o mesmo número.
Portanto, não parece que um bash seja executado antes de 'csh -l'.
Por outro lado, csh não usa /etc/profile .
strace -eopen csh -l
não mostra nenhuma entrada de /etc/profile* .
Portanto, não tenho certeza se o problema está em / etc / profile *.
Estou sentindo falta de algo?
É improvável que isso funcione, mas você pode tentar enviar um valor para KSH_VERSION quando fizer a conexão ssh:
KSH_VERSION=x ssh -v -o 'SendEnv=KSH_VERSION' myuser@myserver
A idéia é definir a variável de ambiente para algo, de modo que o bash não reclamará do fato de que não está definido. Eu digo que é improvável que funcione porque a configuração do servidor SSH padrão não permite que você defina essa variável específica. Isso só funcionaria se alguém tivesse motivos para tornar essa configuração mais branda nesse servidor em particular.
Eu tive o mesmo problema e finalmente encontrei uma solução.
Como @nkms mencionado:
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
Para aumentar suas chances, usei o seguinte loop:
$ (trap '' INT; while true; do ssh myuser@myserver; done)
O script inicia subshell '(' e desativa o comando ctr-c para essa subshell (com o comando trap) .Em seguida, ele faz um loop sobre o comando ssh. Se você pressionar ctrl-c ou pressionar ctrl-c continuamente, aumentará suas chances de acertar o momento certo.
... funciona como um encanto!
Experimente ssh -t username@hostname /bin/sh --noprofile .