SSH sans sourcing .bashrc
J'expérimentais mon .bashrcfichier en étant connecté à distance à un serveur via SSH. J'ai laissé par inadvertance un exitlà-dedans qui a provoqué la déconnexion immédiate de toutes les connexions suivantes. J'ai été effectivement mis en lock-out. J'ai pu récupérer l'accès avec l'intervention d'une personne disposant des privilèges root, mais cela aurait-il été possible sans l'aide de quelqu'un d'autre?
J'ai essayé de faire des trucs comme courir ssh <server> 'bash --norc --noprofile'et ssh <server> 'mv .bashrc bashrc-backup', et même essayer de l'écraser de force avec scp empty-file <server>:.bashrc. Cependant, toutes ces options semblent reposer sur le premier sourcing du cassé .bashrcavant d'exécuter la commande, donc aucune d'elles n'a fonctionné.
Il se peut fort bien qu'il n'y ait aucun moyen de sortir de ce genre de situation. Mais est-ce par conception? Y a-t-il une raison pour laquelle il est si facile de se verrouiller un système, par exemple simplement en exécutant ssh <server> 'echo exit > .bashrc'? Existe-t-il des moyens d'atténuer ce genre d'erreur?
Réponses
Comme indiqué dans l'autre réponse, lorsqu'un client SSH se connecte au serveur OpenSSH, le serveur OpenSSH démarre généralement une session shell au nom du client, en utilisant le shell de connexion de l'utilisateur:
- Si le client demande une session interactive, le serveur lancera le shell de connexion de l'utilisateur.
- Si le client demande l'exécution d'une commande, le serveur utilisera le shell de connexion de l'utilisateur pour exécuter la commande en tant que commande shell.
- Les utilitaires comme
scp,rsyncetgitqui utilisent ssh pour le transport demanderont qu'une commande soit exécutée sur le système distant, donc ils relèvent du n ° 2.
Si vous avez quelque chose dans les fichiers de démarrage du shell de l'utilisateur distant qui provoque la fermeture du shell, vous aurez du mal à entrer.
SFTP est cependant un cas particulier. Le serveur OpenSSH peut être configuré pour prendre en charge SFTP sans lancer de commande externe. Si tel est le cas, vous pourrez utiliser sftp pour vous connecter au serveur et supprimer, renommer ou modifier le .bashrcfichier à l'origine du problème.
Cela dépend de la façon dont le serveur est configuré pour prendre en charge sftp. Il peut desservir les sessions sftp en lançant un programme externe (nommé sftp-server). Dans ce cas, vous auriez le même problème d'accès que vous avez avec des programmes comme scp. Ou bien, le serveur peut desservir la session sftp par quelque chose appelé "internal-sftp" , qui ne nécessite pas d'invoquer un shell. Cela dépend simplement de la configuration du serveur SSH particulier.
La raison pour laquelle cela se produit est que sshd, le composant côté serveur, appelle les processus à l'aide de votre shell. S'il génère un shell interactif, il le fait apparaître comme un shell de connexion; sinon, il utilise l' -cargument pour générer un shell non interactif pour exécuter la commande que vous spécifiez.
Toutes les opérations que vous avez spécifiées (commandes spécifiées et scp) sont des opérations non interactives, donc normalement bash ne se chargerait pas .bashrc, mais bash a une casse spéciale pour lorsqu'elle est appelée par sshdafin qu'il l'invoque quand même. Si vous utilisiez zsh, alors .zshenv(qui est invoqué pour tous les shells) serait chargé, mais .zshrc(qui est uniquement pour les shells interactifs) ne le serait pas sauf si vous chargiez spécifiquement une session shell.
Dans ce cas, si vous utilisez bash, vous n'avez pas de chance. Il n'y a aucun moyen d'appeler une commande SSH côté serveur sans utiliser le shell; cela est vrai même pour scp et sftp. La plupart du temps, vous voulez utiliser le shell car il configure des choses comme PATHpour divers programmes, et il permet une quantité raisonnable de scripts de commandes complexes, donc OpenSSH l'utilise toujours.
Cela présente également des avantages en matière de sécurité: si vous essayez de vous connecter à un compte système qui a en quelque sorte un mot de passe valide mais un shell de /usr/sbin/nologinou /bin/false, alors vous ne pouvez rien faire, ce qui est probablement ce que l'administrateur système avait prévu.
Il existe des moyens d'atténuer cela. De nombreuses personnes conservent un référentiel Git de leurs fichiers dotfiles et les développent sur un système, puis les déploient sur d'autres. Par exemple, je fais toujours du développement de dotfile sur mon ordinateur portable. Vous remarquerez probablement ce problème un peu plus tôt si, à chaque fois que vous ouvrez une nouvelle fenêtre de terminal, elle se ferme immédiatement, et vous pouvez avoir un accès root pour le résoudre vous-même.
Si vous avez besoin de tester une configuration qui pourrait vous verrouiller, telle que la configuration du shell ou un sudoerschangement, vous pouvez laisser un shell (normal ou root, respectivement) ouvert puis faire des tests, donc si vous cassez quelque chose, vous avez toujours un moyen de l'annuler.