Question (svn + ssh) demande à bash de charger mon chemin via SSH


Ce problème vient avec moi essayant de faire svnserve (Serveur Subversion) disponible sur un serveur via SSH. J'ai compilé SVN et l'ai installé dans $HOME/bin. L'accès local à celui-ci (pas via SSH) fonctionne bien.

Connexions à svn+ssh échouer à cause de:

bash: svnserve: command not found

En déboguant ceci, j'ai trouvé que:

ssh user@server "which svnserve"

dit:

which: no svnserve in (/usr/bin:/bin)

C'est étrange, car j'ai mis à jour le chemin d'accès à $HOME/bin dans mon .bashrc, et l'a également ajouté dans ~/.ssh/environment. Cependant, il semble que le SSH ne le lise pas. Bien que quand je cours:

ssh user@server "echo $PATH"

Il Est-ce que imprimer mon chemin mis à jour!

Que se passe t-il ici? Comment puis-je faire en sorte que SSH trouve mon svnserve? Merci d'avance


6
2018-04-09 07:32


origine


Lorsque vous exécutez 'ssh utilisateur @serveur "echo $ PATH"', $ PATH est développé localement, ce qui vous donne PATH sur localhost. Essayez d'échapper à $ comme "echo \ $ PATH". (ne résout pas votre problème, mais vous aidera à résoudre les problèmes). - Shawn Chin
@lsc: cela explique le mystère "echo $ PATH", merci - Eli Bendersky
En passant, vous voudrez peut-être mettre à jour le titre pour refléter votre problème actuel (c'est-à-dire svn + ssh). Cela devrait vous aider à obtenir des réponses plus pertinentes. - Shawn Chin


Réponses:


Vous pouvez essayer de lancer la commande via un bash en utilisant la commande -l afin qu’elle se comporte comme un shell de connexion.

ssh user@server "bash -l -c 'which svnserve'"

Comme indiqué dans les commentaires que j'ai laissés ci-dessus, vous aurez besoin d'échapper à tous les $ pour que les variables soient développées sur le serveur et non localement. Par exemple.:

ssh user@server "bash -l -c 'echo \$PATH'"

mettre à jour:

En ce qui concerne votre question sur la raison pour laquelle .ssh / environment ne prend pas effet, je pense que la configuration par défaut pour SSHd consisterait à ignorer les environnements utilisateur. Vous devez l'activer spécifiquement dans / etc / ssh / sshd_config (ou similaire) et ajouter:

PermitUserEnvironment yes

mise à jour 2:

Si vous n'avez pas accès à / etc / ssh / sshd_config, une solution possible (mais pas idéale) serait d'utiliser une authentification à clé publique pour lancer svnserve lors de la connexion.

Voir http://svnbook.red-bean.com/fr/1.4/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks

Notez que cela affectera votre capacité à vous connecter normalement via SSH. Pour ce faire, vous devez contourner l'authentification par clé publique:

svn -o PubkeyAuthentication=no user@server

4
2018-04-09 08:51



Merci, cela a du sens. Malheureusement, cela ne résout toujours pas le problème initial en cours svnserve via SSH. pour une raison quelconque, ssh ignore mon fichier .ssh / environemnt et chaque tentative que je tente - Eli Bendersky
@Eli answer mis à jour pour résoudre le problème .ssh / environment - Shawn Chin
Oopps .. remarque que @Dennis vous a déjà indiqué cela. Toutes mes excuses pour la répétition. - Shawn Chin
Merci. Malheureusement, puisqu'il s'agit d'un serveur partagé, je n'ai pas accès à / etc / ssh / sshd_config. Mais d'après les tests que j'ai effectués, il apparaît que cette variable n'est pas définie, car ssh ignore mon fichier d'environnement à coup sûr. - Eli Bendersky


Comme ça arrive, .bashrc et .bash_profile ne sont exécutés que si vous êtes dans un shell interactif. Lorsque vous vous connectez via ssh, vous n'êtes pas dans un shell interactif, par conséquent, votre PATH les définitions ne sont jamais exécutées. Vous pouvez associer un script à des sheels non interactifs à l'aide de BASH_ENV. Vérifiez aussi .ssh/environment ce qui vous donne une autre alternative. La meilleure façon de savoir à ce sujet est de faire man ssh.

Bonne chance!


3
2018-04-09 07:58



Désolé, mais j'ai remarqué que .ssh / environment ne fonctionnait pas pour moi. Des conseils de quoi écrire là-bas? En outre, j'avais l'impression que .bashrc est inclus dans les shells non interactifs. Sinon, comment mon PATH est-il correctement donné via ssh? (echo $ PATH)? - Eli Bendersky


Vous pouvez exécuter une commande env:

ssh nom_serveur "env PATH = $ REMOTEPATH qui svnserve"

1
2018-04-09 09:01



après avoir ajouté un point-virgule avant which, ça dit: which: no svnserve in (/usr/bin:/bin) - Eli Bendersky
@Eli: pas de point-virgule - ce qui est un argument pour env - Charles Stewart


J'ai le même problème avec HostMonster, en raison d'un changement récent qu'ils ont apporté. J'ai trouvé une solution dans un ancien fil de discussion à l'adresse http://svn.haxx.se/dev/archive-2007-02/0204.shtml:

Sur votre poste de travail:

  • modifier ~/.subversion/config: localisez [tunnels] et ajoutez la ligne ssh = ~ / svnssh
  • créer ~ / svnssh comme dans le lien:

    #!/bin/sh
    /usr/bin/ssh $1 /<ur_bluhost_home_path>/sshsvnserve -t

  • chmod +x ~/svnssh

Sur votre compte bleuhost:

  • créer ~/sshsvnserve, même contenu que le lien:

    #!/bin/sh
    /<ur_bluehost_home_path>/bin/svnserve $*

  • chmod +x ~/sshsvnserve

C'est tout. Le changement de configuration [tunnels] modifie la commande exécutée par svn lors de la gestion de l'espace de noms svn + ssh et utilise le script ur ~ / svnssh à la place. Le script appelle ssh et passe dans le chemin complet de sshsvnserve sur votre compte bluehost. Et sshsvnserve redirige tout vers le chemin complet de svnserve, à mesure que vous l’installez. Travaillé pour moi, pas de $ PATH requis.


1
2018-04-13 07:18





Définir la variable BASH_ENV à '~/.bashrc'.

ssh servername "BASH_ENV='~/.bashrc' which svnserve"

De man bash:

Lorsque bash est appelé en tant que shell de connexion interactif ou en tant qu’interface non inter‐          shell actif avec l’option --login, il commence par lire et exécuter le          commandes du fichier / etc / profile, si ce fichier existe. Après avoir lu          ce fichier, il recherche ~ / .bash_profile, ~ / .bash_login et ~ / .profile,          dans cet ordre, et lit et exécute les commandes du premier qui          existe et est lisible.

et

Quand un shell interactif qui n’est pas un shell de connexion est démarré, bash          lit et exécute les commandes de /etc/bash.bashrc et ~ / .bashrc, si          ces fichiers existent.

et

Lorsque bash est démarré de manière non interactive, pour exécuter un script shell, par exemple          Par exemple, il recherche la variable BASH_ENV dans l’environnement, se développe          sa valeur si elle y apparaît, et utilise la valeur étendue comme nom          d'un fichier à lire et à exécuter.

De man ssh:

De plus, ssh lit ~ / .ssh / environment et ajoute des lignes au format        "VARNAME = value" à l'environnement si le fichier existe et que les utilisateurs sont        permis de changer leur environnement. Pour plus d'informations, voir la        Option PermitUserEnvironment dans sshd_config (5).

De man sshd_config:

PermitUserEnvironment
               Spécifie si ~ / .ssh / environment and environment = options dans                ~ / .ssh / allowed_keys sont traités par sshd (8). La valeur par défaut est                "non". L'activation du traitement de l'environnement peut permettre aux utilisateurs de contourner                restrictions d'accès dans certaines configurations utilisant des mécanismes tels que                comme LD_PRELOAD.


0
2018-04-09 10:52



@ Dennis, oui, c'est ce que je pensais. Cependant, dans mon cas, je vois clairement que .bashrc N'EST PAS chargé. De plus, ~ / .ssh / environment est ignoré. Je peux en conclure que Bluehost (mon fournisseur de serveur) l'a configuré de cette façon, ce qui est très regrettable. P.S. la ligne avec BASH_ENV ne fonctionne pas pour moi - Eli Bendersky


J'ai réussi à faire en sorte que ssh exécute des commandes à l'aide du chemin distant en exécutant:

ssh dist@d6 "bash --login -c 'env'"

Ceci charge le fichier .profile distant, etc. Ici, env peut être remplacé par la commande de votre choix.

J'ai des clés autorisées, je n'ai donc pas besoin d'un mot de passe pour exécuter la commande ou ssh.


0
2018-04-26 15:37