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


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


58
2017-11-12 02:44


origine


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:


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

RHEL / CentOS 5.2 n'incluant pas de paquet pour rssh, vous pouvez chercher 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 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 éditer /etc/rssh.conf configurer le shell rssh - en particulier le commentaire allowscp ligne pour permettre l’accès SCP à tous les utilisateurs rssh.

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


41
2017-11-12 03:14



c'est génial - je cherche quelque chose comme ça depuis un moment aussi - warren
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 avec ... - wzzrd
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


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 / allowed_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.

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

Voici un exemple de travail de cela, pour un utilisateur nommé backup_user sur le 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 mène au répertoire où le contenu doit ê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 (optionnel: vous pouvez enlever le -v de la commande et du fichier allowed_keys)
  • Il copie de manière récursive le contenu du chemin / vers / des données. (optionnel: vous pouvez enlever -r depuis la commande et le fichier allowed_keys si vous ne voulez pas faire de copie récursive)
  • Il utilise le port 2222 pour se connecter au serveur (optionnel: vous pouvez enlever -P 2222 de la commande)
  • Il utilise un fichier d’identité pour automatiser la connexion (optionnel: vous pouvez enlever -i .ssh/id_rsa_key_file
  • Le contenu de path/to/data sera copié dans /path/to/directory/with/accessible/content/

Pour copier un fichier (ou plusieurs) du serveur sur le client, vous devez créer un script shell qui gère ce fichier. comme décrit ici


35
2017-11-27 17:52



Qu'est-ce qui empêche l'utilisateur de parcourir son fichier authorised_keys? Peut-il être restreint pour ne pas appartenir à l'utilisateur lui-même? - Dan
@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 ~/.ssh/rc lecture seulement. 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 recommande contre cette méthode (command="..."). - pts


Je suis un peu en retard à la fête, mais je vous suggère de jeter un coup d'œil au ForceCommand directive 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.


29
2017-11-12 10:56



ajouter le chrootDirectory %h et AllowTcpForwarding no  après la section de match pour forcer les utilisateurs à chrooter jusqu’à leur domicile. veuillez noter que la correspondance doit (doit!) être la dernière section de la configuration ssh et que les options qui suivent sont des options réservées aux utilisateurs correspondants. - higuita
ForceCommand internal-sftp -u 0077 -d /uploaddir peut 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 umask doit être mis dans le ForceCommand, pas dans le Subsystem directive, si vous voulez qu'ils fonctionnent. - Marcin
Un article plus long expliquant ceci est disponible sur debian-administration.org/article/590/… - koppor


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 récemment installé. Vous pouvez le faire manuellement via / etc / passwd ou utiliser la commande suivante: usermod -s /usr/bin/scponly USERNAME


5
2018-01-25 20:30



Je seconde ceci. scponly est CONÇU exactement à cette fin. - UtahJarhead
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


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

https://github.com/mysecureshell/mysecureshell

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


5
2017-11-12 07:21





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 contacter l'utilisateur avec 'su -s / bin / bash git' ou quel que soit votre nom d'utilisateur git.


2
2017-10-01 19:54





Nous utilisons un shell psudo appelé scponly sur nos serveurs FTP sécurisés pour les utilisateurs, nous souhaitons uniquement pouvoir numériser des fichiers, mais pas nous connecter.


1
2017-11-27 18:05





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

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

Voici le fichier allowed_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)


1
2017-10-13 03:13



C'est assez cool - mais j'imagine que cela peut être subverti en émettant une commande qui effectue 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 (auquel cas cela résoudrait les problèmes) - Phil
Aussi vous devriez faire ~/.ssh/authorized_keys, ~/.bashrc (et tout ce que Bash exécute) et ~/.ssh/rc lecture 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 recommande contre cette méthode (command="..."). - pts
@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, il vaut mieux utiliser quelque chose de dédié, comme rssh. Wow, je viens de me rendre compte que c'est ma réponse! C'est vieux! Haha! - Phil
N'oublie pas ça scp -S ... et rsync -e ... permet à 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


Ce n'est pas la solution la plus gracieuse, mais vous pouvez jeter quelque chose comme ceci 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 en fait une solution pas la meilleure, mais pour une solution rapide et sale, cela fonctionnera


0
2018-02-07 17:17



Je déconseille fortement cette solution proposée, il est trop facile pour un utilisateur malveillant de se soustraire (par exemple en téléchargeant un autre ~/.bashrc). C'est aussi floconneux en ce sens que peut-être de nouvelles versions d'OpenSSH définiraient la TERM variable différemment, ou certains paramètres de configuration sshd peuvent affecter TERM. - pts


Changer le shell de connexion de l’utilisateur en quelque chose de restrictif, ce qui permet à l’utilisateur de ne lancer que scp, sftp-server et rsync et vérifie également que les arguments non sécurisés ne sont pas autorisés (par exemple, scp -S ... et rsync -e ... sont dangereux, 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’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 faciliter le contrôle (sur la liste blanche) des répertoires pouvant être lus et / ou écrits.

Je ne recommande pas d'utiliser command="..." dans ~/.ssh/authorized_keys, car sans protection supplémentaire prudente (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 ou ~/.bashrc, et peut donc inclure et exécuter des commandes arbitraires.


0
2017-12-07 13:27