SSH's Keys Authentications. Ok en root, NOk en user

**T3rm1nat0r** · 23/02/2013, 16h07

Bonjour tout le monde !

Alors voilà, j'ai un Nas à la maison (Nas4Free, équivalent à FreeNAS en version 7)
Je souhaite m'y connecter en SSH avec des clés Privées/Publiques
Voilà comment j'ai procédé :

Ouverture Session SSH via Putty avec ID/Password en root

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
# mkdir ~/.ssh
# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
f3:..:..:..:20 root@nas4free.local
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|o=..   . +       |
|.+o .....        |
+-----------------+
# mv id_rsa.pub authorized_keys
# exit

Je copie ensuite id_rsa.pub sur mon bureau Windows 7 via WinSCP
je lance powershell :

Code :

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

$connexionServeurSSH = New-SSHSession -Server $nas4free -UserName root -Key $keyFile

Ca fonctionne !
Je m'y déconnecte :

Code :

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

Remove-SSHSession -Client $connexionServeurSSH

Bon. Jusqu'ici tout va bien me direz-vous...
Sauf que moi je veux m'y connecter pour un script de backup pour ma famille. Donc une connexion root, c'est quand même pas tip top...

Je créé via l'interface GUI un utilisateur backup dont le shell est autorisé.
Je test en me connectant au Nas via Putty et ID/Password en backup

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
# mkdir .ssh
# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/mnt/nas/backup/.ssh/id_rsa):
Created directory '/mnt/nas/backup/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /mnt/nas/backup/.ssh/id_rsa.
Your public key has been saved in /mnt/nas/backup/.ssh/id_rsa.pub.
The key fingerprint is:
f3:..:..:..:20 backup@nas4free.local
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|o=..   . +       |
|.+o .....        |
+-----------------+
# mv id_rsa.pub authorized_keys
# exit

Je copie ensuite id_rsa.pub sur mon bureau Windows 7 via WinSCP
je lance powershell :

Code :

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

$connexionServeurSSH = New-SSHSession -Server $nas4free -UserName backup -Key $keyFile2

J'obtiens :
Error connecting 192.168.0.10. Exception lors de l'appel de «Connect» avec «0» argument(s): «User cannot be authenticated.»

Je me suis alors dit... Peut-être faut-il mettre la clé publique non pas dans le "authorized_keys" de backup mais dans celui de "root"
en faisant un

Code :

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

# tail backup\.ssh\authorized_keys >> ~\.ssh\authorized_keys

Mais là je ne peux plus m'y connecter en root ni en backup via les clés...

Pourquoi est-ce que je n'arrive pas avec un utilisateur perso mais qu'en root tout se passe bien?
Qu'est-ce que j'oublie ?

EDIT : Mes dossiers .ssh et mes fichiers authorized_keys, pour chacun des comptes possèdent les droits d'écriture pour le possesseur seulement.

**disedorgue** · 23/02/2013, 17h25

Bonjour,

Je ne sais pas si j'ai tout compris sur ton problème, mais si le client c'est ton windows 7 et ton serveur ton FREE4NAS (donc je suppose un freebsd), tu devrais en principe concaténer ta clé public dans ton authorized_keys de backup et utiliser la clé privé depuis ton poste client et non l'inverse.

Cordialement.

**T3rm1nat0r** · 23/02/2013, 17h31

Salut disedorgue

C'est bien ce que je fais

Code :

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

# mv id_rsa.pub authorized_keys

Pour preuve, ca fonctionne très bien quand je veux me logger en "root" via SSH Keys

Moi je ne comprends pas pourquoi ca marche avec "root" et pas avec "backup" alors que je fais la même procédure...

**disedorgue** · 23/02/2013, 17h43

Dans ce cas, il se peut que cela vient de la configuration de ton serveur ssh, et que l'authorized_keys utilisateur se trouve dans un autre répertoire pour n'être pilotable que par root.
un répertoire du genre /etc/ssh/<nom_utilisateur> ou quelque chose comme ça.

