Forum Linux.debian/ubuntu Securiser SSH par clef

Posté par Philoolehiboo le 22 février 2021 à 13:16. Licence CC By‑SA.

Étiquettes :

fév.

2021

Bonjour,

Je souhaite "securiser" mes acces ssh a mes differentes machines virtuelles.
Pour cela, je passe de la securité "passwrd" aux clefs rsa.
Cela fonctionne sur la plupart des machines :
-generation de la clef sur le client
-copie via ssh-copy-id /id-rsa user@ip
-desactivation acces root et mot de passe
tout est ok

MAIS, et c'est la que je demande votre aide, je rencontre un soucis depuis 2 jours sur une debian qui fait tourner openmediavault
-acces par mot de passe ok, mais impossible d'acceder uniquement par la clef
Elle se trouve pourtant bien dans le /home/user/.ssh/authorized_keys mais j'ai le messeage d'erreur "Permission denied" public keys.

J'ai changé les droits en 700 sur le dossier .ssh, copier a la mano la clef,changer le chemin Authorized_keys dans le sshd_config du serveur et enfin changé le User dans le groupe SSH, rien n y fait….

Merci pour vos conseils et/ou solutions!

# Groupe ?

Posté par Nanawel (site web personnel, Mastodon) le 22 février 2021 à 13:44. Évalué à 1. Dernière modification le 22 février 2021 à 13:44.
Sauf erreur, je crois que sur OMV les utilisateurs avec lesquels il est possible de se connecter en SSH doivent être dans le groupe système ssh au préalable.
```
usermod -aG ssh $ton_user
```
- [^] # Re: Groupe ?
  
  Posté par stombi (site web personnel) le 22 février 2021 à 13:49. Évalué à 1.
  
  je confirme, dans l'interface web il faut cocher ssh dans les groupes de l'utilisateur. On peut aussi ajouter un clé directement dans l'interface web au niveau du user
- [^] # Re: Groupe ?
  
  Posté par Philoolehiboo le 22 février 2021 à 14:11. Évalué à 1. Dernière modification le 22 février 2021 à 14:13.
  
  root@NAS:~# grep "philoo" /etc/group
  root:x:0:philoo
  users:x:100:philoolehiboo,philoo
  ssh:x:111:philoo
  root@NAS:~#
  
  Normalement il y est
  
  Desoler je n'arrive pas a poster la capture d ecran
  - [^] # Re: Groupe ?
    
    Posté par Nanawel (site web personnel, Mastodon) le 22 février 2021 à 14:40. Évalué à 1.
    Tu peux tester un
```
journalctl -u ssh -xe
```
    pour avoir les raisons des erreurs de connexion ?
    - [^] # Re: Groupe ?
      
      Posté par Philoolehiboo le 22 février 2021 à 16:01. Évalué à 1. Dernière modification le 22 février 2021 à 16:01.
      
      Accepted password for philoo from 192.168.1.37 port 49724
      févr. 22 14:17:11 NAS sshd[7087]: pam_unix(sshd:session): session opened for user philoo by
      févr. 22 14:17:21 NAS sshd[7118]: error: Could not load host key: /etc/ssh/ssh_host_dsa_key
      févr. 22 14:17:21 NAS sshd[7118]: Authentication refused: bad ownership or modes for directo
      févr. 22 14:17:21 NAS sshd[7118]: Authentication refused: bad ownership or modes for directo
      févr. 22 14:17:26 NAS sshd[7118]: Accepted password for philoo from 192.168.1.37 port 49726
      févr. 22 14:17:26 NAS sshd[7118]: pam_unix(sshd:session): session opened for user philoo by
      févr. 22 15:27:22 NAS sshd[8870]: error: Could not load host key: /etc/ssh/ssh_host_dsa_key
      févr. 22 15:27:25 NAS sshd[8870]: Accepted password for root from 192.168.1.37 port 49908 ss
      
      J ai regeneré une clef en id.dsa , idem , refusé
      
      Mon fichier "authorized_keys" sur le serveur se remplit (respectivement 4 clef rsa identiques et 2 clefs dss) j'hesiste a supprimer ce repertoire afin de le purger car je suis obliger de le recreer a la main sous root et changer le proprietaire en user mais je fais peut etre pas bien
      - [^] # Re: Groupe ?
        
        Posté par Anonyme le 22 février 2021 à 17:27. Évalué à 5.
        
        Authentication refused: bad ownership or modes for directo
        
        À mon avis, l’utilisateur ou le groupe du dossier .ssh est pas bon (par exemple si tu as créé le fichier en tant que root pour un utilisateur lambda).
        
        [^] # Re: Groupe ?
        
        Posté par Nanawel (site web personnel, Mastodon) le 22 février 2021 à 18:24. Évalué à 1.
        
        Oui c'est ça, le cas classique de permissions incorrectes sur le dossier ./ssh/* et son contenu. SSH est très tatillon sur ça (à raison, bien sûr).
        
        Pour un user toto, ça devrait être par exemple
        
        ls -alR /home/toto/.ssh/ /home/toto/.ssh/: total 24 drwx------ 2 toto users 4096 mai 2 2019 . drwxr-xr-x 9 toto users 4096 janv. 25 2020 .. -rw-r--r-- 1 toto users 1192 mai 2 2019 authorized_keys
        
        Les permissions ne suffisent pas, il faut aussi le bon ownership.
        
        [^] # Re: Groupe ?
        
        Posté par Philoolehiboo le 22 février 2021 à 18:39. Évalué à 1.
        
        ls -al
        total 16
        drwx------ 2 philoo ssh 4096 févr. 22 16:36 .
        drwxr-xr-x 3 1000 1000 4096 févr. 18 00:11 ..
        -rw------- 1 philoo ssh 609 févr. 22 16:35 authorized_keys
        -rw-r--r-- 1 philoo ssh 222 sept. 30 2019 known_hosts
      - [^] # Re: Groupe ?
        
        Posté par jigso le 23 février 2021 à 08:47. Évalué à 2.
        
        : error: Could not load host key: /etc/ssh/ssh_host_dsa_key
        
        c'est peut-etre sur ce fichier qu'il y a un pb de droits ?
