[RESOLU]Annulation de connexion SSH pour un seul utilisateur

alfirdaous · Le 03/06/2012, à 14:19

Bonjour,

J'ai genere une clef pour 3 utilisateurs, copies sur leurs repertoires .ssh, comment annuler la connexion ssh pour un pseudo user1 sans affecter les autres.

Merci

Dernière modification par alfirdaous (Le 05/06/2012, à 07:34)

Qid · Le 03/06/2012, à 14:21

en supprimant la clef de son repertoir peut etre ? ...

alfirdaous · Le 03/06/2012, à 14:31

dans le repertoire j'ai seulement authorized_keys, que j'ai supprime, mais ca se connecte pas.

/home/pseudo1/authorized_keys
/home/pseudo2/authorized_keys
/home/pseudo3/authorized_keys

je voulais supprimer celle de pseudo3

/home/pseudo1/authorized_keys
/home/pseudo2/authorized_keys
/home/pseudo3/

voila:

$ sudo mv authorized_keys auth1
[sudo] password for desktop: 
$ ls
auth1  test
$ sudo service ssh restart
ssh start/running, process 10360
$ ssh desktop@94.23.233.170
Permission denied (publickey).

Qid · Le 03/06/2012, à 14:33

donc c'est bon ?

alfirdaous · Le 03/06/2012, à 14:52

normalement ca doit se connecter pour cet utilisateur, mais il me demande publickey

Qid · Le 03/06/2012, à 14:59

bon on recommance à la source parce que de toutes évidence il y a quelque chose de pas clair :

alfirdaous a écrit :

J'ai genere une clef pour 3 utilisateurs, copies sur leurs repertoires .ssh, comment annuler la connexion ssh pour un pseudo user1 sans affecter les autres.

si tu crée une clef pour 3 utilisateur les 3 peuvent se connecter ça c'est normal ...
si tu ne veux plus qu'un utilisateur puisse se connecter
tu lui enlève simplement la clef et puis c'est tout ...
quoi dire de plus ?

alfirdaous · Le 03/06/2012, à 15:18

pardon Qid, peut etre les changement n'etaient pas pris en compte, que lorque j'ai mis du changement dans sshd_config:

PasswordAuthentication no

je l'ai remis en yes, redemarrer le SSH, apres:

PasswordAuthentication no

restart SSH, apres ca marche.

J'ai essaye de se connecter d'une autre machine, et ca donne:

mery@ubuntu:~/.ssh$ ssh desktop@IP
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/mery/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /home/mery/.ssh/id_rsa
Permission denied (publickey).
mery@ubuntu:~/.ssh$

est ce que maintenant tout va bien??

Dernière modification par alfirdaous (Le 03/06/2012, à 15:19)

Qid · Le 03/06/2012, à 15:27

alfirdaous a écrit :

est ce que maintenant tout va bien??

pas trop : t'as joué à quoi avec les droits de ta clef ? parce que la de toutes évidence il y a un truc qui ne lui plait pas

alfirdaous · Le 03/06/2012, à 15:35

je n'ai pas attribue de droits a ma clef, juste creee et copiee

Nasman · Le 03/06/2012, à 15:41

Et dans le fichier sshd_config du serveur, il y a la possibilité de limiter les utilisateurs ayant accès à ce dernier

AllowUsers user1 user2

alfirdaous · Le 03/06/2012, à 16:23

oui Nasman, c'est une bonne chose, qui est deja issue, je voudrais juste voir ce jeu de clef SSH, en ajoutant un utilisateur, son repertoire ssh ne contient pas de clef (authorized_keys), et pourtant ne peuvent pas se connecter

$ sudo adduser rimie
[sudo] password for desktop: 
Adding user `rimie' ...
Adding new group `rimie' (1002) ...
Adding new user `rimie' (1002) with group `rimie' ...
Creating home directory `/home/rimie' ...
Copying files from `/etc/skel' ...
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully

voila la connexion, sachant que:

PasswordAuthentication no

Resultat:

$ ssh rimie@94.23.233.170
Permission denied (publickey).

nesthib · Le 03/06/2012, à 18:29

@alfirdaous : il semble que tu mélanges plusieurs choses ici. Voici comment mettre en place proprement :

le dossier .ssh doit avoir les permissions 700, normalement tu ne devrais pas le créer à la main
la clé privée doit avoir les permissions 600 ou 700
la clé publique doit avoir les permissions 644 ou 744
tu ne devrais pas créer de clé pour tes clients, il devraient créer leur clé eux même (avec ssh-keygen) et te fournir la clé publique (.ssh/id_dsa.pub)
tu peux régler les autorisations de connexion, et notamment le doit d'utiliser ou non un mot de passe, et des droits par nom/groupe d'utilisateur dans le sshd_config
soit tu peux ajouter la clé publique de tes clients dans authorized_keys, soit ils peuvent se connecter une première fois avec ssh-copy-id et un mot de passe