Regarde ta configuration dans /etc/sshd_config pour "AuthorizedKeysFile" et "AuthorizedPrincipalsFile".
man sshd_config pour plus d'informations

Cordialement.

**T3rm1nat0r** · 23/02/2013, 21h07

Hum, alors dans mon /etc/ssh/sshd_config je n'ai pas de lignes "AuthorizedKeysFile" et "AuthorizedPrincipalsFile"

Dois-je les rajouter du coup ?

un tail me donne ceci :
Protocol 2
UseDNS no
SubSystem sftp /usr/libexec/sftp-server
ChallengeResponseAuthentication no
Port 22
PermitRootLogin yes
AllowTcpForwarding no
PasswordAuthentication yes
PubkeyAuthentication yes

Jdois t'avouer ne pas comprendre grand chose la-dedans..
"AuthorizedPrincipalsFile" n'est pas dans le man
"AuthorizedKeysFile" irait donc me chercher mon authorized_keys qui se trouve dans mon repertoire backup ?

**disedorgue** · 23/02/2013, 21h37

Alors, dans un premier temps, fait une copie de ton fichier /etc/sshd_config histoire de le restaurer au cas où.
Si tu ne peux accéder a ton free4nas que par ssh, garde toujours une connection dessus dans le cas où il y a un loupé sur la modification du fichier et que ssh ne te permette plus de te connecter.

A ce que je vois de ta config, il faudrait modifier juste:

Code :

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

ChallengeResponseAuthentication no

par

Code :

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

ChallengeResponseAuthentication yes

Ensuite, l'un des piège fréquent concernant le fichier authorized_keys, c'est qu'il ne finisse pas par une ligne vide, et donc quand tu concatène une autre clé dedans, celle-ci et la précédente du fichier deviennent inutilisable car les 2 clés se retrouve sur la même ligne.

Il faut aussi vérifier les droits du répertoire .ssh de ton user ainsi que les droits de ton fichier authorized_keys (a priori, pour lui cela semble ok, au vu de se que tu as déjà précisé).

Cordialement.

**T3rm1nat0r** · 24/02/2013, 18h03

Pour ce qui est de l'accès, pas de soucis, le serveur est chez moi, faudra juste que je me lève de ma chaise

j'ai mis ChallengeResponseAuthentication à "yes"
j'ai ajouté une ligne vide après mes clés au cas où
j'ai fais un /etc/rc.d/sshd restart

même résultat :/

Mes deux connexions (en "root" et en "backup") se font à partir du même poste... Ca ne pose pas de soucis ?

Mes clés, je dois toutes les mettre dans ~/.ssh/ peu importe qu'elles soient pour une connexion "root" ou "backup"

Ou alors je mets les clés pour "root" dans ~/.ssh/
et les clés pour "backup" dans /mnt/nas/backup/.ssh/ ?

