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


62

Existe-t-il un moyen de configurer un utilisateur sur une machine Linux (Centos 5.2 dans ce cas) de sorte qu'il puisse utiliser scp pour récupérer des fichiers, mais ne puisse pas se connecter au serveur à l'aide de SSH?


J'ai essayé de définir le shell de connexion sur / bin / false, mais cela empêche simplement le fonctionnement de scp.
DrStalker

Réponses:


45

Le shell rssh ( http://pizzashack.org/rssh/ ) est conçu précisément à cette fin.

RHEL / CentOS 5.2 n'incluant pas de package pour rssh, vous pouvez rechercher ici un fichier RPM: http://dag.wieers.com/rpm/packages/rssh/

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

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

..ou changer le shell pour un existant comme ceci:

chsh -s /usr/bin/rssh scpuser1

..et modifier /etc/rssh.confpour configurer le shell rssh - en particulier la allowscpligne de suppression du commentaire pour permettre l'accès SCP à tous les utilisateurs rssh.

(Vous pouvez également utiliser chroot pour que les utilisateurs restent dans leur maison, mais c'est une autre histoire.)


c'est génial - je cherche quelque chose comme ça depuis quelque temps aussi
warren

6
L’idée derrière rssh est bien, mais iirc rssh n’était pas un miracle de la sécurité en termes de programmation. Un simple google sur 'exploit rssh' donne plus de résultats que je ne suis à l'aise ...
wzzrd

7
scponly est plus ou moins la même chose aussi et apparemment moins sujet aux exploits: sublimation.org/scponly/wiki/index.php/Main_Page
François Feugeas

semble avoir bougé à github. Le lien de sublimation est mort. github.com/scponly/scponly/wiki
spazm

38

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 / registered_keys, par exemple

no-port-forwarding, no-pty, commande = "cible source scp" ssh-dss ...

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

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

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é distante. Cela vous donne une idée de ce que vous devez mettre dans allowed_keys.

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

Voici un exemple de travail pour un utilisateur nommé backup_usercô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 devrait être accessible.

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

Maintenant, 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 ( facultatif : vous pouvez supprimer le -vfichier à la fois de la commande et du fichier allowed_keys)
  • Il copie de manière récursive le contenu du chemin / vers / des données. ( facultatif : vous pouvez supprimer -rà la fois les fichiers de la commande et les Commande_ authorisés si vous ne souhaitez pas faire de copie récursive)
  • Il utilise le port 2222 pour se connecter au serveur ( facultatif : vous pouvez supprimer -P 2222de la commande)
  • Il utilise un fichier d’identité pour automatiser la connexion ( facultatif : vous pouvez supprimer-i .ssh/id_rsa_key_file
  • Le contenu de path/to/datasera copié dans/path/to/directory/with/accessible/content/

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


1
Qu'est-ce qui empêche l'utilisateur de lire son fichier authorised_keys? Peut-il être restreint pour ne pas appartenir à l'utilisateur lui-même?
Dan

1
@Dan - Il devrait être possible de définir des autorisations en lecture seule sur le fichier allowed_keys, c'est-à-dire. chmod 400 ~/.ssh/authorized_keys.
Roger Dueck

Aussi, vous devriez faire ~/.bashrc(et tout ce que Bash exécute) et en ~/.ssh/rclecture seule. Mais si l'utilisateur malveillant a accès à rsync ou à sftp, il peut toujours supprimer ~/.bashrcet en télécharger un nouveau. Comme il est difficile de protéger, je déconseille cette méthode ( command="...").
Pts

31

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

Subsystem sftp internal-sftp

Match group sftponly
         ForceCommand internal-sftp

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


2
ajoutez le chrootDirectory %het AllowTcpForwarding no après la section de match pour forcer les utilisateurs à chrooter à leur domicile. veuillez noter que la correspondance doit (doit!) être la dernière section de la configuration ssh et que les options qui suivent ne sont que des options
réservées

4
ForceCommand internal-sftp -u 0077 -d /uploaddirpeut le renforcer, en forçant un umask sur un répertoire de téléchargement. En conjonction avec «ChrootDirectory», il crée un environnement de téléchargement isolé et très contrôlé. Note bonus: le répertoire par défaut et le masque umask doivent être définis ForceCommanddans la Subsystemdirective, et non dans la directive, si vous souhaitez qu'ils fonctionnent.
Marcin

Un article plus long expliquant ceci est disponible sur debian-administration.org/article/590/…
koppor

7

Je recommanderais d'utiliser scponly.

C'est un shell restreint qui permet aux utilisateurs de faire exactement ce que cela ressemble, de fichiers SCP au serveur, mais pas de se connecter. Les téléchargements d'informations et de code source du logiciel sont disponibles ici et les packages RPM précompilés sont disponibles via le Dépôts EPEL YUM .

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


Je seconde ceci. scponlyest CONÇU exactement à cette fin.
UtahJarhead

1
scponly semble être mort. debian semble l'avoir supprimé: packages.debian.org/search?keywords=scponly et le code sur github est mort aussi. Discussion de suivi: serverfault.com/questions/726519/…
koppor


3

Très tard pour la fête, mais définissez simplement le shell de l'utilisateur git sur / usr / bin / git-shell. C'est un shell restreint qui n'autorise pas la connexion interactive. Vous pouvez toujours utiliser l'utilisateur 'su -s / bin / bash git' ou quel que soit votre nom d'utilisateur git.


2

Nous utilisons un psudo shell appelé scponly sur nos serveurs ftp sécurisés pour les utilisateurs pour lesquels nous souhaitons uniquement pouvoir numériser des fichiers sans les connecter.


2

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

La commande que vous exécuteriez serait celle qui testerait les arguments commençant par scp (et rsync).

Voici le fichier authorised_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

J'imagine que vous auriez probablement encore besoin de protéger le fichier employee_keys de l'utilisateur, mais mon objectif était de disposer d'une clé sans mot de passe que je pourrais utiliser pour les sauvegardes, sans avoir à créer un nouvel utilisateur et à ne pas donner la clé à un shell. (ok, facilement)


3
C'est assez cool - mais j'imagine que cela peut être subverti en émettant une commande qui fait un scp, puis lance un script par la suite!
Davidgo

@davidgo prepending $ SSH_ORIGINAL_COMMAND avec exec pourrait remédier à cette vulnérabilité, en supposant que scp et rsync n'essaient pas eux-mêmes d'exécuter plusieurs programmes (dans ce cas, cela romprait cela)
Phil

Aussi , vous devriez faire ~/.ssh/authorized_keys, ~/.bashrc(et tout autre Bash exécute) et en ~/.ssh/rclecture seule pour l'utilisateur. Mais si l'utilisateur malveillant a accès à rsync ou à sftp, il peut toujours supprimer ~/.bashrcet en télécharger un nouveau. Comme il est difficile de protéger, je déconseille cette méthode ( command="...").
Pts

1
@pts vous pouvez faire en sorte que les fichiers rc et les répertoires qui les contiennent soient la propriété de quelqu'un d'autre que l'utilisateur (personne?) et ne puissent être écrits par l'utilisateur. Mais à ce stade, vous feriez mieux d'utiliser quelque chose de dédié, comme rssh. Wow, je viens de réaliser que c'est ma réponse! C'est vieux! Haha!
Phil

N'oubliez pas que scp -S ... et rsync -e ... permettent à l'utilisateur d'exécuter des commandes arbitraires. Donc, vous devriez vérifier les arguments dans $ SSH_ORIGINAL_COMMAND avant de l'exécuter. Plus d'infos ici: exploit-db.com/exploits/24795
pts

1

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

Vous voudrez peut-être exécuter l'un de ces éléments dans un chroot ou dans un autre environnement restreint (par exemple, nsjail sous Linux), pour désactiver l'accès réseau et pour contrôler plus facilement (sur liste blanche) les répertoires pouvant être lus et / ou écrits.

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


0

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

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

J'ai constaté que les utilisateurs de SCP obtenaient un TERM de "stupide", et que les autres recevaient généralement vt100.

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


1
Je recommande fortement contre cette solution proposée, il est trop facile pour un utilisateur malveillant de le contourner (par exemple en en téléchargeant un autre ~/.bashrc). C'est également flasque en ce sens que les nouvelles versions d'OpenSSH définiraient peut-être la TERMvariable différemment, ou que certains paramètres de configuration de sshd pourraient l'affecter TERM.
Pts

1
Ehhh ... ssh -o SetEnv TERM=dumb yourserver bash??
ulidtko le
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.