pour supprimer le doit d'un utilisateur à se connecter sur une machine, il suffit de supprimer sa clé publique du fichier authorized_keys. Tu devrais avoir une ligne de la forme :

ssh-dss XXXXXXXXXXXXXXXXXXXXXXXXX user@host

qui correspond à ton client

alfirdaous · Le 05/06/2012, à 01:26

nesthib a écrit :

le dossier .ssh doit avoir les permissions 700, normalement tu ne devrais pas le créer à la main

drwx------  2 desktop desktop 4096 2012-06-03 14:34 .ssh/

Le proprio a le droit rwx (700)

la clé privée doit avoir les permissions 600 ou 700
la clé publique doit avoir les permissions 644 ou 744

voila pour les clefs en local:

-rw-------  1 alfirdaous alfirdaous  231 Jun  3 14:38 authorized_keys
-rw-------  1 alfirdaous alfirdaous 1766 Jun  3 08:49 id_rsa
-rw-r--r--  1 alfirdaous alfirdaous  399 Jun  3 08:49 id_rsa.pub
-rw-r--r--  1 alfirdaous alfirdaous  442 Jun  3 08:42 known_hosts

id_rsa: 600
id_rsa.pub: 644

tu ne devrais pas créer de clé pour tes clients, il devraient créer leur clé eux même (avec ssh-keygen) et te fournir la clé publique (.ssh/id_dsa.pub)

J'ajoute des utilisateurs, je suis le meme proprio, je teste seulement:

1er utilisateur: Avoir les droits admin
2eme utilisateur: Peut se connecter via x2go, pour voir l'interface graphique
3eme utilisateur: C'est celui qui se connecte pour effectuer des commandes sur le site

Note: PermitRootLogin est a OFF, et seulement ces 3 ont le droit de se connecter AllowUser user1 user2 user3

tu peux régler les autorisations de connexion, et notamment le doit d'utiliser ou non un mot de passe, et des droits par nom/groupe d'utilisateur dans le sshd_config

Desole, je l'ai pas retenu

soit tu peux ajouter la clé publique de tes clients dans authorized_keys, soit ils peuvent se connecter une première fois avec ssh-copy-id et un mot de passe

J'ai ajoute les utilisateurs, et j'ai voulu copie la clef publique vers leurs repertoire en utilisant ssh-copy-id

$ ssh-copy-id rimie@IP
/usr/bin/ssh-copy-id: ERROR: No identities found
$ cd /home/rimie
$ ls
examples.desktop
$ cd .ssh
-bash: cd: .ssh: No such file or directory

pour supprimer le doit d'un utilisateur à se connecter sur une machine, il suffit de supprimer sa clé publique du fichier authorized_keys. Tu devrais avoir une ligne de la forme :
ssh-dss XXXXXXXXXXXXXXXXXXXXXXXXX user@host
qui correspond à ton client

je vais verifier cette derniere apres success de transmission de la clef publique vers leurs repertoires

Merci a vous

Dernière modification par alfirdaous (Le 05/06/2012, à 01:29)

nesthib · Le 05/06/2012, à 02:04

ton « ERROR: No identities found » signifie que sur le client tu n'as pas de couple de clé privée/publique.

Donc, sur le client, tu devrais faire :

ssh-keygen

tu valides les champs par défaut. Cela va créer un dossier .ssh et un couple de clés.

puis tu envoies la clé (publique) sur le serveur :

ssh-copy-id rimie@ip_du_serveur

en entrant le mot de passe du compte du client sur le serveur (rimie doit avoir un compte sur le serveur avec un home)

NB. si le compte du client sur la machine client est aussi « rimie » tu peux t'affranchir de mettre le nom d'utilisateur lors de la connexion ssh :

rimie@machine_client$ ssh ip_du_serveur

alfirdaous · Le 05/06/2012, à 04:10

si je fais cette commande sur ma console je vais regenerer la clef:

ssh-keygen

alors que je veux juste copier une seule clef generee, sur des repertoires differents (differents repertoire .ssh des uilisateurs sur le serveur)

nesthib · Le 05/06/2012, à 05:33

Certes, mais en te lisant j'ai l'impression que tu confonds le client et le serveur.

