Digamos que digamos algo em seu .bashrc que o impeça de fazer login via ssh (ou seja, o login do ssh é encerrado devido ao erro no arquivo). Existe alguma maneira que a pessoa possa logar sem executá-lo (ou .bashrc desde que o outro execute o outro), ou então excluir / renomear / invalidar o arquivo?
Suponha que você não tenha acesso físico à máquina, e esta é a única conta de usuário com capacidade para ssh.
Para referência: .bash_profile inclui .bashrc :
[[ -f ~/.bashrc ]] && . ~/.bashrc
Edit: coisas que tentei:
ssh user@host "rm ~/.bashrc"
scp nothing user@host:/RAID/home/tom/.bashrc
ssh user@host "/bin/bash --norc"
Todos dão o erro:
/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
Eu acho que suas únicas opções são:
ssh como outro usuário e su na sua conta;
use algo como ftp ou smbclient, se os serviços relevantes estiverem habilitados no host;
encontre uma vulnerabilidade aberta em um serviço de rede aberta e explore-a:).
peça a um administrador para corrigir o problema.
ssh -t username@hostname /bin/sh funciona para mim.
Eu tive o mesmo problema e, de alguma forma, consegui resolvê-lo. Eu usei o ssh para acessar o sistema e pressionei e segurei Ctrl + c assim que entrei no sistema. Então, ~ / .bashrc não foi lido, e eu pude modificá-lo.
Eu usei um CVE publicado para executar um comando como root através de uma interface web em um software de monitoramento de rede que eu tinha instalado. rm /RAID/home/tom/.bashrc
Então eu poderia logar e svn reverter as alterações que fiz.
Você precisa de a) iniciar bash sem source ' ~/.bashrc ou ~/.bash_profile eb) já que esse shell não seria um shell de login completo / não tem < strong> tty anexado, forçar ssh para anexar um tty :
ssh -t user@host bash --norc --noprofile
Você está sem sorte.
Todos os comandos ssh executam seu shell de login. ssh $COMMAND corre $SHELL -c $COMMAND , scp corre $SHELL -c /path/to/sftp-server , simples ssh apenas executa a sua concha.
Nenhuma das respostas acima pode ignorar o shell de login do ssh. Você pode passar uma linha de comando completa e, portanto, executa o shell remoto para processar o comando e definir o ambiente de trabalho do comando. Isso é o que as shells são para e é o caminho Unix. Você teria todos os tipos de problemas de compatibilidade se tentasse executar algo sem um shell. Da mesma forma, tentar um controle-C deve fazer o mesmo que chamar exit, que é o comportamento que você está tentando evitar. Se o bash continua sendo um bug. Por que as pessoas continuam dizendo que a página man diz algo diferente, é necessário citá-la porque não diz nada do tipo na minha página de manual.
Além disso, na maioria dos sistemas linux, especificar / bin / sh faz NADA, já que este é apenas um link simbólico para o bash!
Quer testar? Adicione instruções "echo" a você .bashrc e .profile e veja qual delas é executada. Eu fiz. Aqui estão os resultados.
ssh user@host executará .bash_profile
ssh user@host /bin/bash executará .bashrc, mas acha que é não interativo (sem prompt).
ssh -t user@host /bin/bash executa .bashrc duas vezes ... uma vez no login, uma vez para o comando passado, portanto, especificar QUALQUER shell sempre executará o primeiro.
ssh -T user@host é o mesmo que não especificar -T ou -t em tudo.
Agora, se você perceber, o MEU sistema não está executando os dois arquivos, apenas um ou outro. Mas o pôster original tem uma linha em .bash_profile executando .bashrc, então .bashrc sempre será executado, não importa o quê. Não deveria ter colocado essa linha lá! Se essa linha não existisse, você não teria um problema.
Você precisará encontrar outro caminho ou encontrar um administrador. É para isso que os administradores são.
Algo como:
ssh host "/bin/bash --norc"
que parece funcionar, mas note que o PS1 não está configurado, então você estará digitando comandos sem um prompt.
Isso tem a vantagem de ser não destrutivo.
ssh -t user@host "bash --norc --noprofile -c '/bin/rm .bashrc'"
tente
echo ^C | ssh <hostname> ' rm .bashrc'
^ C existe control-v então c
Você pode tentar sobrescrever o .bash_profile com um arquivo vazio usando o comando scp . Pelo que pesquisei, o scp usa um login não interativo que não lê .bash_profile .
Você também pode simplesmente excluir o arquivo bashrc:
ssh <hostname> rm ~/.bashrc
Se o seu sistema estiver configurado normalmente, o .bash_profile não será executado para um shell não interativo (como a execução de um comando).
Como você afirma que o problema está no arquivo .bash_profile, tente movê-lo para fora do caminho:
ssh user@host "mv ~/.bash_profile ~/.bash_profile_broken"
UH='user@host'; ssh $UH 'mv ~/.bashrc ~/letmein'; ssh $UH
Por favor, não o corte e corra, mude user e host , então edite letmein e salve como .bashrc
Kudos para user60069, funcionou para mim, mas eu uso o arquivo de inicialização específico do shell .bashrc, então o login com / bin / sh funcionou para mim.
No entanto, se você estiver na situação "sem essa sorte", ofereço essa solução com base nas soluções do user60069 e do Dennis W:
ssh -t you@host /bin/bash --noprofile --norc
Dennis W ofereceu a opção --norc, que alguém disse que não funcionava para eles.
Execute "man bash" ou "man (your shell)" para opções de desativação dos arquivos de inicialização. Você só precisa usar um shell repugnante pelo tempo que leva para corrigir o problema.
Outra forma de fazer login no servidor é sem perfil, por favor, ache o comando abaixo: ssh -t user@host bash --noprofile
Para o AWS usando o arquivo pem e nenhum outro usuário do ssh -ti "YOUR-PEM-FILE-NAME.pem" ec2-user@YOUR-IP-ADDRESS bash --noprofile
Espero que isso ajude!
Das sugestões e respostas dadas acima, eu diria que não são os arquivos .bashrc ou .bash_profile. Também ssh manpage diz que se você especificar um comando a ser executado, seus arquivos de perfil não serão lidos.
Sugiro tentar executar um shell de login diferente (ksh? csh? sh?) a partir do caminho absoluto; também, cuidado com o fato de que pode ser um problema totalmente diferente (cota? executar e ler permissão em seu diretório pessoal?), portanto, uma abordagem lateral seria melhor. Você pode pedir a outro usuário para fazer um ls -la $YOUR_HOME_DIR e enviar o resultado por e-mail?