Connectez-vous sans exécuter bash_profile ou bashrc
Disons que l'on a tapé quelque chose dans leur .bashrc qui l'empêche de se connecter via ssh (c'est-à-dire que la connexion ssh se termine en raison de l'erreur dans le fichier). Existe-t-il un moyen pour cette personne de se connecter sans l'exécuter (ou .bashrc puisque l'un exécute l'autre), ou sinon supprimer/renommer/invalider le fichier?
Supposons que vous n'ayez pas d'accès physique à la machine, et c'est le seul compte utilisateur avec la possibilité de se connecter.
Pour référence: .bash_profile comprend .bashrc:
[[ -f ~/.bashrc ]] && . ~/.bashrc
Edit: Ce que j'ai essayé:
ssh user@Host "rm ~/.bashrc"
scp nothing user@Host:/RAID/home/tom/.bashrc
ssh user@Host "/bin/bash --norc"
Tous donnent l'erreur:
/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
Je pense que vos seules options sont:
ssh en tant qu'un autre utilisateur et su sur votre compte;
utiliser quelque chose comme ftp ou smbclient, si les services appropriés sont activés sur l'hôte;
trouver une vulnérabilité ouverte dans un service réseau ouvert et l'exploiter :).
demandez à un administrateur de résoudre le problème.
ssh -t username@hostname /bin/sh travaille pour moi.
J'ai eu le même problème et j'ai pu le résoudre d'une manière ou d'une autre. J'ai utilisé ssh pour accéder au système et j'ai appuyé et maintenu Ctrl + c dès que je me suis connecté au système. Ensuite, ~/.bashrc n'a pas été lu et j'ai pu le modifier.
J'ai utilisé un CVE publié pour exécuter une commande en tant que root via une interface Web dans un logiciel de surveillance réseau que j'avais installé. rm /RAID/home/tom/.bashrc
Ensuite, je pouvais me connecter et svn annuler les modifications que j'avais apportées.
Vous devez a) démarrer bash sans source 'ni ~/.bashrc ou ~/.bash_profile et b) puisqu'un tel shell ne serait pas un shell de connexion complet/sans tty attaché, force ssh pour attacher un tty :
ssh -t user@Host bash --norc --noprofile
Vous n'avez pas de chance.
Toutes les commandes ssh exécutent votre shell de connexion. ssh $COMMAND s'exécute $Shell -c $COMMAND, scp exécute $Shell -c /path/to/sftp-server, plain ssh exécute simplement votre Shell.
Aucune des réponses ci-dessus ne peut contourner le shell de connexion de ssh. Vous pouvez passer une ligne de commande complète et exécuter le shell distant pour traiter la commande et définir l'environnement de travail de la commande. C'est à cela que servent les obus et c'est la manière Unix. Vous auriez toutes sortes de problèmes de compatibilité si vous tentiez d'exécuter quelque chose sans Shell. De même, essayer un contrôle-C devrait faire la même chose que d'appeler exit qui est le comportement que vous essayez d'éviter. Si bash continue, c'est un bug. Pourquoi les gens continuent à dire que la page de manuel dit quelque chose de différent, il faut la citer parce qu'elle ne dit rien de la sorte dans ma page de manuel.
De plus, sur la plupart des systèmes Linux, la spécification de/bin/sh ne fait RIEN puisque ce n'est qu'un lien symbolique vers bash!
Tu veux tester? Ajoutez les instructions "echo" à vous .bashrc et .profile et voyez laquelle est exécutée. J'ai fait. Voici les résultats.
ssh user@Host exécutera .bash_profile ssh user@Host /bin/bash exécutera .bashrc, mais il pense que ce n'est pas interactif (pas d'invite). ssh -t user@Host /bin/bash exécute .bashrc deux fois ... une fois à la connexion, une fois pour la commande passée, donc spécifier TOUT Shell exécutera toujours le premier. ssh -T user@Host revient à ne pas spécifier du tout -T ou -t.
Maintenant, si vous remarquez, MON système n'exécute pas les deux fichiers, seulement l'un ou l'autre. Mais l'affiche originale a une ligne dans .bash_profile exécutant .bashrc, donc .bashrc sera toujours exécuté quoi qu'il arrive. N'aurait pas dû mettre cette ligne là! Si cette ligne n'existait pas, vous n'auriez pas eu de problème.
Vous devrez trouver un autre moyen ou trouver un administrateur. C'est à cela que servent les administrateurs.
Quelque chose comme:
ssh Host "/bin/bash --norc"
qui semble fonctionner, mais notez que la PS1 n'est pas définie, vous allez donc taper des commandes sans invite.
Cela a l'avantage d'être non destructif.
ssh -t user@Host "bash --norc --noprofile -c '/bin/rm .bashrc'"
essayer
echo ^C | ssh <hostname> ' rm .bashrc'
^ C il y a control-v puis c
Mashing ctrl-C fonctionne tant que vous pouvez obtenir un ctrl-C avant que le .bashrc ne se termine. Malheureusement, cela peut être difficile à faire si exit est au début du .bashrc.
Vous pouvez mettre un ctrl-C dès que possible en le canalisant directement vers ssh:
{ echo ^C; cat /dev/tty; } | ssh -tt user@Host
Notez que ^C est tapé comme ctrl-V suivi de ctrl-C.
Cela envoie un seul Ctrl-C suivi d'une entrée du terminal de contrôle, tandis que -tt force l'allocation d'un pseudo-terminal. Tout cela vous donne un Shell (quelque peu malformé) sur la machine distante tout en contournant autant de .bashrc que possible.
UH = 'user @ Host'; ssh $ UH 'mv ~/.bashrc ~/letmein'; ssh $ UH
Veuillez ne pas couper et exécuter, modifier user et Host, puis modifier letmein et enregistrer sous .bashrc
Vous pouvez essayer d'écraser le .bash_profile avec un fichier vide à l'aide de la commande scp. D'après ce que j'ai googlé, scp utilise une connexion non interactive qui ne lit pas .bash_profile.
Vous pouvez également simplement supprimer le fichier bashrc:
ssh <hostname> rm ~/.bashrc
Si votre système est configuré normalement, .bash_profile ne sera pas exécuté pour un shell non interactif (comme l'exécution d'une commande).
Puisque vous indiquez que le problème se trouve dans le fichier .bash_profile, essayez de le déplacer hors du chemin:
ssh user@Host "mv ~/.bash_profile ~/.bash_profile_broken"
Félicitations à l'utilisateur 60069, cela a fonctionné pour moi, mais j'utilise le fichier de démarrage spécifique à Shell .bashrc, donc la connexion avec/bin/sh a fonctionné pour moi.
Cependant, si vous êtes dans la situation "pas de chance", je propose cette solution, basée sur les solutions de user60069 et Dennis W:
ssh -t you@Host /bin/bash --noprofile --norc
Dennis W a proposé l'option --norc, qui, selon quelqu'un, ne fonctionnait pas pour eux.
Exécutez "man bash" ou "man (votre Shell)" pour les options permettant de désactiver les fichiers de démarrage. Vous n'avez besoin d'utiliser un shell répugnant que le temps nécessaire pour résoudre le problème.
L'autre moyen de se connecter au serveur est sans profil, veuillez trouver la commande ci-dessousssh -t user@Host bash --noprofile
Pour AWS utilisant un fichier pem et aucun autre utilisateurssh -ti "YOUR-PEM-FILE-NAME.pem" ec2-user@YOUR-IP-ADDRESS bash --noprofile
J'espère que cela t'aides!