Le couple clé privée/clée publique doit être chez le client, dans son dossier ${HOME_CLIENT}/.ssh/, ce qui n'est visiblement pas le cas chez toi puisque tu obtiens l'erreur que j'ai citée précédemment.
Le serveur quant-à lui possède aussi un couple de clés mais tu ne dois pas t'en occuper, il doit être généré tout seul quand tu installes openssh-server (pour info le couple de clés est dans /etc/ssh/).
Sur le serveur il n'y a donc aucune opération à effectuer et en particulier aucune clé à créer.

En utilisant ssh-copy-id depuis le client, ce script copie la clé publique (${HOME_CLIENT}/.ssh/id_rsa.pub) du client sur le serveur dans le fichier ${HOME_SERVEUR}/.ssh/authorized_keys.

Réciproquement, lors de la première connexion au serveur, la clé publique du serveur (celle qui est stockée dans le dossier /etc/ssh du serveur), est affichée chez le chez le client pour validation, puis est copiée dans le fichier ${HOME_CLIENT}/.ssh/know_hosts du client.

Le listing que tu as montré présente à la fois les fichiers id_rsa, id_rsa.pub et known_hosts qui sont typiquement des fichiers clients et le fichier authorized_keys qui, lui, est un fichier serveur.

Bien entendu un client peut également jouer le rôle de serveur et comporter tous ces fichiers, soit si les machines ont le droit de se connecter l'une sur l'autre, soit si la machine est client d'une machine A et serveur pour une machine B, mais pas dans le cas simple d'une connexion unique A → B.

Donc, si je comprends bien ce que tu veux faire, à savoir autoriser plusieurs clients A, B et C à se connecter sur une machine D, tu dois créer trois couples de clés sur chacune des machines A, B et C, et copier grâce à ssh-copy-id la clé publique de chaque client sur le serveur D (dans le fichier authorized_keys, et non dans le .ssh du serveur). Éventuellement tu peux utiliser un seul couple de clés que tu copies chez chaque client, mais je te déconseille fortement cette pratique si tu veux discriminer ces clients car il te sera impossible de révoquer l'accès à un seul de ces clients. Tu pourras soit autoriser tout le monde à se connecter, soit interdire tout le monde (et discriminer le doit d'accès sur le seul nom d'utilisateur serait une faille de sécurité). Dés lors qu'une personne a eu connaissance d'une clé privée, considère la clé comme compromise.

En espérant que cela clarifie les choses et t'aide à comprendre qui est le client et qui est le serveur dans ton réseau et donc où chaque fichier doit être (et ne pas être ! car il est absurde de mettre la clé privée du client sur le serveur).

alfirdaous · Le 05/06/2012, à 06:18

J'ai la clef chez le client:

alfirdaous est le CLIENT:

alfirdaous@ubuntu:~/.ssh$ ls
authorized_keys  id_rsa  id_rsa.pub  known_hosts

desktop est le SERVEUR:

alfirdaous@ubuntu:~$ ssh desktop@IP
Welcome to Ubuntu!

******************* ICI JE SUIS CONNECTE SANS MDP, CONNEXION DIRECT ****************************

$ clear
$ cd /home
/home$ ls

##################### LA LISTE DES UTILISATEURS ###########################
alfirdaousroot  desktop  firstuser  ftp  lost+found  rimie  testuser

####################### JE RENTRE A L'UTILISATEUR DESKTOP ######################
$ cd desktop
$ cd .ssh
$ ls
authorized_keys  test

J'espere que jusqu'au la, tout va bien.

Les autres utilisateurs crees (SONT MOI MEME), a lister:
alfirdaousroot: lui donner les droits admin => (Aura une clef)
desktop: l'utilisateur principal du serveur (compte livre par la societe qui a le serveur: Datacenter) => Aura une clef
firstuser: utilisateur normal => (Sans clef)
ftp: utilisateur des ftp => (sans clef)
rimie: utilisateur avec droits d'admin (Aura une clef)
testuser: utilisateur normal (sans clef)

alors j'aurais des utilisateur qui auront une clef, les autres non, sachant que je suis tous ces utilisateurs, autrement dit: UNE SEULE MACHINE CLIENT

Une fois je me connecte avec une clef, une autre sans clef.

NB: Cette pratique que pour apprendre bien la gestion des utiisateurs ainsi que la clef, mais dans le cas normal je vais faire 1 utilisateur:

adduser USER
passswd

PermitRootLogin no
AllowUsers USER

avec sa clef, et c tout

nesthib · Le 05/06/2012, à 06:49

OK.
Au message #3 tu semblais tester la connexion ssh depuis le serveur, c'est pourquoi cela me paraissait ambigu.