A l'heure actuelle j'ai ma clé publique pour "backup" dans chacun de mes 2 .ssh/authorized_keys
Donc normalement le soucis vient pas de là (c'est une question à titre informatif)
Je vois pas trop d'où pourrait venir le problème du coup...

**disedorgue** · 24/02/2013, 19h27

En général, pour un ssh standard, on met les clé ssh dans le fichier authorized_keys qui doit se trouver dans le répertoire .ssh qui lui même se trouve dans le HOME de l'utilisateur, donc dans ton cas, pour l'user backup dans:

Code :

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

~backup/.ssh/authorized_keys

une clé égale une ligne et une seule, pas 1 clé sur plusieurs lignes.

Si ton authorized_keys de root fonctionne, c'est à dire si tu arrive à te connecter en root sans problème avec sa clé ssh, tu peux aussi dans ce cas le copier à la place du fichier authorized_keys de ton user backup (en respectant la propriété et les droits du fichier pour backup) et essayer de te connecter en tant que backup depuis ton client en utilisant la même clé que pour root.Cet action permettra de retirer la mise en cause de la validité du fichier authorized_keys

Après tu peux aussi lancer un depuis ton poste client avec l'option -vvv pour que celui-ci te dise ce qu'il fait ou essaye de faire (en fait c'est le mode verbose de ssh (les 3 v c'est pour un verbose max).

Cordialement.

**T3rm1nat0r** · 06/03/2013, 14h07

Bonjour, après pas mal de test et beaucoup d'énervement j'ai décidé de tout recommencer à 0...

Ce que je veux faire :
Me connecter à mon serveur à partir d'un client ubuntu en ssh avec clés private/public pour être plus tard utilisé dans un script de sauvegarde.

Ce que j'ai fait :
Supprimé tout ce qu'il y a dans mes authorized_keys de root ET backup ET dans mon poste client (ubuntu)
Supprimé tout ce qu'il y a dans mes known_hosts de root ET backup ET dans mon poste client (ubuntu)

J'ai ensuite, sur ubuntu lancé la commande ssh-keygen
Pas de passphrase
Récupération des fichiers id_rsa, id_rsa.pub

Code :

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

1
2
3
4
5
ubuntu@ubuntu:~/.ssh$ ls -l
total 12
-rw------- 1 ubuntu ubuntu 1675 201-03-02 01:56 id_rsa
-rw-r--r-- 1 ubuntu ubuntu 406 201-03-02 01:56 id_rsa.pub
-rw-r--r-- 1 ubuntu ubuntu 1162 201-03-02 01:58 known_hosts

Je lance alors la commande d'envoi de clé :

Code :

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

ubuntu@ubuntu:~/.ssh$ ssh-copy-id -i id_rsa.pub backup@monServeur

Sur mon serveur j'ai dans mon dossier backup :

Code :

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

1
2
3
4
5
6
7
8
root@monServeur:(...)/backup# ls -la
drwxrwxrwx 5 backup guest 512 Mar 1 06:14 .
drwxrwxrwx 7 root wheel 1024 Feb 20 02:31 ..
drwx------  2 backup guest 512 Mar 2 05:20 .ssh
 
root@monServeur:(...)/backup/.ssh# ls -l
-rw-r--r-- 1 backup guest 406 Mar 6 19:08 authorized_keys
-rwxr-x--- 1 backup guest 0 Feb 23 22:21 known_hosts

Ma clé publique est bien dans mon authorized_keys.

Pour ce qui est de sshd_config :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
root@monServeur:(...)/backup/.ssh# cat /etc/ssh/sshd_config
SysLogFacility LOCAL3
Protocol 2
UseDNS no
Subsystem sftp /usr/libexec/sftp-server
ChallengeResponseAuthentication no
Port 22
PermitRootLogin yes
AllowTcpForwarding no
PasswordAuthentication yes
PubkeyAuthentication yes

et.. ça ne marche pas :/

**JeitEmgie** · 06/03/2013, 15h58

Envoyé par T3rm1nat0r

et.. ça ne marche pas :/

qu'est-ce qui ne marche pas ?

Code :

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

1
2
 
ssh backup@monserveur ...

?

vous avez créé un .ssh/ dans /mnt/nas/backup/ mais est-ce que ce dossier est bien le $HOME de l'utilisateur backup et est-ce que l'utilisateur backup a un shell associé ? (voir dans etc/passwd)

**T3rm1nat0r** · 06/03/2013, 18h34

Ce qui ne marche pas c'est la connexion ssh avec les clés
Malgré la procédure ci-dessus réalisée, lorsque je fais un ssh backup@monServeur il me demande quand même mon mot de passe, il ne passe pas par les clés d'authentifications.

Par contre, si je rentre les mots de passe, je peux très bien me connecter !
J'accède bien au répertoire perso de "backup"

J'ai bien un shell d'associé car je l'ai activé dans l'interface d'administration de freenas (enfin, Nas4Free)
Et comme je peux m'y connecter parfaitement avec les mots de passe, c'est juste au niveau des clés (ou des droits) que ça doit merder...

un cat /etc/passwd me donne concernant backup :
backup:*:1008:31:backup:/mnt/nas/backup/:/bin/sh