Autoriser SCP mais pas la connexion réelle en utilisant SSH

Très tard dans la soirée, mais il suffit de définir Shell de l'utilisateur git pour être /usr/bin/git-Shell. C'est un Shell restreint qui n'autorise pas la connexion interactive. Vous pouvez toujours vous connecter à l'utilisateur avec 'su -s /bin/bash git' ou quel que soit votre nom d'utilisateur git.

Nous utilisons un psudo Shell appelé scponly sur nos serveurs ftp sécurisés pour les utilisateurs qui doivent seulement être en mesure de transférer des fichiers mais pas de se connecter.

J'ai trouvé un bon moyen d'utiliser la fonction command="..." du fichier authorized_keys. (Suggéré par cette page )

La commande que vous exécuteriez serait celle qui teste les arguments qui commencent par scp (et rsync).

Voici le fichier authorized_keys :

# authorized_keys
command="/usr/local/bin/remote-cmd.sh" ssh-rsa.....== user@pewpew

Voici le contenu de remote-cmd.sh :

#!/bin/bash
# /usr/local/bin/remote-cmd.sh
case $SSH_ORIGINAL_COMMAND in
 'scp'*)
    $SSH_ORIGINAL_COMMAND
    ;;
 'rsync'*)
    $SSH_ORIGINAL_COMMAND
    ;;
 *)
    echo "Access Denied"
    ;;
esac

Je suppose que vous auriez probablement encore besoin de protéger le fichier authorized_keys de l'utilisateur, mais mon but était d'avoir une clé sans mot de passe que je pourrais utiliser pour les sauvegardes, sans avoir à créer un tout nouvel utilisateur, et que la clé ne donne pas un Shell (ok, facilement).

Changez le login Shell de l'utilisateur en quelque chose de restrictif, qui permet à l'utilisateur d'exécuter seulement scp , sftp-server y rsync uniquement, et il vérifie également que les arguments non sûrs ne sont pas autorisés (par exemple, la commande scp -S ... y rsync -e ... ne sont pas sûrs, voir ici : http://exploit-db.com/exploits/24795 ). Exemple pour un tel login restrictif Shell :

• rssh
• scponly (pas seulement scp, mais aussi sftp, svn etc. si configuré ainsi)
• transfer_shell

Il se peut que vous souhaitiez exécuter l'un de ces programmes dans un chroot ou dans un autre environnement restreint (par ex. nsjail sur Linux), pour désactiver l'accès au réseau et pour contrôler plus facilement (liste blanche) les répertoires qui peuvent être lus et/ou écrits.

Je ne recommande pas d'utiliser command="..." sur ~/.ssh/authorized_keys car sans une protection supplémentaire soignée (telle que chmod -R u-w ~ pour l'utilisateur) un utilisateur malveillant peut télécharger une nouvelle version de ~/.ssh/authorized_keys , ~/.ssh/rc o ~/.bashrc et peut donc inclure et exécuter des commandes arbitraires.

Ce n'est pas la solution la plus gracieuse, mais vous pourriez ajouter quelque chose comme ceci dans le .bashrc de l'utilisateur

if [ "$TERM"  != "dumb" ]; then
  exit
fi

J'ai constaté que les utilisateurs de SCP obtiennent un TERM de 'dumb', et les autres obtiennent généralement vt100.

J'imagine que l'utilisateur pourrait probablement transférer un nouveau .bashrc par scp, ce qui fait que ce n'est pas la meilleure solution, mais pour une solution rapide et sale, ceci fonctionnera.