Forum Linux.debian/ubuntu Cloisonner utilisateur ssh debian 8 (Résolu)

Posté par hakhak91 le 11 mars 2016 à 16:42. Licence CC By‑SA.

Étiquettes :

mar.

2016

Bonjour,

Nous sommes actuellement sur une Debian 8. Nous souhaitons cloisonné un user pour une connexion ssh.
Bizarrement en appliquant les mêmes configurations que la debian 7 sa ne fonctionne pas.

Les messages que nous avons dans les logs /var/log/auth.log concernent le chroot

fatal: bad ownership or modes for chroot directory "/var/www/mon-user"

lors de l'activation de la configuration dans le fichier /etc/ssh/sshd_config:

Match User knp_prod
       PasswordAuthentication yes
       ChrootDirectory /var/www/mon-user
       ForceCommand internal-sftp
       ForceCommand internal-ssh
       X11Forwarding no
       AllowTCPForwarding no

En effet il y a un changement dans l'activation du chroot sur debian 8 il est impératif que root soit propriétaire c'est le cas
Par la suite il est impossible de se connecter en ssh et nous avons pas de message pertinent pour debuger.
L'authentification fonctionne mais "mon-user" est éjecté.
Connexion en ssh -v:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Offering DSA public key: /root/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Next authentication method: password
knp_prod@172.31.1.30's password:
debug1: Authentication succeeded (password).
Authenticated to 172.x.x.x ([172.x.x.x]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
Write failed: Broken pipe
moi:38-root-10.x.x.x-~# ssh -v mon-user@172.x.x.x

Votre aide serait la bienvenue

# more verbose

Posté par nono14 (site web personnel) le 11 mars 2016 à 17:22. Évalué à 3.

plusieurs "v" ?

Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités

[^] # Re: more verbose

Posté par hakhak91 le 14 mars 2016 à 10:43. Évalué à 1.

pas compris désolé

[^] # Re: more verbose

Posté par jihele le 14 mars 2016 à 17:09. Évalué à 2.

man ssh

Multiple -v options increase the verbosity.

Tu peux utiliser -vvv pour avoir plus de messages de debug.

[^] # Re: more verbose

Posté par hakhak91 le 14 mars 2016 à 17:59. Évalué à 1.

test@x.x.x.x's password:

debug2: we sent a password packet, wait for reply

debug1: Authentication succeeded (password).

Authenticated to x.x.x.x ([x.x.x.x]:22).

debug1: channel 0: new [client-session]

debug3: ssh_session2_open: channel_new: 0

debug2: channel 0: send open

debug1: Requesting no-more-sessions@openssh.com

debug1: Entering interactive session.

debug2: callback start

debug2: fd 3 setting TCP_NODELAY

debug3: packet_set_tos: set IP_TOS 0x10

debug2: client_session2_setup: id 0

debug2: channel 0: request pty-req confirm 1

debug1: Sending environment.

debug3: Ignored env TERM

debug3: Ignored env SHELL

debug3: Ignored env SSH_CLIENT

debug3: Ignored env SSH_TTY

debug3: Ignored env USER

debug3: Ignored env MAIL

debug3: Ignored env PATH

debug3: Ignored env PWD

debug3: Ignored env EDITOR

debug1: Sending env LANG = fr_FR.UTF-8

debug2: channel 0: request env confirm 0

debug3: Ignored env SHLVL

debug3: Ignored env HOME

debug3: Ignored env LOGNAME

debug3: Ignored env SSH_CONNECTION

debug3: Ignored env HISTTIMEFORMAT

debug3: Ignored env _

debug2: channel 0: request shell confirm 1

debug2: callback done

debug2: channel 0: open confirm rwindow 0 rmax 32768

debug2: channel_input_status_confirm: type 99 id 0

debug2: PTY allocation request accepted on channel 0

debug2: channel 0: rcvd adjust 2097152

debug2: channel_input_status_confirm: type 99 id 0

debug2: shell request accepted on channel 0



The programs included with the Debian GNU/Linux system are free software;

the exact distribution terms for each program are described in the

individual files in /usr/share/doc/*/copyright.



Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent

permitted by applicable law.

Last login: Mon Mar 14 17:54:53 2016 from 10.10.10.100

Could not chdir to home directory /var/www/test/: No such file or directory

/var/www/test/bin/bash: No such file or directory

debug1: client_input_channel_req: channel 0 rtype exit-status reply 0

debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0

debug2: channel 0: rcvd eow

debug2: channel 0: close_read

debug2: channel 0: input open -> closed

debug2: channel 0: rcvd eof

debug2: channel 0: output open -> drain

debug2: channel 0: obuf empty

debug2: channel 0: close_write

debug2: channel 0: output drain -> closed

debug2: channel 0: rcvd close

debug3: channel 0: will not send data after close

debug2: channel 0: almost dead

debug2: channel 0: gc: notify user

debug2: channel 0: gc: user detached

debug2: channel 0: send close

debug2: channel 0: is dead

debug2: channel 0: garbage collecting

debug1: channel 0: free: client-session, nchannels 1

debug3: channel 0: status: The following connections are open:

  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)



Connection to x.x.x.x closed.

Transferred: sent 3680, received 2196 bytes, in 0.0 seconds

Bytes per second: sent 196278.1, received 117126.8

debug1: Exit status 1

# port salut, c'est marqué dessus

Posté par NeoX le 11 mars 2016 à 20:28. Évalué à 3.

fatal: bad ownership or modes for chroot directory "/var/www/mon-user"

bad ownership :
en gros tu as un utilisateur mon-user avec les UID/GID disons 1003
mais le dossier /var/www ou /var/www/mon-user n'appartient pas à l'utilisateur 1003

bad modes :
eventuellement c'est les "droits" sur ces dossiers qui ne sont pas bons
- [^] # Re: port salut, c'est marqué dessus
  
  Posté par hakhak91 le 14 mars 2016 à 10:08. Évalué à 1.
  Le dossier appartient à l'utilisateur que nous allons nommé test.
  voici comment il est crée
```
#useradd -p test -m -d /var/www/test/ -s /bin/bash test && echo test:test | chpasswd
```
  - [^] # Re: port salut, c'est marqué dessus
    
    Posté par NeoX le 14 mars 2016 à 10:16. Évalué à 2.
    
    il sert à quoi le echo test:test ?
    
    à quel moment tu definis les droits du dossier /var/www et ceux de /var/www/test ?
    - [^] # Re: port salut, c'est marqué dessus
      
      Posté par hakhak91 le 14 mars 2016 à 14:11. Évalué à 1.
      
      C'est le password du user test qui sert à illustrer ma problématique.
  - [^] # Re: port salut, c'est marqué dessus
    
    Posté par BAud (site web personnel) le 14 mars 2016 à 10:46. Évalué à 4.
    
    l'utilisateur que nous allons nommer test.
    
    Sans doute pas la meilleure idée au monde, surtout si le mot de passe est malencontreusement test :/
    Vu le nombre de scans ssh qui font ce genre de tentatives, ce serait limite une incitation à la compromission ;-)
    - [^] # Re: port salut, c'est marqué dessus
      
      Posté par hakhak91 le 14 mars 2016 à 14:10. Évalué à 1.
      
      C'est pour mettre en exemple un utilisateur.
      Le user test sera supprimé une fois la solution trouvée et nous allons appliquer les modifications sur l'utilisateur en production.
      - [^] # Re: port salut, c'est marqué dessus
        
        Posté par BAud (site web personnel) le 14 mars 2016 à 14:47. Évalué à 2.
        
        Je vais le reformuler autrement :
        
        si tu as un utilisateur test
        
        tu vas avoir déjà subi des tentatives d'intrusions
        
        si quelqu'un obtient une connexion ssh, cela lui donne un accès local à ton serveur, l'utilisation d'une faille locale lui permet d'escalader ses privilèges (il y a toutes les semaines des 0-days qui traînent ces derniers temps…).
        
        Cela peut se passer en moins de 2 jours, du fait de la large automatisation de ces scans et leur utilisation par des fermes de bots. Après, à toi d'évaluer le risque.
        
        [^] # Re: port salut, c'est marqué dessus
        
        Posté par hakhak91 le 14 mars 2016 à 16:47. Évalué à 1.
        
        C'est modifié
- [^] # Re: port salut, c'est marqué dessus
  
  Posté par hakhak91 le 14 mars 2016 à 14:33. Évalué à 1.
```
x.x.x.x-14:31-root-172.31.1.30-~# ls -l /var/www/
total 12
drwxr-xr-x 2 root     root     4096 févr. 25 12:09 html
drwxr-xr-x 3 test     test     4096 mars  14 14:14 test
```

# root:root

Posté par M.Poil (site web personnel) le 12 mars 2016 à 22:18. Évalué à 1.

De mémoire le dossier /var/www doit appartenir à root:root en 755
L'utilisateur mon-user doit être chroot dans /var/www (et pas /var/www/mon-user)

c'est valable également sur debian7, je penche pour une erreur de recopie :)

Is it a Bird? Is it a Plane?? No, it's Super Poil !!!

[^] # Re: root:root

Posté par hakhak91 le 14 mars 2016 à 10:23. Évalué à 1.

Avec la configuration suivante dans /etc/ssh/sshd_config

Match User test
        PasswordAuthentication yes
        ChrootDirectory /var/www/test
        ForceCommand internal-sftp
        ForceCommand internal-ssh
        X11Forwarding no
        AllowTCPForwarding no

#tail -f /var/log/auth.log
Mar 14 10:12:39 lnx-app-publishing-toulouse sshd[29782]: Accepted password for test from x.x.x.x
 port 59661 ssh2
Mar 14 10:12:39 lnx-app-publishing-toulouse sshd[29782]: pam_unix(sshd:session): session opened for user test by (uid=0)
Mar 14 10:12:39 lnx-app-publishing-toulouse sshd[29784]: fatal: bad ownership or modes for chroot directory /var/www/test
Mar 14 10:12:39 lnx-app-publishing-toulouse sshd[29782]: pam_unix(sshd:session): session closed for user test

#ssh test@x.x.x.x 
test@x.x.x.x's password:
Write failed: Broken pipe

Avec la configuration suivante dans /etc/ssh/sshd_config

Match User test
        PasswordAuthentication yes
        ChrootDirectory /var/www
        ForceCommand internal-sftp
        ForceCommand internal-ssh
        X11Forwarding no
        AllowTCPForwarding no

#tail -f /var/log/auth.log
Mar 14 10:14:36 lnx-app-publishing-toulouse sshd[29809]: Accepted password for test from x.x.x.x port 59662 ssh2
Mar 14 10:14:36 lnx-app-publishing-toulouse sshd[29809]: pam_unix(sshd:session): session opened for user test by (uid=0)
Mar 14 10:14:36 lnx-app-publishing-toulouse sshd[29811]: Received disconnect from x.x.x.x: 11: disconnected by user
Mar 14 10:14:36 lnx-app-publishing-toulouse sshd[29809]: pam_unix(sshd:session): session closed for user test

#ssh test@x.x.x.x
test@x.x.x.x's password:
Could not chdir to home directory /var/www/test/: No such file or directory
This service allows sftp connections only.
Connection to x.x.x.x closed.

[^] # Re: root:root

Posté par NeoX le 14 mars 2016 à 10:59. Évalué à 2.

c'est deja une evolution

Match User test
PasswordAuthentication yes
ChrootDirectory /var/www
ForceCommand internal-sftp
ForceCommand internal-ssh

ssh test@x.x.x.x
test@x.x.x.x's password:
Could not chdir to home directory /var/www/test/: No such file or directory
This service allows sftp connections only.
Connection to x.x.x.x closed.

quelque part tu lui dis que cet utilisateur ou ce serveur SSH n'autorise que le SFTP
tu tente de te connecter en SSH il t'a laissé entré, n'a pas vu de sftp, et a fermé la connexion

[^] # Re: root:root

Posté par hakhak91 le 14 mars 2016 à 14:30. Évalué à 1.

Modification pour la connexion ssh

MOI-14:08-root-10.10.10.100-/tmp# ssh test@x.x.x.x
test@x.x.x.x's password:
Could not chdir to home directory /var/www/test/: No such file or directory
/bin/bash: No such file or directory
Connection to x.x.x.x closed.

vim /etc/ssh/sshd_config
Match User test
        PasswordAuthentication yes
        ChrootDirectory /var/www
        #ForceCommand internal-sftp
        ForceCommand internal-ssh
        X11Forwarding no
        AllowTCPForwarding no

MOI-14:08-root-10.10.10.100-/tmp# ssh test@x.x.x.x
test@x.x.x.x's password:
Could not chdir to home directory /var/www/test/: No such file or directory
/bin/bash: No such file or directory
Connection to x.x.x.x closed.

J'ai testé la désactivation internal-ssh. Possible que la balise n'existe pas en modifiant le path du bash

vim /etc/ssh/sshd_config
Match User test
        PasswordAuthentication yes
        ChrootDirectory /var/www
        #ForceCommand internal-sftp
        ForceCommand internal-ssh
        X11Forwarding no
        AllowTCPForwarding no

Match User test
        PasswordAuthentication yes
        ChrootDirectory /var/www
        #ForceCommand internal-sftp
        #ForceCommand internal-ssh
        X11Forwarding no
        AllowTCPForwarding no

vim /etc/passwd
test:x:1006:1006::/var/www/test/:/bin/bash

remplacer par

test:x:1006:1006::/var/www/test/:/var/www/test/bin/bash

En root

mkdir /var/www/test/bin
cp /bin/bash /var/www/test/bin/
MOI-14:09-root-10.10.10.100-/tmp# ssh test@x.x.x.x
test@x.x.x.x's password:
Could not chdir to home directory /var/www/test/: No such file or directory
/var/www/test/bin/bash: No such file or directory
Connection to x.x.x.x closed.

[^] # Re: root:root

Posté par NeoX le 14 mars 2016 à 19:53. Évalué à 2.

parce qu'il faut comprendre que le chroot c'est un nouveau /

donc le shell de l'utilisateur est bien /bin/bash
si le chroot est /var/www
et que le shell est configuré en /bin/bash
le binaire doit etre dans /var/www/bin/bash
si le home de l'utilisateur est configuré en /home/user
il doit etre mis dans /var/www/home/user

[^] # Re: root:root

Posté par hakhak91 le 15 mars 2016 à 09:21. Évalué à 1.

Nous avons ajouté le répertoire /bin/bash dans /var/www/bin/bash
Sa ne fonctionne toujours pas.

ssh -v test@server:
...
..
.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent

permitted by applicable law.

Last login: Tue Mar 15 09:15:12 2016 from x.x.x.x

Could not chdir to home directory /var/www/test/: No such file or directory

/var/www/bin/bash: No such file or directory

debug1: client_input_channel_req: channel 0 rtype exit-status reply 0

debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0

debug1: channel 0: free: client-session, nchannels 1

Connection to x.x.x.x closed.

Transferred: sent 3680, received 2180 bytes, in 0.0 seconds

Bytes per second: sent 215937.6, received 127919.5

debug1: Exit status 1

[^] # Re: root:root

Posté par hakhak91 le 15 mars 2016 à 09:26. Évalué à 1.

Je l'ai aussi chrooté sur /var/www
sans succès.

test@x.x.x.x's password:

debug1: Authentication succeeded (password).

Authenticated to x.x.x.x ([x.x.x.x]:22).x.x.x.x

debug1: channel 0: new [client-session]

debug1: Requesting no-more-sessions@openssh.com

debug1: Entering interactive session.

debug1: Sending environment.

debug1: Sending env LANG = fr_FR.UTF-8

Could not chdir to home directory /var/www/: No such file or directory

/var/www/bin/bash: No such file or directory

debug1: client_input_channel_req: channel 0 rtype exit-status reply 0

debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0

debug1: channel 0: free: client-session, nchannels 1

Connection to x.x.x.x closed.

Transferred: sent 3680, received 1772 bytes, in 0.0 seconds

Bytes per second: sent 255415.6, received 122988.2

debug1: Exit status 1

# maintenant que j'y penses

Posté par NeoX le 15 mars 2016 à 12:53. Évalué à 2.

plutot que de vouloir faire un utilisateur chrooté dans /var/www

pourquoi ne pas dire à apache d'aller lire de dossier /home/test/public_html

le resultat est le meme, ton utilisateur accede uniquement à son home
et apache peut aller lire les fichiers qui sont dedans.
- [^] # Re: maintenant que j'y penses
  
  Posté par hakhak91 le 15 mars 2016 à 16:12. Évalué à 1.
  
  Ma demande n'est pas en rapport avec apache. Mais sa aurait pu être une très bonne idée dans un autre contexte.
  - [^] # Re: maintenant que j'y penses
    
    Posté par NeoX le 15 mars 2016 à 17:16. Évalué à 2.
    
    alors pourquoi vouloir chrooter l'utilisateur dans /var/www
    
    qui par definition appartient à apache2/ngnix/lighthttpd
    plutot que dans un dossier /chroot/ dedié à ca ?
    - [^] # Re: maintenant que j'y penses
      
      Posté par hakhak91 le 15 mars 2016 à 17:39. Évalué à 1.
      
      J'ai trouvé la solution!!
      
      Je ferai une belle explication demain
      
      MERCI MERCI pour votre aide ;-)

# Solution

Posté par hakhak91 le 16 mars 2016 à 10:00. Évalué à 1.

légende lorsque le prompt est en # =>root si $ =>user (test)
Vous trouverez les étapes pour chrooter l'utilisateur en ssh. (Nous nous sommes largement inspiré du site suivant: https://debian-facile.org/viewtopic.php?id=9607)

1)installation du packet bash-static

#apt-get install bash-static

2)Pour faciliter l'administration nous allons créer un groupe sshchroot

#addgroup sshchroot

3)Création de l'utilisateur test

#adduser test
#usermod -d / test
#usermod -s /bin/bash-static
#adduser test sshchroot

4)mettre l'utilisateur root propriétaire du home de test sinon la connexion ssh sera refusée

#chown root: /home/

5)petit script qui vous activera des commandes supplémentaire pour le user test

#cd /home/test
#vim create.sh

#!/bin/bash

mkdir -p {bin,dev,lib,lib64}
mknod dev/null c 1 3
mknod dev/zero c 1 5
chmod 0666 dev/{null,zero}

TMPFILE1=./temp1
TMPFILE2=./temp2
#Definition des commandes que vous souhaitez activer
APPS="/bin/bash /bin/cp /bin/ls /bin/mkdir /bin/mv /bin/rm /bin/rmdir /usr/bin/id /usr/bin/rsync /usr/bin/scp /usr/bin/wget /usr/bin/vim /usr/bin/vi /bin/cat /bin/less /usr/bin/tail /usr/bin/clear /bin/chmod"

for app in $APPS;  do
  if [ -x $app ]; then
    app_path=`dirname $app`
    if ! [ -d .$app_path ]; then
        mkdir -p .$app_path
    fi
    cp -p $app .$app
    ldd $app >> ${TMPFILE1}
  fi
done

for libs in `cat ${TMPFILE1}`; do
    frst_char="`echo $libs | cut -c1`"
    if [ "$frst_char" = "/" ]; then
        echo "$libs" >> ${TMPFILE2}
    fi
done

for lib in `cat ${TMPFILE2}`; do
      mkdir -p .`dirname $lib` > /dev/null 2>&1
      cp $lib .$lib
done

cp -r /lib/terminfo ./lib/

rm -f $TMPFILE1
rm -f $TMPFILE2

Lancez le script dans /home/test

#./create.sh

6)Editez le fichier de conf ssh pour enfin chrooter la connexion

#vim /etc/sshd_config 
Match Group test
        #%u permet de se placer automatiquement dans le home du user 
        ChrootDirectory /home/%u
        AllowTCPForwarding no
        X11Forwarding no

7)Petit restart du service ssh

# service ssh reload

(on ne sait jamais)
#service ssh restart

8)Test avec le user test

I have no name!@x.x.x.x:/$
I have no name!@x.x.x.x:/$ ls -l
total 28
drwxrwxr-x 2    0 1003 4096 Mar 15 15:35 bin
-rwxr-xr-x 1    0 1003  886 Mar 15 15:21 create.sh
drwxr-xr-x 2    0 1003 4096 Mar 15 15:23 dev
drwxr-xr-x 2 1001 1003 4096 Mar 15 15:48 lala
drwxr-xr-x 4    0 1003 4096 Mar 15 15:23 lib
drwxr-xr-x 2    0 1003 4096 Mar 15 15:23 lib64
drwxr-xr-x 4    0 1003 4096 Mar 15 15:23 usr

9) Je ne peux pas editez dans home de test
C'est normal seul root doit être propriétaire. Les droits plus permissifs sont les suivants:
chmod 755 si vous donnez des trop permissifs le ssh chrooter ne fonctionnera pas. Dans ce cas créer un répertoire dont l'utilisateur a full access.
exemple:

#mkdir /home/test/test 
#chown test:test /home/test/test

Encore merci pour vos propositions, suggestions et votre aide.

[^] # Re: Solution

Posté par hakhak91 le 16 mars 2016 à 10:12. Évalué à 1.
Rectification pour
4)mettre l'utilisateur root propriétaire du home de test sinon la connexion ssh sera refusé
```
#chown root: /home/
```
plutôt
```
#chown root: /home/test
```

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.