Puis-je exécuter certaines commandes lors du démarrage de la session ssh avant de passer en mode interactif?

Lors du démarrage de la session ssh avec la commande ssh, il me semble avoir deux options - session interactive par défaut avec env par défaut et à partir du répertoire personnel - ou exécuter une commande arbitraire mais de manière non interactive (même les astuces comme ssh "command; command; bash -i -l"ne semblent pas faire grand-chose). Très souvent, je veux une session interactive, mais avec quelque chose qui se passe avant cela - normalement un changement de répertoire, ou parfois un ajustement de l'environnement système. Ces choses varieraient d'une session à l'autre, donc je ne peux pas simplement les coller dans .bashrcou ainsi.

Y a-t-il un moyen d'y arriver?

Je réponds moi-même, car j'ai enfin découvert le secret. Aucune -toption pour ssh, ni -loption pour bashne mènera au shell de connexion par eux-mêmes - mais en combinaison, ils fonctionnent.

ssh user@host.com -t 'cd /some/where; FOO=BAR NUMBER=42 bash -l'change de répertoire, définit les variables d'environnement, puis démarre le bon shell de connexion (la seule différence que j'ai trouvée jusqu'à présent est qu'il /etc/motdne s'affiche pas de cette façon - c'est normalement sshla loginresponsabilité de ou non bash, à part ça, tout semble pour fonctionner parfaitement, et toutes les variables environnementales sont identiques).

Ces changements d'environnement / répertoire se produisent après ssh, ils ne sont donc pas limités par PermitUserEnvironmentles paramètres associés (exactement comme prévu), mais avant .bashrc/ .profileêtre exécuté. Cela a des avantages et des inconvénients - il est plus difficile de simplement remplacer quelque chose qui est défini à partir de scripts d'initialisation bash comme PS1, mais plus facile à emballer exactement les bonnes valeurs dans les sshlignes de commande, et à .profilefaire tout le gros du travail.

Et si c'est vraiment nécessaire, il est en fait assez facile d'obtenir que bash exécute quelque chose après .profileavec une ligne de commande comme ssh user@foo.com -t 'cd /mnt; echo ". ~/.bash_profile; PS1=\"\\h-\w \"" >~/xxx; bash --init-file ~/xxx'- très moche quand on le dit, mais ces .profilefichiers alternatifs peuvent être préparés avant. (pour autant que je sache, basha quelques emplacements candidats pour le .profilescript et exécutera le premier trouvé - . filen'a pas de tels replis automatiques, vous devrez donc vérifier où est votre normale profilesi vous voulez le faire)

Modifiez .bashrc et insérez vos paramètres d'environnement spécifiques à SSH dans:

if [ $SSH_TTY ]; then
    ...
fi

Cela vous permettrait d'ajouter des paramètres spécifiques aux sessions SSH. 'Bien sûr, si tout ce que vous voulez est de définir des variables d'environnement arbitraires qui varient selon la session, je ne sais pas comment vous pouvez faire en sorte que la machine les devine pour vous en dehors de les taper ... quoi qu'il arrive, vous' ll aura besoin d'une condition testable pour baser le choix des paramètres.

Depuis la sshpage de manuel:

De plus, ssh lit ~ / .ssh / environnement et ajoute des lignes du format "VARNAME = valeur" à l'environnement si le fichier existe et que les utilisateurs sont autorisés à changer leur environnement. Pour plus d'informations, voir l'option PermitUserEnvironment dans sshd_config (5).

qui dit:

PermitUserEnvironment
Spécifie si les options ~ / .ssh / environment et environment = dans ~ / .ssh / authorized_keys sont traitées par sshd (8). La valeur par défaut est «non». L'activation du traitement de l'environnement peut permettre aux utilisateurs de contourner les restrictions d'accès dans certaines configurations à l'aide de mécanismes tels que LD_PRELOAD.

Cette fonction peut être utilisée pour exécuter conditionnellement des instructions dans votre télécommande en ~/.bashrcutilisant la ifstructure suggérée par Mickey .

Exécutez simplement de cette façon: ssh -t yourdomain 'cd /yourpath; bash'

• -t : pour que cette invite apparaisse
• ; bash: pour qu'il retourne le contrôle malgré l'exécution de la commande (ici cd) et la sortie de la session ssh