Forum Linux.général Commande distante avec ssh

Posté par gremous le 31 octobre 2008 à 17:21.

Étiquettes : aucune

oct.

2008

Bonjour

Je tombe sur un os avec ssh.

# ssh utilisateur@machine bash -c "ls /"
(rien)

# ssh utilisateur@machine bash -c ";ls /"
bin
boot
dev
etc etc

# ssh utilisateur@machine bash -c "echo 123"
(ligne vide)

# ssh utilisateur@machine bash -c "echo 123;echo 456"
(ligne vide)
456

# ssh utilisateur@machine bash -c "echo 123;echo 456;echo 789"
(ligne vide)
456
789

Vraiment je ne comprends pas.

# Marrant ca...

Posté par aurel le 31 octobre 2008 à 17:36. Évalué à 2.

Marrant... ca viendrait de "bash -c" ? Pour ma part, je fais simplement

ssh username@remotehost "echo 123" # avec ou sans quote

Et ca marche très bien :)
- [^] # Re: Marrant ca...
  
  Posté par NeoX le 31 octobre 2008 à 18:12. Évalué à 2.
  
  c'est d'ailleurs comme ca que je fais toutes mes requetes SSH quand je n'ai pas besoin d'etre vraiment sur la machine.
- [^] # Re: Marrant ca...
  
  Posté par Damien (site web personnel) le 01 novembre 2008 à 14:19. Évalué à 2.
  
  Le problème de ssh user@remotehost commande c'est que la commande s'exécute dans un shell de base, sans ton environnement perso. En passant par bash -lic on peut avoir un environnement complet qui a ta config de ~/.bashrc et/ou ~/.bash_profile.
# [mode verbose on]

Posté par ecid le 31 octobre 2008 à 17:37. Évalué à 1.
Que donne la même commande avec l'option -v ? Avec ton premier exemple, on devrait voir la ligne suivante:
```
debug1: Sending command: bash -c ls /
```
Une autre piste serait de faire le même ssh en localhost en étant déjà connecté au serveur "machine":
```
ssh utilisateur@localhost bash -c ";ls /"
```
# j'ai peut être l'explication...

Posté par genma (site web personnel) le 31 octobre 2008 à 17:38. Évalué à 4.

bash -c représente une première commande et echo 123 une seconde. Le ";" sépare deux commandes. Tu le mets d'ailleurs bien pour séparer les trois commandes "echo 123;echo 456;echo 789"

Ca doit venir de là. Dans bash -c "ls /", le ls / est compris comme un argument et non comme une commande...
# protections (quoting)

Posté par tuxce (site web personnel) le 31 octobre 2008 à 18:53. Évalué à 2.

le ssh interpréte les guillemets "" et envoie donc à l'hote:
bash -c echo 123;echo 456;echo 789
sans les ", bash quand à lui ne prend qu'un argument après le -c ->
echo
ce qui fait la ligne vide (le "ls" ne prend pas le / et doit lister le répertoire courant qui doit être vide)

en gros, si tu tiens absolument à tout envoyer avec le "bash -c":
ssh user@hote "bash -c 'echo 123;echo 456;echo 789'"
- [^] # Re: protections (quoting)
  
  Posté par Kerro le 31 octobre 2008 à 19:34. Évalué à 2.
  
  C'est effectivement le même "bug" que pour scp:
  scp toto@machine:"'source avec espaces'" cible
  
  On peut faire aussi:
  ssh user@hote bash -c "'echo 123;echo 456;echo 789'"
  Ca surprend d'avoir "' puis '" :-)
  - [^] # Re: protections (quoting)
    
    Posté par tuxce (site web personnel) le 31 octobre 2008 à 20:43. Évalué à 2.
    
    c'est pas un bug, c'est le traitement normal de la protections d'arguments
    - [^] # Re: protections (quoting)
      
      Posté par Kerro le 01 novembre 2008 à 01:39. Évalué à 1.
      
      Si ce n'est pas un bug, c'est rudement bien imité car on en trouve trace un peu partout :-)
      C'est référencé comme bug 419848 chez Debian. 89945 chez Ubuntu. Je n'ai pas cherché ailleurs.
      
      La réponse des intégristes est "ce fonctionnement tordu est normal".
      - [^] # Re: protections (quoting)
        
        Posté par wismerhill le 01 novembre 2008 à 09:54. Évalué à 4.
        
        C'est peut-être tordu, mais oui c'est normal.
        Le shell interprète la ligne avant de lancer la commande, donc ta ligne
        
        ssh utilisateur@machine bash -c "echo 123;echo 456"
        
        est d'abord interprétée par le shell, qui enlève les guillemets et ssh ne voit que
        
        ssh utilisateur@machine bash -c echo 123;echo 456
        
        qu'il envoie au serveur distant, qui lui verra
        
        bash -c echo 123;echo 456
        
        qui sera a son tour interprété par le shell distant, qui va séparer ça en deux commandes
        
        bash -c echo 123
        echo 456
        
        Pour ce que tu veux faire tu aurais du essayer
        
        ssh utilisateur@machine bash -c '"echo 123;echo 456"'
        
        où les simple quote vont protéger les doubles qui seront passés tels quel à ssh qui va les envoyer comme ça au serveur distant, qui exécutera donc la commande
        
        bash -c "echo 123;echo 456"
        
        mais comme écrit par d'autres, un simple
        
        ssh utilisateur@machine "echo 123;echo 456"
        
        fait l'affaire (les double quote sont encore là pour protéger le point-virgule).
      - [^] # Re: protections (quoting)
        
        Posté par tuxce (site web personnel) le 01 novembre 2008 à 14:55. Évalué à 3.
        
        pourquoi tu estimes que le fonctionnement est tordu?
        et si tu veux vraiment qu'une variable par exemple soit interprétée, tu fais comment? tu crées un moyen pour l'indiquer !
        
        la ligne est interprétée à chaque étape; pour la question d'origine, c'est d'abord le shell puis ssh et enfin bash! et le problème de départ est la première ligne vide qui est due à la façon dont le bash traite l'argument "-c" qui ne prend qu'un seul argument, tu vas quand meme pas lui imposer d'en prendre 2 ou plus :p (ca en casserait des scripts)
        
        pour ce qui est des bugs, celui de debian n'est pas considéré comme bug et celui d'ubuntu est résolu et ne concerne que l'affichage pas le succès de l'opération.
# Quotes !

Posté par gUI (Mastodon) le 03 novembre 2008 à 18:03. Évalué à 2.

As-tu essayé en quotant ta commande ?

ssh utilisateur@machine 'bash -c "ls /"'
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.