Je travaille actuellement dans un réseau qui utilise LDAP pour l'authentification. Ayant défini zsh
mon shell de connexion, j'ai rencontré un problème d'accès à distance ssh
à l'une des machines du réseau qui, apparemment, n'a pas été zsh
installée. La connexion échoue avec
Dec 8 19:16:11 abert sshd[20649]: User sorokine not allowed because shell /bin/zsh does not exist
La question est donc la suivante: comment dire à la machine distante d'utiliser un shell de connexion différent de celui qui a été configuré dans LDAP?
OpenSSH_6.0p1 Debian-4 + deb7u2, OpenSSL 1.0.1e
/bin/sh
, puis demandez à votre~/.profile
exécutable distant le shell approprié si disponible?Réponses:
Si votre shell de connexion ne peut pas être exécuté sur une machine, vous ne pouvez pas vous y connecter via SSH, ou par la plupart des autres méthodes d'ailleurs. Le serveur SSH exécute toujours votre shell de connexion. Si vous passez une commande sur la
ssh
ligne de commande, le shell de connexion est exécuté avec-c
et la chaîne de commande¹ comme arguments; sinon, le shell de connexion est exécuté comme un shell de connexion sans argument.S'il y avait un moyen de contourner le shell de connexion, ce serait un trou de sécurité. Un compte peut être configuré comme un compte restreint en faisant de son shell de connexion un programme qui n'effectue qu'une seule tâche spécifique; par exemple, le shell de connexion pourrait être
git-shell
de n'autoriser que l'accès à un référentiel git, ourssh
, etc.Pour vous connecter à cette machine, vous devrez soit vous organiser pour
/bin/zsh
être présent, soit changer votre shell de connexion en quelque chose qui est présent.Ce que je recommande dans un environnement hétérogène comme celui-ci, c'est de s'en tenir à
/bin/sh
votre shell de connexion, car il est présent partout. Définissez laSHELL
variable d'environnement sur/bin/zsh
si elle est présente, de cette façon vous obtiendrez zsh comme un shell interactif.Pendant que vous y êtes, cela vous permet d'éviter de coder en dur le chemin vers
zsh
.Pour que zsh s'exécute automatiquement pour une connexion en mode texte, appelez-le depuis votre
.profile
. Si vous souhaitez utiliser.zprofile
pour configurer les choses, faites-en un shell de connexion (mais vous n'obtiendrez pas le même environnement sur les machines où zsh n'est pas présent, donc je ne le recommande pas). Ne faites cela que s'il s'agit d'une connexion interactive, pas lorsque votre.profile
est exécuté par un script, pendant la connexion en mode GUI, etc.¹ Le client SSH concatène ses arguments sans option avec des espaces entre les deux et envoie la chaîne résultante via la connexion. Les protocoles SSH définissent la commande comme une chaîne, pas une liste de chaînes.
la source
[ "0$SHLVL" -lt 2 ]
au cas où le shell de connexion par défaut prend en charge$SHLVL
afin quebash -l
ou un autre shell puisse être exécuté si besoin est (par exemple en cas d'échec de zsh pour une raison quelconque). Ainsissh -t host bash -l
exécuterait unbash
shell de connexion sans exécuter zsh derrière. En outre, je remplaceraisexec zsh
parexec zsh -l
pour que le.zlogin
fichier provienne.Vous devez éther installer le shell sur la machine spécifiée si vous avez un accès différent ou le demander à un administrateur de le faire pour vous ou changer votre shell dans ldap en un shell qui existe sur la machine distante.
(open) sshd vérifiera toujours le shell utilisateur et exécutera toujours ce shell tout ce qui est passé à exécuter. Si un autre shell est passé pour s'exécuter, il l'exécutera en le passant en argument au shell utilisateur, par exemple le shell utilisateur est '/ bin / sh' et vous passez en argument un shell csh qu'il exécutera "/ bin / sh -c / bin / csh '.
la source
ssh -l user server "ps ax" | grep bash
il est facile de remarquer que le shell par défaut n'est pas toujours appelé. Ce qui empêche vraiment l'autre solution de fonctionner, c'est le contrôle de sécurité de zsh qui n'est pas dans / etc / shells