Salut la communauté.
Je souhaiterais restreindre au maximum les privilèges d'un user côté serveur : en gros il ne doit que pouvoir recevoir des tunnels de données à acheminé vers 127.0.0.1:port comme dans ce tuto. Je souhaiterais qu'il ne puisse pas faire un "ls /" ni autre commande, ni effectuer de montage sftp/sshfs.
distro : xubuntu
Merci d'avance pour votre aide :)
# Quelques questions
Posté par GG (site web personnel) . Évalué à 2.
Bonjour,
pourquoi avoir choisi Xubuntu? pour un serveur, il n'y a généralement pas besoin d'un "bureau".
Est ce que l'utilisateur à la possibilité d'accéder physiquement à la machine?
Ensuite, je ne vois pas le lien entre ta demande et le tutoriel en question.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Quelques questions
Posté par EauFroide . Évalué à 1. Dernière modification le 24 septembre 2016 à 14:32.
Disposer d'une interface a quelques avantages, sans oublier que le serveur sert aussi de télé :) Xubuntu intègre aussi beaucoup de drivers très utile pour les ordinosaures, drivers que Debian n'intègre pas par défaut :)
Non, c'est un user dédié au proxy que je souhaite ré-utiliser sur X machines appartenant a X personnes tout en le protégeant contre une compromission d'un des clients.
c'est juste pour montrer le contexte (je souhaite sécuriser deux users: un qui est dédié exclusivement a tunneler des connexions de clients vers le owncloud (uniquement vers 127.0.0.1), et un dédié exclusivement au montage SSHFS comme ici pour ranger les fichiers de mes webservices sur mon raid :) )
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
# chroot
Posté par nono14 (site web personnel) . Évalué à 2.
Tout est dans le titre
Tutos à la pelle sur le web.
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
[^] # Re: chroot
Posté par EauFroide . Évalué à 1.
Oui j'ai déjà tenté d'en suivre plusieurs mais je me tape un "packet_write_wait: Connection to 192.168.1.42 port 22: Broken pipe" à chaque fois
Pour le moment j'ai
sudo su
cd /home/userNeedChroot/
On crée les dossiers des requis
mkdir bin dev lib lib/i386-linux-gnu lib/x86_64-linux-gnu lib64
On copie Bash
cp /bin/bash /home/userNeedChroot/bin/
Lister les requis
ldd /bin/bash
exemple
└─ # ▶ ldd /bin/bash
linux-vdso.so.1 => (0x00007ffc33cf1000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fc810b11000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc81090d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc810543000)
/lib64/ld-linux-x86-64.so.2 (0x000055647a454000)
Trouver les requis
find /lib/ -name libdl.so.2
Copier les requis
cp /lib/i386-linux-gnu/libtinfo.so.* ./lib/i386-linux-gnu/
cp /lib/x86_64-linux-gnu/libtinfo.so.* ./lib/x86_64-linux-gnu/
cp /lib/i386-linux-gnu/libdl.so.* ./lib/i386-linux-gnu/
cp /lib/x86_64-linux-gnu/libdl.so.* ./lib/x86_64-linux-gnu/
cp /lib/i386-linux-gnu/libc.so.* ./lib/i386-linux-gnu/
cp /lib/x86_64-linux-gnu/libc.so.* ./lib/x86_64-linux-gnu/
cp /lib64/ld-linux-x86-64.so.* ./lib64/
Note : pas moyen de trouver linux-vdso.so.1
Accorder les bons droits et propriétaires
chown userNeedChroot:root -R ./*
chmod 770 -R ./*
Ajouter dans /etc/ssh/ sshd_config
Match user userDedieSSH
PasswordAuthentication no
ChrootDirectory /home/%u
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
# /bin/false
Posté par wismerhill . Évalué à 5.
Si le but est uniquement de pouvoir établir des tunnels (avec -L ou -R) alors il n'y a même pas besoin de pouvoir exécuter des commandes locales, tu peux donc mettre le shell de l'utilisateur à /bin/false et exécuter ssh avec l'option -N.
Si tu veux pouvoir exécuter quand même quelques commandes, il existe des shell restreints que tu peux configurer pour n'accepter que quelques commandes, éventuellement avec seulement quelques options.
[^] # Re: /bin/false
Posté par EauFroide . Évalué à 1. Dernière modification le 24 septembre 2016 à 15:51.
Wow @wismerhill ça fonctionne exactement comme je le souhaitais et sans faire des tonnes de modifications obscures !
Merci merci merci !
la commande :
sudo usermod -s /bin/false jeSuisUnUser
PS: tu sais si on peut aller jusqu'à restreindre les tunnels vers une seule IP (127.0.0.1 dans le cas présent)?
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: /bin/false
Posté par EauFroide . Évalué à 1. Dernière modification le 24 septembre 2016 à 16:00.
Note : comment je fais pour l'annuler? (je pense (need verification) que cette méthode bloque l'ajout de nouvelle clés et doit donc être remis à la valeur par défaut avant d'ajouter un client)
usermod -s /bin/login jeSuisUnUser renvoie "-login : fonctionnement impossible sans être réellement le superutilisateur" lors de la tentative de connexion via ssh
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: /bin/false
Posté par wismerhill . Évalué à 2.
Ça n'a rien à voir, les clés doivent simplement être ajoutées dans le fichier ~/.ssh/authorized_keys (mais si tu comptais sur ton utilisateur pour pouvoir les ajouter lui-même, effectivement il ne sait plus le faire).
[^] # Re: /bin/false
Posté par EauFroide . Évalué à 1.
Oui je parlais de l'export de clés des clients avec la commande
ssh-copy-id -i ~/.ssh/id_ed25519 jeSuisUnUser@adresseServerSSH
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: /bin/false
Posté par wismerhill . Évalué à 3.
Dans la configuration d'openssh server, je vois le paramètre AllowTcpForwarding dont l'option local devrait faire ce que tu veux (à tester, je ne suis pas sur d'avoir bien compris).
Il y a aussi le paramètre PermitOpen qui semble intéressant.
Tu peux combiner ça avec le paramètre Match pour ne mettre ces options que pour un utilisateur en particulier (et peut-être ajouter encore d'autres restrictions).
[^] # Re: /bin/false
Posté par EauFroide . Évalué à 1.
"AllowTcpForwarding local" semble valide mais ne m'empêche pas de contacter un autre serveur.
Par contre "PermitOpen 127.0.0.1:*" fait se que je demande
Si tu sais juste me renseigner comment revenir en arrière après mon "sudo usermod -s /bin/false jeSuisUnUser", j'en aurai terminé avec cet user grâce tes infos gros merci @wismerhill :)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: /bin/false
Posté par wismerhill . Évalué à 3.
Tu te connecte en root (ou un user pouvant exécuter sudo) et tu remet un autre shell à ton user.
Ensuite, tu peux laisser un shell normal au user pour permettre les connexion locales, tu peux utiliser le paramètre ForceCommand d'openssh server avec un shell limité comme rush ou rssh (j'ai personnellement eu de bon résultats avec rush) que tu configure pour autoriser les quelques commandes souhaitées (comme celles exécutées par ssh-copy-id).
Attention, si configure ton serveur ssh comme ça, fais bien attention à ce que ce ForceCommand ne soit actif que pour l'utilisateur souhaité, sinon tu va bloquer tout le monde.
[^] # Re: /bin/false
Posté par EauFroide . Évalué à 1.
ce rush la? J'avais déjà tenté une fois avec rssh mais ça avait mal terminé ^ ^
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: /bin/false
Posté par wismerhill . Évalué à 3.
Non, celui-là
http://puszcza.gnu.org.ua/software/rush/
il y a un paquet debian du même nom, donc probablement pour ubuntu aussi.
À l'époque où j'en avais eu l'usage je l'avais trouvé plus pratique que rssh (mais je ne me souviens plus pourquoi).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.