Article mis à jour le 26/03/2016
INDEX
Configuration du deamon OpenSSH pour chrooter certains users
sudo nano /etc/ssh/sshd_config
Sur une instance EC2, autoriser le login par password :
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication yes
Ne pas utiliser le serveur SFTP d’OpenSSH :
#Subsystem sftp /usr/lib/openssh/sftp-server
Utiliser le serveur sftp par défaut, et chrooter les utilisateurs du groupe chrootedusers dans le dossier /var/chroot/%u (où %u est le login) :
Subsystem sftp internal-sftp
Match Group chrootedusers
ChrootDirectory /var/chroot/%u
#ForceCommand internal-sftp
X11Forwarding no
AllowTcpForwarding no
Au passage on peut désactiver la vérification du DNS au login, si votre ISP n’a pas associé bien le reverse DNS à votre IP (coucou Completel tu te reconnais ?) :
UseDNS no
Redémarrer le service SSH :
sudo service ssh restart
ssh stop/waiting
ssh start/running, process 11670
Créer le groupe chrootedusers et configurer le dossier de jail
sudo groupadd chrootedusers
Configurer le dossier de chroot
/$ cd /var/
/var$ sudo mkdir chroot
/var$ cd chroot/
Créer les répertoires des exécutables, puis copier bash et rsync :
/var/chroot$ sudo mkdir {bin,lib,lib64}
/var/chroot$ sudo cp /bin/bash bin/
/var/chroot$ sudo cp /usr/bin/rsync bin/
/var/chroot$ sudo ldd /bin/bash
linux-vdso.so.1 => (0x00007fff9f7fe000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f36bf793000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f36bf58f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f36bf1c8000)
/lib64/ld-linux-x86-64.so.2 (0x00007f36bf9c6000)
/var/chroot$ sudo mkdir lib/x86_64-linux-gnu
/var/chroot$ sudo cp -p /lib/x86_64-linux-gnu/libtinfo.so.5 lib/x86_64-linux-gnu/libtinfo.so.5
etc…
La même chose pour rsync
/var/chroot$ sudo ldd /usr/bin/rsync
linux-vdso.so.1 => (0x00007fffc6b9d000)
libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f7586286000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f758606d000)
libpopt.so.0 => /lib/x86_64-linux-gnu/libpopt.so.0 (0x00007f7585e60000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7585a9a000)
libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007f7585895000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7586498000)
/var/chroot$ sudo cp -p /lib/x86_64-linux-gnu/libacl.so.1 lib/x86_64-linux-gnu/libacl.so.1
etc…
Pensez à rire un bon coup en copiant la librairie « saucisse » 😀
Un script qui copie les libs des binaries automatiquement !
U NEED DIS: https://www.metashock.de/2012/11/export-binary-with-lib-dependencies/
Modifier un utilisateur existant
/var/chroot$ sudo nano /etc/passwd
L’utilisateur importé ou précédemment créé devrait ressembler à :
italic_174:x:1031:1031::/home/italic_174:/bin/bash
Mettre / en homedir correspond en fait à /var/chroot/%u définit dans la config d’OpenSSH :
italic_174:x:1032:1032::/:/bin/bash
Penser à lui créer son répertoire perso dans le dossier de jail :
/var/chroot$ sudo mkdir italic_174
Et à l’ajouter dans le groupe des utilisateurs chrootés :
/var/chroot$ sudo usermod -a -G chrootedusers italic_174
Surtout, penser à lui copier les exécutables, étant donné que, chrooté dans /var/chroot/%u l’utilisateur n’aura pas accès à /bin/bash ni même /var/chroot/bin/bash etc.
/var/chroot$ sudo cp -Rr bin/ lib* italic_174/
Configuration des fichiers par défaut dans le homedir et création d’un nouvel utilisateur
Pour éviter de se cogner tous les fichiers à copier à chaque fois, on utilise le skeleton lors de la création d’un utilisateur.
/var/chroot$ sudo mkdir skel
/var/chroot$ sudo mv bin/ lib* skel/
L’utilisation dans la commande de création d’un utilisateur :
sudo useradd -U -G chrootedusers -d /var/chroot/<username> -m -k /var/chroot/skel -s /bin/bash <username>
Explications :
-U: créer un groupe du même nom que l’utilisateur, et lui affecte-G: ajoute l’utilisateur dans le groupe spécifié-d: configure la création du homedir dans le dossier spécifié-m: demande de créer le homedir-k: indique quel « squelette » utiliser pour créer le homedir-s: le shell voulu pour l’utilisateur,/bin/bashsi on veut du rsync over SSH, sinon/sbin/nologin
Le problème est que le homedir spécifié sera /var/chroot/<username>, alors qu’on a besoin de /. Du coup…
sudo usermod -d / test1
Résultat :
/var/chroot$ id test1 uid=1106(test1) gid=1106(test1) groups=1106(test1),1105(chrootedusers)
Et :
sudo nano /var/etc/passwd
test1:x:1106:1106::/var/chroot/test1:/bin/bash
Petit problème en testant la connexion :
➜ ~ slogin test1@debugg.in test1@debugg.in's password: Write failed: Broken pipe
Pourquoi ?
tail -f /var/log/auth.log May 21 00:15:58 ip-172-31-29-241 systemd-logind[1047]: New session 69 of user test1. May 21 00:15:59 ip-172-31-29-241 sshd[18637]: fatal: bad ownership or modes for chroot directory "/var/chroot/test1" May 21 00:15:59 ip-172-31-29-241 sshd[18584]: pam_unix(sshd:session): session closed for user test1
Ah ben oui…
/var/chroot$ sudo chown root:root test1
On réessaie :
➜ ~ ssh test1@debugg.in test1@debugg.in's password: Welcome to Ubuntu 14.04 LTS (GNU/Linux 3.13.0-24-generic x86_64)
Ça va mieux 🙂
Test de la connexion en SSH
➜ ~ slogin italic_174@debugg.in italic_174@debugg.in's password: Welcome to Ubuntu 14.04 LTS (GNU/Linux 3.13.0-24-generic x86_64) Last login: Tue May 20 21:18:34 2014 from 46.218.202.194
Vérifions tout d’abord que l’on est bien chrooté :
-bash-4.3$ pwd /
Ensuite, que l’on a accès à rsync mais pas aux autres commandes :
-bash-4.3$ cp -bash: cp: command not found -bash-4.3$ rsync rsync version 3.1.0 protocol version 31
Restriction de la connexion par mot de passe par IP
sudo nano /etc/ssh/sshd_config
ChallengeResponseAuthentication no
PasswordAuthentication no
Et ajouter en fin de fichier
Match Address XXX.XXX.XXX.XXX
PasswordAuthentication yes
Récupération d’anciens utilisateurs
S’assurer que l’utilisateur est bien dans le groupe chrootedusers :
getent group chrootedusers
Si tel n’était pas le cas :
sudo usermod -G chrootedusers leclaireur_227
Ne pas oublier pour prendre en compte ce changement :
sudo update-passwd
Test de transfert en SFTP
Pour contrôler ce qui se passe durant l’identification :
tail -f /var/log/auth.log
May 20 20:27:39 ip-172-31-29-241 sshd[12077]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key May 20 20:27:39 ip-172-31-29-241 sshd[12077]: Accepted password for italic_174 from 46.218.202.201 port 59818 ssh2 May 20 20:27:39 ip-172-31-29-241 sshd[12077]: pam_unix(sshd:session): session opened for user italic_174 by (uid=0) May 20 20:27:39 ip-172-31-29-241 systemd-logind[1047]: New session 14 of user italic_174.
WTF : Could not load host key: /etc/ssh/ssh_host_ed25519_key
D’après mes recherches, c’est un bug dans OpenSSH. Pas bien méchant mais quand même un bug. Bravo les gars. Ça se corrige comme ça :
/var/chroot$ sudo ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ed25519_key -N '' Generating public/private ecdsa key pair. Your identification has been saved in /etc/ssh/ssh_host_ed25519_key. Your public key has been saved in /etc/ssh/ssh_host_ed25519_key.pub. The key fingerprint is: 9c:9f:88:53:ca:2d:26:6f:7f:45:95:0f:fd:8a:ec:59 root@ip-172-31-29-241 The key's randomart image is: +--[ECDSA 256]---+ | o | | + .| | . o.| | . . . o| | S o . . | | . = o .+ E | | . B o oo o | | +.o . o | | ..... | +-----------------+
Anyway, nous sommes loggés.
Problème :
Ce qui est somme toute logique, étant donné que /var/chroot/italic_174 appartient à root.
Il faut donc créer un (ou plusieurs) sous-dossiers appartenant à l’utilisateur :
/var/chroot$ cd italic_174/
/var/chroot/italic_174$ sudo mkdir www
/var/chroot/italic_174$ sudo chown -R italic_174:italic_174 www/
Et voilà, envoyé c’est pesé :
Je sais, dans la ligne de commande le dossier s’appelle www et sur le screenshot il s’appelle master. La flemme.
Test de transfert via rsync
En ligne de commande, avec un tunnel SSH :
➜ ~ rsync -azvcu -e "ssh" /Users/germain/Sites/_repositories/7lieues/mailing.e/www/maquette/jpg italic_174@debugg.in:/www/ italic_174@debugg.in's password: building file list ... done sent 457 bytes received 20 bytes 136.29 bytes/sec total size is 9418305 speedup is 19744.87
Avec l’excellent DropSync :
NB : les copies d’écrans suivantes sont réalisées dans une version beta privée de DropSync 3 mais le principe reste le même pour DropSync 2.
Choisir « Remote login »
Entrez les paramètres normalement, sans spécifier de path.
Un test de transfert left to right devrait logiquement annoncer le transfert de tout www :
Sauf bien sûr si vous aviez déjà effectué le transfert en ligne de commande avant :
Conclusion
Et bah c’était pas simple, cette histoire.
