Comment limiter les utilisateurs SSH à un ensemble prédéfini de commandes après la connexion ?

Vous pouvez également limiter les clés aux commandes autorisées (dans le fichier authorized_keys).

C'est à dire. l'utilisateur ne se connecterait pas via ssh et aurait alors un ensemble restreint de commandes, mais serait plutôt autorisé à exécuter ces commandes via ssh (par exemple "ssh somehost bin/showlogfile")

Ce que vous recherchez s'appelle Shell restreint. Bash fournit un tel mode dans lequel les utilisateurs ne peuvent exécuter que les commandes présentes dans leurs répertoires personnels (et ils ne peuvent pas se déplacer vers d'autres répertoires), ce qui peut vous suffire.

J'ai trouvé ce fil très illustratif, bien qu'un peu daté.

ssh suit le rsh tradition en utilisant le programme shell de l'utilisateur à partir du fichier de mots de passe pour exécuter des commandes.

Cela signifie que nous pouvons résoudre ce problème sans impliquer ssh configuration de quelque manière que ce soit.

Si vous ne voulez pas que l'utilisateur puisse avoir accès au shell, remplacez simplement le shell de cet utilisateur par un script. Si vous regardez dans /etc/passwd vous verrez qu'il y a un champ qui assigne un interpréteur de commandes shell à chaque utilisateur. Le script est utilisé comme shell à la fois pour leur connexion interactive ssh [email protected] ainsi que pour les commandes ssh [email protected] command arg ... .

Voici un exemple. J'ai créé un utilisateur foo dont le shell est un script. Le script imprime le message my arguments are: suivi de ses arguments (chacun sur une ligne séparée et entre crochets) et se termine. Dans le cas de connexion, il n'y a pas d'arguments. Voici ce qui se passe :

webserver:~# ssh [email protected]
[email protected]'s password:
Linux webserver [ snip ]
[ snip ]
my arguments are:
Connection to localhost closed.

Si l'utilisateur tente d'exécuter une commande, celle-ci ressemble à ceci :

webserver:~# ssh [email protected] cat /etc/passwd
[email protected]'s password:
my arguments are:
<-c>
<cat /etc/passwd>

Notre "shell" reçoit un -c invocation de style, avec la commande entière comme un argument, de la même manière que /bin/sh le recevrait.

Donc, comme vous pouvez le voir, ce que nous pouvons faire maintenant est de développer davantage le script afin qu'il reconnaisse le cas où il a été invoqué avec un -c argument, puis analyse la chaîne (par exemple par correspondance de modèle). Les chaînes autorisées peuvent être transmises au vrai shell en appelant récursivement /bin/bash -c <string> . Le cas de rejet peut imprimer un message d'erreur et se terminer (y compris le cas où -c est manquant).

Vous devez faire attention à la façon dont vous écrivez ceci. Je recommande d'écrire uniquement des correspondances positives qui n'autorisent que des choses très spécifiques et d'interdire tout le reste.

Remarque : si vous avez root , vous pouvez toujours vous connecter à ce compte en remplaçant le shell dans le su commande, comme ceci su -s /bin/bash foo . (Coquille de remplacement au choix.) Non-root ne peut pas faire cela.

Voici un exemple de script :restreindre l'utilisateur à n'utiliser que ssh pour git accès aux référentiels sous /git .

#!/bin/sh

if [ $# -ne 2 ] || [ "$1" != "-c" ] ; then
  printf "interactive login not permitted\n"
  exit 1
fi

set -- $2

if [ $# != 2 ] ; then
  printf "wrong number of arguments\n"
  exit 1
fi

case "$1" in
  ( git-upload-pack | git-receive-pack )
    ;; # continue execution
  ( * )
    printf "command not allowed\n"
    exit 1
    ;;
esac

# Canonicalize the path name: we don't want escape out of
# git via ../ path components.

gitpath=$(readlink -f "$2")  # GNU Coreutils specific

case "$gitpath" in
  ( /git/* )
     ;; # continue execution
  ( * )
    printf "access denied outside of /git\n"
    exit 1
    ;;
esac

if ! [ -e "$gitpath" ] ; then
   printf "that git repo doesn't exist\n"
   exit 1
fi

"$1" "$gitpath"

Bien sûr, nous espérons que ces programmes Git git-upload-pack et git-receive-pack n'ont pas de trous ou de trappes d'évacuation permettant aux utilisateurs d'accéder au système.

C'est inhérent à ce type de système de restriction. L'utilisateur est authentifié pour exécuter du code dans un certain domaine de sécurité, et nous introduisons une restriction pour limiter ce domaine à un sous-domaine. Par exemple, si vous autorisez un utilisateur à exécuter le vim commande sur un fichier spécifique pour le modifier, l'utilisateur peut simplement obtenir un shell avec :!sh[Enter] .