Donc, nous sommes d'accord que chaque client aura sa propre clé, et son propre home.
Ainsi, pour répondre à ta question initiale, il est extrêmement simple de supprimer l'accès à un utilisateur.
Il suffit, comme je l'ai dit plus haut, de supprimer sa clé publique du fichier .ssh/authorized_keys de son home sur le serveur (ou de supprimer le fichier entier si aucune autre clé n'y figurait). Ou, comme Nasman te l'a expliqué, d'interdire la connexion via le sshd_config.
Par exemple, si tu veux retirer le droit de se connecter par clé à rimie, tu as 2 possibilités :

supprimer la clé publique de rimie du fichier /home/rimie/.ssh/authorized_keys
Interdire l'accès à l'utilisateur rimie au niveau du sshd_config avec un DenyUsers (ou ne pas l'autoriser si un AllowUsers est présent)

La première solution est plus définitive car la clé disparaît du serveur, mais si l'utilisateur a un mot de passe il pourra toujours se connecter (et éventuellement remettre la clé)
La seconde solution demande une configuration plus poussée du serveur, mais a l'avantage d'interdire toute connexion à rimie (clé+mot de passe)

Comme je te l'expliquais dans mon premier message, tu peux faire un mix de tout cela via le sshd_config, en autorisant certains utilisateurs à se connecter par mot de passe uniquement, d'autres par clé uniquement, d'autres pas du tout. Tu peux également autoriser certains à avoir un accès sftp mais pas d'accès shell, faire des configurations par groupes d'utilisateurs etc.
pour plus de détails :

man sshd_config

Au passage, pas besoin de relancer le service ssh si tu supprimes simplement la clé. Le redémarrage du service n'est nécessaire que si le fichier de configuration sshd_config est modifié.

Je pense donc que ton problème est résolu ?

alfirdaous · Le 05/06/2012, à 07:34

Oui, merci nesthib, je vais revoir cette partie:

tu peux faire un mix de tout cela via le sshd_config, en autorisant certains utilisateurs à se connecter par mot de passe uniquement, d'autres par clé uniquement, d'autres pas du tout. Tu peux également autoriser certains à avoir un accès sftp mais pas d'accès shell, faire des configurations par groupes d'utilisateurs etc.

en la testant sur plusieurs machines, comme ca le resultat serait fiable, comme si j'ai donne access 2 plusieurs personnes.

Merci encore une fois

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 03/06/2012, à 14:19

[RESOLU]Annulation de connexion SSH pour un seul utilisateur

#2 Le 03/06/2012, à 14:21

Re : [RESOLU]Annulation de connexion SSH pour un seul utilisateur

#3 Le 03/06/2012, à 14:31

Re : [RESOLU]Annulation de connexion SSH pour un seul utilisateur

#4 Le 03/06/2012, à 14:33

Re : [RESOLU]Annulation de connexion SSH pour un seul utilisateur

#5 Le 03/06/2012, à 14:52

Re : [RESOLU]Annulation de connexion SSH pour un seul utilisateur

#6 Le 03/06/2012, à 14:59

Re : [RESOLU]Annulation de connexion SSH pour un seul utilisateur

#7 Le 03/06/2012, à 15:18

Re : [RESOLU]Annulation de connexion SSH pour un seul utilisateur

#8 Le 03/06/2012, à 15:27

Re : [RESOLU]Annulation de connexion SSH pour un seul utilisateur

#9 Le 03/06/2012, à 15:35

Re : [RESOLU]Annulation de connexion SSH pour un seul utilisateur

#10 Le 03/06/2012, à 15:41

Re : [RESOLU]Annulation de connexion SSH pour un seul utilisateur

#11 Le 03/06/2012, à 16:23

Re : [RESOLU]Annulation de connexion SSH pour un seul utilisateur

#12 Le 03/06/2012, à 18:29

Re : [RESOLU]Annulation de connexion SSH pour un seul utilisateur

#13 Le 05/06/2012, à 01:26

Re : [RESOLU]Annulation de connexion SSH pour un seul utilisateur

#14 Le 05/06/2012, à 02:04

Re : [RESOLU]Annulation de connexion SSH pour un seul utilisateur

#15 Le 05/06/2012, à 04:10

Re : [RESOLU]Annulation de connexion SSH pour un seul utilisateur

#16 Le 05/06/2012, à 05:33

Re : [RESOLU]Annulation de connexion SSH pour un seul utilisateur

#17 Le 05/06/2012, à 06:18

Re : [RESOLU]Annulation de connexion SSH pour un seul utilisateur

#18 Le 05/06/2012, à 06:49

Re : [RESOLU]Annulation de connexion SSH pour un seul utilisateur

#19 Le 05/06/2012, à 07:34

Re : [RESOLU]Annulation de connexion SSH pour un seul utilisateur

Pied de page des forums