# Re: Securiser SSH par clef

Posté par guitou le 22 février 2021 à 15:31. Évalué à 1.

Bonjour
Doc
A priori, je verrais essentiellement 2 choses a verifier.
- l'option de config PubkeyAuthentication du serveur ssh dans /etc/ssh/sshd_config
- la procedure pour enregistrer la cle publique de l'utilisateur dans son profil, via l'interface web (probable que le setup OMV utilise un autre emplacement que ~/.ssh/authorized_keys)

++
Gi)
- [^] # Re: Securiser SSH par clef
  
  Posté par Philoolehiboo le 22 février 2021 à 19:44. Évalué à 1.
  
  effectivement d'aprés la doc il faut editer la sortie du fichier id.rsa.pub et le coller via l'interface clef ppublique dans OMV.
  Par curiosité, il me semble que cette clef est en fait stockée dans
  /var/lib/openmediavault/ssh/user/authorized_keys
  
  .
# Un lien trouvé

Posté par MicP le 23 février 2021 à 01:21. Évalué à 1. Dernière modification le 23 février 2021 à 01:22.

Bonjour

Peut-être quelques pistes qui n'ont pas encore été explorées :
https://forum.openmediavault.org/index.php?thread/32487-fixing-public-key-authentication/
- [^] # Re: Un lien trouvé
  
  Posté par Philoolehiboo le 23 février 2021 à 10:48. Évalué à 1.
  
  Merci pour cette source tres utile
# Le client

Posté par seb le 23 février 2021 à 08:38. Évalué à 1.

Salut,

J'ai eu un problème similaire une fois et cela venait du client, si tu forces la clé avec un ssh -i ~/.ssh/ta_cle user@serveur ça change quelque chose ?
- [^] # Re: Le client
  
  Posté par Philoolehiboo le 23 février 2021 à 10:48. Évalué à 1.
  
  Salut,
  merci deja tenté mais ne resoud pas
# Resolu

Posté par Philoolehiboo le 23 février 2021 à 11:05. Évalué à 2.

Finalement sujet resolu grace a vos differents post:

OMV a effectivement besoin d'une clef au format RFC4716 donc,
1/generer une clef ssh-keygen sur le poste local
2/convertir le id..pub et afficher et copier la sortie avec ssh-keygen -e -f id..pub (a faire par l'user avec lequel on se connecte, verifier dans le comment:)

3/Se connecter a l'interface WebGui OMV et coller la sortie convertie pour le bon user.

--Dans ma config OMV, je n'ai pas autorisé la creation de dossier perso pour les users, je pense que cela influe sur l'emplacement du "authorized_keys"--

Comme je trouve ca bof d'etre obligé de passer par le Webgui, solution alternative:

Copier la clef entre les entetes "BEGIN et END", se connecter par password au serveur et editer le fichier /var/lib/openmediavault/ssh/authorized_keys/"user"
Dans ce fichier edité, rajouter ssh-rsa(ou autre chiffrement) puis coller et mettre en forme pour supprimer les retours a la ligne

J'avoue j'en ai chié pendant 2 jours, mais je vous remercie pour vos differents commentaires et liens qui m'ont aiguillés.

Suivre le flux des commentaires

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