J'ai vu les questions et les réponses sur la nécessité d'échapper deux fois les arguments aux commandes ssh distantes. Ma question est la suivante :exactement où et quand la deuxième analyse est-elle effectuée ?
Si j'exécute ce qui suit :
$ ssh otherhost pstree -a -p
Je vois ce qui suit dans la sortie :
|-sshd,3736
| `-sshd,1102
| `-sshd,1109
| `-pstree,1112 -a -p
Le processus parent de la commande distante (pstree ) est sshd , il ne semble pas y avoir de shell qui analyserait les arguments de ligne de commande de la commande distante, il ne semble donc pas que des guillemets doubles ou des échappements soient nécessaires (mais c'est définitivement le cas). Si au lieu de cela, je me connecte d'abord en ssh et obtiens un shell de connexion, puis j'exécute pstree -a -p Je vois ce qui suit dans la sortie :
├─sshd,3736
│ └─sshd,3733
│ └─sshd,3735
│ └─bash,3737
│ └─pstree,4130 -a -p
Il y a donc clairement un bash shell là qui ferait l'analyse de la ligne de commande dans ce cas. Mais dans le cas où j'utilise directement une commande distante, il ne semble pas y avoir de shell, alors pourquoi les guillemets doubles sont-ils nécessaires ?
Réponse acceptée :
Il y a toujours un shell distant. Dans le protocole SSH, le client envoie au serveur une chaîne à exécuter. Le client de ligne de commande SSH prend ses arguments de ligne de commande et les concatène avec un espace entre les arguments. Le serveur prend cette chaîne, exécute le shell de connexion de l'utilisateur et lui transmet cette chaîne. (Plus précisément :le serveur exécute le programme enregistré en tant que shell de l'utilisateur dans la base de données des utilisateurs, en lui transmettant deux arguments de ligne de commande :-c et la chaîne envoyée par le client. Le shell n'est pas appelé en tant que shell de connexion :le serveur ne définit pas le zéroième argument sur une chaîne commençant par - .)
Il est impossible de contourner le shell distant. Le protocole n'a rien comme envoyer un tableau de chaînes qui pourraient être analysées comme un tableau argv sur le serveur. Et le serveur SSH ne contournera pas le shell distant car cela pourrait être une restriction de sécurité :l'utilisation d'un programme restreint comme shell de l'utilisateur est un moyen de fournir un compte restreint qui n'est autorisé qu'à exécuter certaines commandes (par exemple, un compte rsync uniquement ou un compte git uniquement).
Vous ne pouvez pas voir le shell dans pstree car il est peut-être déjà parti. De nombreux shells ont une optimisation où s'ils détectent qu'ils sont sur le point de faire "lancez cette commande externe, attendez qu'elle se termine et quittez avec le statut de la commande", alors le shell exécute "execve de cette commande externe » à la place. C'est ce qui se passe dans votre premier exemple. Comparez les trois commandes suivantes :
ssh otherhost pstree -a -p
ssh otherhost 'pstree -a -p'
ssh otherhost 'pstree -a -p; true'
Les deux premiers sont identiques :le client envoie exactement les mêmes données au serveur. Le troisième envoie une commande shell qui annule l'optimisation exec du shell.
En relation :Quelle est la différence entre les verrous tournants et les sémaphores ?