Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Accès SFTP restreint

Titi04

Bonjour,

Dans le but de donner un accès restreint SFTP sur un serveur (ubuntu 18.04) j'ai suivi ce tutoriel : https://community.jaguar-network.com/restreindre-lacces-sftp-dun-utilisateur-chroot/

Cette ligne fait planter le redémarrage d'apache.

Subsystem       sftp    internal-sftp

Je ne l'ai d'ailleurs pas compris. Quoiqu'il en soit en la commentant le serveur redémarre, cependant cela ne fonctionne pas. En effet, lors d'une tentative de connexion via filezilla j'obtiens le retour suivant :

Erreur :	Connection reset by peer
Erreur :	Impossible d'établir une connexion au serveur

Avez-vous une idée du pourquoi du comment ?

Merci pour vos réponses.

EDIT : temporairement ça a marché quelques minutes une aprem et d'un coup la connexion SFTP à sauter et depuis ça ne passe plus.

bruno

Bonjour,

Titi04 a écrit
Cette ligne fait planter le redémarrage d'apache.

Subsystem       sftp    internal-sftp

Quel est le rapport entre Apache, un serveur Web, et une directive pour openSSH, un serveur SSH/SFTP ?

Titi04

C'est une erreur de vocabulaire de ma part, pardon. C'est bien le service ssh qui ne démarre avec la ligne en question.

bruno

Il faut donner le contenu complet du fichier, mais normalement c'est plutôt du type :

Subsystem	sftp	/usr/lib/openssh/sftp-server


Match group groupe_truc
        PasswordAuthentication yes
        ChrootDirectory %h
        AllowTcpForwarding no
        ForceCommand internal-sftp

Titi04

Effectivement c'est différent. J'essaierai demain avec ce que tu m'as donné. En attendant voici le fichier complet. Est-ce que tu pourras m'expliquer un peu plus en détails le fonctionnement des différentes ligne histoire que je comprenne mieux ce que je fais ?

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
PasswordAuthentication yes

#Ajout pour connexion restreinte
#Subsystem      sftp    internal-sftp

Match Group groupe_restreint
        ChrootDirectory /home/%u
        ForceCommand internal-sftp
        AllowTCPForwarding no
        X11Forwarding no

Titi04

Je viens de regarder à nouveau le fichier, la ligne qui posait problème au redémarrage du service est déjà présente. Pour le reste j'ai essayé la version que tu as noté et j'ai la même erreur au niveau de filezilla.

bruno

Attention il faut aussi que le dossier dans lequel l'utilisateur est bloqué (chroot) appartienne à root. Dans ton cas /home/toto pour l'utilisateur toto.
Il faut aussi bien configurer le client, Filezilla ou autre, pour qu'il se connecte en SFTP sur le port 22.

Titi04

La configuration filezilla est bonne je me connecte au serveur avec le compte admin sans problème. Le /home/toto est bon normalement, je viens de vérifier avec ls -l qui me sort

drwxrwxrwx  6 root     root     4096 janv.  6 18:53 toto

Et comme je l'avais précisé dans l'edit de mon premier message il y a eu un moment ou au moins durant quelques minutes ça a fonctionné alors que ce ne fonctionnait pas avant.

bruno

Qu'est-ce que tu appelles le compte admin ?
Si la connexion SFTP fonctionne avec un autre utilisateur non restreint (non membre de groupe_restreint), c'est qu'il y a une erreur au niveau de l'utilisateur lui-même : il n'est pas dans le groupe groupe_restreint, il est verrouillé, mauvais mot de passe ou mot de passe expiré, etc.

Titi04

Je peux effectivement me connecter avec un utilisateur qui n'est pas dans ce groupe.
Je suis certain que le user et le mot de passe sont bon, si ce n'était pas le cas fail2ban aurait déjà ban mon IP. L'utilisateur est bien dans le groupe, je viens de vérifier en passant :

