web-dev-qa-db-fra.com

Autoriser SCP mais pas la connexion réelle à l'aide de SSH

Existe-t-il un moyen de configurer un utilisateur sur une boîte Linux (Centos 5.2 dans ce cas) afin qu'il puisse utiliser scp pour récupérer des fichiers, mais ne peut pas réellement se connecter au serveur en utilisant SSH?

linuxsshscp
63
DrStalker

rssh Shell ( http://pizzashack.org/rssh/ ) est précisément conçu à cet effet.

Étant donné que RHEL/CentOS 5.2 n'inclut pas de package pour rssh, vous pouvez consulter ici pour obtenir un RPM: http://dag.wieers.com/rpm/packages/rssh/

Pour l'utiliser, définissez-le simplement comme un shell pour un nouvel utilisateur comme celui-ci:

useradd -m -d /home/scpuser1 -s /usr/bin/rssh scpuser1
passwd scpuser1

..ou changez le Shell pour un existant comme ceci:

chsh -s /usr/bin/rssh scpuser1

..et éditez /etc/rssh.conf pour configurer le shell rssh - en particulier décommenter la ligne allowscp pour activer l'accès SCP pour tous les utilisateurs rssh.

(Vous pouvez également utiliser chroot pour garder les utilisateurs confinés dans leurs maisons, mais c'est une autre histoire.)

45
Anonymous

Je suis bien en retard, mais vous pouvez utiliser les clés ssh et spécifier la commande exacte autorisée dans leur fichier ~/.ssh/authorized_keys, par exemple.

no-port-forwarding, no-pty, command = "scp source target" ssh-dss ...

Vous devrez peut-être utiliser ps to sur la cible pour définir les bons paramètres de commande.

PS: Si vous exécutez une commande test scp avec "-v", vous pouvez voir quelque chose comme ça

debug1: Sending command: scp -v -t myfile.txt

Vous remarquerez que "-t" est une option scp non documentée, utilisée par le programme à l'extrémité. Cela vous donne une idée de ce que vous devez mettre dans des clés autorisées.

EDIT: Vous pouvez trouver plus d'informations (avec plusieurs liens) dans cette question StackOverflow .

Voici un exemple pratique de cela, pour un utilisateur nommé backup_user côté serveur.

~backup_user/.ssh/authorized_keys contenu côté serveur (avec quelques restrictions de sécurité supplémentaires):

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="scp -v -r -d -t ~/CONTENT" ssh-rsa AAAAMYRSAKEY...

Créez un lien dans ~ backup_user/qui renvoie au répertoire où le contenu doit être accessible.

$ ln -s /path/to/directory/with/accessible/content ~backup_user/CONTENT

Maintenant, du côté client, la commande suivante devrait fonctionner:

scp -v  -r  -P 2222 -i .ssh/id_rsa_key_file path/to/data backup_user@SERVER:~/CONTENT

Que fait cette commande:

  • Il affiche des informations détaillées ( optionnel: vous pouvez supprimer le -v à partir de la commande et du fichier de clés autorisées)
  • Il copie récursivement le contenu du chemin/vers/données. ( optionnel: vous pouvez supprimer -r à partir de la commande et du fichier authorized_keys si vous ne voulez pas faire de copie récursive)
  • Il utilise le port 2222 pour se connecter au serveur ( optionnel: vous pouvez supprimer -P 2222 de la commande)
  • Il utilise un fichier d'identité pour automatiser la connexion ( optionnel: vous pouvez supprimer -i .ssh/id_rsa_key_file
  • Le contenu de path/to/data sera copié dans /path/to/directory/with/accessible/content/

Pour faire une copie d'un fichier (ou plusieurs) du serveur vers le client, vous devez créer un script Shell qui gère cela comme décrit ici

39
Action Jack

Je suis un peu en retard à la fête, mais je vous suggère de jeter un œil à la directive ForceCommand d'OpenSSH.

Subsystem sftp internal-sftp

Match group sftponly
         ForceCommand internal-sftp

Certes, il s'agit de SFTP et non de SCP, mais il atteint le même objectif, de manière plus sécurisée qu'avec un Shell restreint. De plus, vous pouvez chrooter l'utilisateur si vous le souhaitez.

31
François Feugeas

Je recommanderais d'utiliser scponly.

Il s'agit d'un shell restreint qui permet aux utilisateurs de faire exactement ce que cela ressemble, des fichiers SCP au serveur, mais pas de se connecter. Les informations et les téléchargements de code source pour le logiciel sont disponibles ici et le pré- les packages RPM compilés sont disponibles via EPEL YUM Repositories .

Une fois installé, vous devrez configurer chaque compte d'utilisateur, auquel vous souhaitez restreindre l'accès, pour utiliser le shell restreint nouvellement installé. Vous pouvez le faire manuellement via/etc/passwd ou utiliser la commande suivante: usermod -s /usr/bin/scponly USERNAME

7
syn-

J'utilise MySecureShell pour ce faire. Vous pouvez également configurer d'autres restrictions.

https://github.com/mysecureshell/mysecureshell

Limite les connexions à SFTP/SCP uniquement. Pas d'accès Shell.

6
J.Zimmerman

Très tard pour la fête, mais définissez simplement le shell de l'utilisateur git sur/usr/bin/git-Shell. Il s'agit d'un shell restreint qui ne permet pas de connexion interactive. Vous pouvez toujours contacter l'utilisateur avec 'su -s/bin/bash git' ou quel que soit votre nom d'utilisateur git.

3
Ian Ellis

Nous utilisons un pseudo Shell appelé scponly sur nos serveurs ftp sécurisés pour les utilisateurs que nous voulons seulement pouvoir scper des fichiers mais pas nous connecter.

2
Zypher

J'ai trouvé une bonne façon d'utiliser la fonction command = "..." du fichier authorized_keys. (Suggéré par cette page )

La commande que vous exécutez serait celle qui teste les arguments commençant 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 nouvel utilisateur, et à ce que la clé ne donne pas de shell (ok, facilement)

2
Phil

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

Vous voudrez peut-être exécuter l'un d'entre eux dans un chroot ou dans un autre environnement restreint (par exemple nsjail sous Linux), pour désactiver l'accès au réseau et pour un contrôle plus facile (sur liste blanche) des répertoires qui peuvent être lus et/ou écrit.

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

1
pts

Ce n'est pas la solution la plus gracieuse, mais vous pouvez lancer quelque chose comme ça dans les utilisateurs .bashrc

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

J'ai trouvé que les utilisateurs SCP obtiennent un TERM de "stupide", et d'autres obtiendront généralement vt100.

J'imagine que l'utilisateur pourrait probablement explorer un nouveau .bashrc, ce qui en fait pas la meilleure solution, mais pour une solution rapide et sale, cela fonctionnera

0
jizaymes