Voici ma situation:
Client A
Client B
Serveur S
J’aimerais que B ne puisse pas se connecter en tant que root à S mais uniquement en tant que utilisateur simple, tandis que A le puisse. Tout en servant uniquement des clés d’authentification (mot de passes désactivé).
Actuellement les deux le peuvent se connecter en tant que root grâce aux clés ssh.
Comment interdire B l’accès à root, tout en le permettant de se connecter en utilisateur ?
J’ai essayé de me connecter en tant que utilisateur simple depuis B, mais je reçois l’erreur
Permission denied (publickey).
Sur mon serveur, dans /root/.ssh
J’ai mon fichier authorized_keys avec la clé publique de A et celle de B. permission à 700, propriétaire root.
Chez A et B, ils ont tout les deux dans /root/.ssh
id_rsa 700 root
id_rsa.pub 744 root
très mauvaise idée d’autoriser une connexion ssh en root; c’est la sécurité du serveur qui mise à mal. Il faut uniquement permettre les connexions en user et une fois connecté en user passer root pour l’utilisateur qui a le droit de le faire.
Pour interdire la connexion ssh en root il faut ajouter la ligne " PermitRootLogin no " dans le fichier sshd_config et ensuite relancer ssh pour que cette ligne soit prise en compte.
Non, ça permet juste d’empêcher de se connecter directement en root depuis le client, mais une fois connecté en tant que simple utilisateur celui qui a le mot de passe root du serveur peut passer en root comme il le ferait sur son propre PC.
Pour te connecter en tant que simple utilisateur à ton serveur, c’est pas dans /root/.ssh qu’il faut mettre les clés publiques, mais dans le dossier /home/user/.ssh de l’utilisateur simple configuré sur le serveur… En l’occurence A ou B.
Pas de permission à 700…, pourquoi 700? Ce fichier n’a pas besoin d’être executé mais simplement lu, et uniquement par l’utilisateur auquel il est destiné, donc permission 600 pour le fichiers dans …/.ssh et 700 pour le dossier ssh lui-même.
Ensuite si tu peux te connecter depuis le serveur sur A et B c’est que tu as aussi installé openssh-server sur tes clients A et B : tu n’en as pas besoin car l’usage voulu est que tu te connectes depuis tes clients sur le serveur, donc ça tu peux le virer et ne garder que openssh-client sur tes postes A et B.
Enfin je te conseille de te fabriquer ton propre jeu de clés privée/publique à l’aide de la commande :
$ ssh-keygen
Regardes du côté du man pour les différentes options, et ce ne sont pas non plus les tutos qui manquent sur le net ; de cette manière et comme tu as deux clients A et B, il est préférable de créer deux paires de clés.
Et en dernier il est préférable de copier le contenu de la clé publique vers le fichier authorized_keys du serveur à l’aide de la commande :
$ ssh-copy-id ...
Bien sûr pour pouvoir faire cette opération, il faudra que, du côté du serveur dans le fichier “sshd_config” tu actives temporairement la connexion avec mot de passe pour pouvoir faire cette opération, puisque les clés publiques n’y sont pas encore… Penses bien également à relancer le service ssh à chaque fois que tu modifies son fichier de config sshd_config.
J’ai besoin d’avoir le serveur qui puisse se connecter au client B, vu que je n’y ait accès qu’à distance. Mais j’ai besoin que B puisse aussi se connecter au serveur car il doit exécuter un script bash et renvoyer son résultat sur le serveur régulièrement.
En fait B est dans un endroit où l’abonnement internet ne distribue que des ips dynamiques. Je l’ai donc configuré pour qu’une fois par jour il me renvoie sa nouvelle adresse ip dans un fichier texte sur le serveur S.
J’ai avancé mais je rencontre des problèmes:
Pour A, j’ai fait la commande ssh-keygen -t rsa -b 4096 puis ssh-copy-id userA@ipS. Maintenant je peux bien me connecter en userA sans qu’il me demande de mot de passe.
Pour B je préfère ne pas régénérer une paire de clé si possible car il y a 3 postes dans son réseau local qui possèdent sa clé publique (et qui marche parfaitement vu que je peux m’y connecter sans problèmes sans mot de passe depuis B).
J’ai donc uniquement fait la commande ssh-copy-id userB@ipS.
Il m’a mit exactement le même résultat que sur client A ("Number of key(s) added: 1")
Depuis B je peux me connecter à S en tant que “userB”, mais j’ai besoin d’un mot de passe. Si je désactive les mots de passe dans sshd_config de S, B me renvoie l’erreur ‘Permission denied (publickey).’
J’ai vérifié les permissions et je les ai mises 700 pour .ssh, 600 pour authorized_keys sur serveur S avec comme propriétaire l’utilisateur en question (userA ou userB).
Néanmoins je n’arrive toujours depuis client B. J’'ai vérifié que la clé publique pour les 3 postes du réseau local de B est bien la même que celle qui dans authorized_keys pour userB sur serveur S.
merci mais j’ai passé toute l’après-midi à lire de la doc/tutos, si je viens ici c’est parce que je n’ai pas réussi à trouver la solution sur internet.
Sur mon serveur, dans /root/.sshJ’ai mon fichier authorized_keys avec la clé publique de A et celle de B.
c’est donc normal que A et B est un accès root.
si tu veut que B est un accès user de base
créer un utilisateur de base sur ton server exemple toto
et en suite
Sur ton serveur, dans /root/.sshJ’ai mon fichier authorized_keys avec la clé publique de A
Sur ton serveur, dans /toto/.sshJ’ai mon fichier authorized_keys avec la clé publique de B
l’utilisateur B ne pourra plus alors accéder a root par autentification clef priver clef publique.
mais comme dit plus haut c’est pas tope d’un poins de vue sécuritée.
le mieux est d’autoriser les connexion a un utilisateur simple pour tous le monde , la commande
su - pour passer en root une foie connéctée.
ou encore de créer des utilisateur sur le serveur a qui on donne des droit supérieure avec sudo .
Si on utilise AllowUsers, il faut lister tous les utilisateurs qui ont le droit de se connecter (ce qui peut être pénible même si c’est mieux pour la sécurité).
Il faudra probablement mettre dans ce cas au choix : AllowUsers root@[IP_A], user@[IP_B] AllowUsers root@[IP_A], user
Une autre possibilité est de mettre from='[IP_A]' au début de la ligne qui contient la clef dans le fichier authorized_keys de root sur le serveur.
On obtient donc un ligne comme : from="IP_A" ssh-[type de clef] AAAA[…] user@A
On peut bien sûr combiner les deux (deux précaution valent mieux qu’une, paraît-il).
Comme AllowUsers, il existe AllowGroups. On peut créer un groupe et mettre les users autorisés dans ce groupe.
Perso, je trouve plus pratique d’ajouter/supprimer les users dans un groupe que de gérer une liste.
