Discussion :

[llaffont]

Salut,

Je sais que le sujet est traité en long en large et en travers, j'ai même lu pas mal de post sur le sujet en appliquant à chaque fois les conseils trouvés.

Mais là je sèche depuis 3 jours, car rien ne fonctionne et il faut que se soit opérationnel d'ici le 24 Décembre...

J'ai mise en service un SFPT chrooté qui fonctionne convenablement si ce n'est que je ne parviens pas à lui faire accepter les connexions par authentification RSA.

La définition de la racine est celle-ci : /traffic_root les droits sont à 750 et le propriétaire et groupe sont root:root
L'arborescence du compte est celle-ci : /traffic_root/selleintel les droits sont à 750 et le propriétaire et groupe root:traffic
Dedans on trouve deux dossiers défini comme suit :

• /traffic_root/selleintel/.ssh les droits sont à 755 et le propriétaire et groupe root:traffic
• /traffic_root/selleintel/data les droits sont à 700 et le propriétaire et groupe selleintel:traffic

Concernant /traffic_root/selleintel/.ssh/authorized_keys les droits sont à 644 et le propriétaire et groupe selleintel:traffic

et voici le /etc/ssh/sshd_config

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
SyslogFacility AUTH
LogLevel DEBUG3
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
 
PubkeyAuthentication yes
PasswordAuthentication yes
 
ChallengeResponseAuthentication no
 
GSSAPIAuthentication no
GSSAPICleanupCredentials no
 
UsePAM yes
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
Subsystem       sftp    /usr/libexec/openssh/sftp-server
 
PermitRootLogin yes
StrictModes yes
 
 
Match group traffic
ChrootDirectory /apps/sftp_users/traffic_root/%u
AllowTcpForwarding no
X11Forwarding no
ForceCommand internal-sftp
PubkeyAuthentication yes
PasswordAuthentication yes

Avec cette configuration la plus part des informations trouvé sur la toile montre que ça doit fonctionner. Pourtant j'obtiens ça dans les logs :

déc. 20 18:44:32 filesServer.stas.ad sshd[9770]: debug1: temporarily_use_uid: 1000/1001 (e=0/0)
déc. 20 18:44:32 filesServer.stas.ad sshd[9770]: debug1: trying public key file /apps/sftp_users/traffic_root/selleintel/.ssh/authorized_keys
déc. 20 18:44:32 filesServer.stas.ad sshd[9770]: debug1: Could not open authorized keys '/apps/sftp_users/traffic_root/selleintel/.ssh/authorized_keys': Permission denied
déc. 20 18:44:32 filesServer.stas.ad sshd[9770]: debug1: restore_uid: 0/0
déc. 20 18:44:32 filesServer.stas.ad sshd[9770]: debug1: temporarily_use_uid: 1000/1001 (e=0/0)
déc. 20 18:44:32 filesServer.stas.ad sshd[9770]: debug1: trying public key file /apps/sftp_users/traffic_root/selleintel/.ssh/authorized_keys2
déc. 20 18:44:32 filesServer.stas.ad sshd[9770]: debug1: Could not open authorized keys '/apps/sftp_users/traffic_root/selleintel/.ssh/authorized_keys2': Permission denied
déc. 20 18:44:32 filesServer.stas.ad sshd[9770]: debug1: restore_uid: 0/0
déc. 20 18:44:32 filesServer.stas.ad sshd[9770]: debug3: mm_answer_keyallowed: publickey authentication test: RSA key is not allowed
déc. 20 18:44:32 filesServer.stas.ad sshd[9770]: Failed publickey for selleintelfrom 10.240.89.70 port 40198 ssh2: RSA SHA256:MWUynUdBzq3hmUBk/pGGyQiTjmLwBWxcJA0C7ZMMi64
déc. 20 18:44:32 filesServer.stas.ad sshd[9770]: debug3: mm_request_send entering: type 23

Auriez-vous une idée sur la raison de pourquoi l'entité 1000/1001 réciproquement selleintel/traffic ne parvient pas à atteindre le fichier authorized_keys, Alors qu'avec une session SFTP ouverte avec le Mot de passe l'utilisateur parvient à lire et éditer ce fichier ?

PS : L'authentification par RSA fonctionne très bien avec mon compte root.

Merci pour votre aide.

[llaffont]

Merci à tous d'avoir jeté un œil à mon problème.

Je pense avoir une piste :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
# cat  /etc/selinux/config
 
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of three values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected.
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

[llaffont]

Bon après l'avoir désactivé, cela fonctionne très bien.
Reste à voir comment le réactiver et faire en sorte que mon arborescence ne soit pas pénalisé par cette #@/*/&"".

[disedorgue]

Pour moi, le problème est ici:

La définition de la racine est celle-ci : /traffic_root les droits sont à 750 et le propriétaire et groupe sont root:root

déc. 20 18:44:32 filesServer.stas.ad sshd[9770]: debug1: temporarily_use_uid: 1000/1001 (e=0/0)

[llaffont]

Merci pour la proposition mais dans un partage SFTP CHROOT la racine devant héberger les futurs dossier doit appartenir à root c'est comme ça. La raison vient de l'option CHROOT.

Mais mon problème venait bien du SELINUX, car dès que je l'ai désactivé tout est rentré dans l'ordre et dès que je l'ai réactivé c'était de retour la galère.

Il me manquait cette petit commande : setsebool -P ssh_chroot_rw_homedirs on

On arrête pas le progrès ! Enfin concernant SELINUX c'est vite dit...