usermod -a -G groupe_retreint toto

bruno

Là je ne vois pas 'où vient le problème. Tout semble correct au niveau de la configuration.
Pour la vérification de l'utilisateur, il vaudrait mieux le retour de :

grep toto /etc/passwd
groups toto
chage -l toto

Le retour complet d'une tentative de connexion en ligne de commande pourrait aider à y voir plus clair :

sftp -v toto@serveur_ssh

Tu peux aussi regarder les logs sur le serveur.

Titi04

grep toto /etc/passwd
toto:x:1001:1001::/home/toto/:/bin/false
groups toto
toto : groupe_restreint

chage -l toto
Last password change                                    : janv. 06, 2020
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

Et voici la fin du retour de la tentative de connexion en ligne de commande. Je pense que le résultat est du que la connexion via terminal est interdite.

debug1: Next authentication method: password
toto@X's password: 
debug1: Authentication succeeded (password).
Authenticated to X ([X]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
packet_write_wait: Connection to X port 22: Broken pipe

bruno

La connexion via le terminal n'est pas interdite. Simplement les utilisateurs membres du groupe restreint ne peuvent faire que du SFTP (ForceCommand internal-sftp
), pas du SSH.
Le retour montre que la connexion et le mot de passe sont acceptés, c'est ensuite qu'une erreur (broken pipe) survient.

Je soupçonne fort que l'origine du problème soit les droits sur le dossier utilisateur.
En effet en #8, je n'avais pas remarqué que les droits sur /home/toto étaient en 777 (rwx pour tous). Il faut des droits en 755 (rwxr-xr-x) :

sudo chmod 755 /home/toto

Et cela devrait fonctionner.

Titi04

Le problème reste le même. J'avais pas les droits d'écriture en 775 lorsque l'on arrivait à se connecter avec le compte on n'avait uniquement le droit de lecture. En 777 ça passait.

bruno

Non cela ne peut pas fonctionner en 777. Et en plus c'est une faille de sécurité. Si le problème persiste en ayant changé les droits, il faudra examiner le fichier /var/log/auth.log au moment de la tentative de connexion.
Encore une fois la connexion fonctionne et le mot de passe est accepté. C'est ensuite que cela bloque pour une raison ou une autre : droits d'accès erronées sur les dossiers, problème de délai (TCPkeepAlive) ou de nombre de connexion simultanées, mauvaise configuration du client, problème de configuration réseau ou d'une VM, etc.

Titi04

J'ai bien conscience que cela pouvait entraîner une faille, c'était un essai. Quoiqu'il en soit j'ai bien repassé en 755.

Dans le ficher auth.log je trouve bien erreur que voici.

Jan 10 11:25:23 ns334757 sshd[11978]: fatal: bad ownership or modes for chroot directory component "/home/"

Il y aurait donc un problème de propriétaire ?

bruno

Oui, retour de :

ls -ld /home

Normalement /home doit appartenir à root avec des droits rwxr-xr-x soit 755

Titi04

C'est bon

drwxr-xr-x 3 root root 4096 juin  11  2019 /home

Titi04

Rah le boulet que je suis j'ai fait le ls -ld sur mon pc et non pas sur le serveur. Du coup le résultat sortait un 775 j'ai corrigé en 755. La connexion fonctionne à nouveau. L'upload ne fonctionne par contre.

Impossible de démarrer le transfert.

Je vais voir si j'arrive à obtenir quelque chose avec plus de détails.

EDIT : ça dit bien que je n'ai pas les droits d'écriture.

bruno

Si tu veux que l'utilisateur toto puisse tranférer des fichiers il faut qu'il ait au moins un sous dossier dont il est propriétaire.
Exemple :

/home/toto propriétaire root groupe root droits rwxr-xr-x

/home/toto/documents propriétaire toto groupe toto (ou autre) droits au minimum rwx pour le propriétaire

Page suivante »