A voir également:
- Connection ssh
- Gmail connection - Guide
- Hotmail connection - Guide
- Facebook connection - Guide
- Ssh download - Télécharger - Divers Web & Internet
- Connection chromecast - Guide
11 réponses
kelux
Messages postés
3074
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
20 janvier 2023
432
25 nov. 2004 à 09:21
25 nov. 2004 à 09:21
Hello :)
Tu peux utiliser PuTTy, avec tous ses outils tu peux te connecter à partir d'un pc sous windows à un serveur SSH sous linux (Authentification par échange de clés, etc...)
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
Luc L.
[Gentoo] enfin :Þ
Tu peux utiliser PuTTy, avec tous ses outils tu peux te connecter à partir d'un pc sous windows à un serveur SSH sous linux (Authentification par échange de clés, etc...)
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
Luc L.
[Gentoo] enfin :Þ
ok.
On ne peut pas se connecter par pages web?
De plus a quoi correspond l'empreinte de la clé.
Sur putty j'ai juste a mettre la clé public?
Merci
On ne peut pas se connecter par pages web?
De plus a quoi correspond l'empreinte de la clé.
Sur putty j'ai juste a mettre la clé public?
Merci
[Dal]
Messages postés
6194
Date d'inscription
mercredi 15 septembre 2004
Statut
Contributeur
Dernière intervention
11 octobre 2024
1 092
25 nov. 2004 à 13:34
25 nov. 2004 à 13:34
Tu as besoin d'un client SSH pour te connecter (Internet Explorer ou Netscape ne savent pas faire).
Tu paramètres juste Putty pour accéder à l'adresse IP de ton serveur RedHat avec utilisation du protocole SSH.
Pas besoin de te casser la tête avec les certificats, c'est transparent pour une utilisation de base de SSH.
Ce que tu as généré sur ton serveur SSH c'est la clé publique et la clé privée de ton *serveur*.
Lors de la première connection, Putty va recevoir (automatiquement) la clé publique du serveur et va te demander de confirmer l'acceptation du certificat. Tu peux vérifier à cette occasion que le certificat en question correspond bien (compare l'empreinte, c'est à celà qu'elle sert). Celui-ci sera stocké en cache par Putty et tu n'auras plus ce message lors de tes prochaines connexions.... à moins que tu changes le couple clé privée/publique de ton serveur. Tu auras alors un avertissement de sécurité qui te préviendra que le certificat a changé et te demandera d'accepter le nouveau.
Le certificat public du serveur est utilisé pour crypter les communications et tu peux, une fois la session établie, tranquillement taper ton login et mot de passe (sauf si quelqu'un regarde par dessus ton épaule :P).
Saisit ton nom d'utilisateur et ton mot de passe. Celà devrait fonctionner avec un utilisateur normal, et avec root aussi sauf si la connexion root a été interdite dans le paramétrage de ton serveur SSH (ce qui est une bonne mesure).
Une fois loggé, tu disposes d'un shell distant sur ton serveur RedHat (SSH c'est pour "Secured Shell"). Tu peux y lancer des commandes, comme si tu étais directement au clavier de ton serveur.
Quant à la clé privée du serveur... tu la gardes sur le serveur !
Dal
Tu paramètres juste Putty pour accéder à l'adresse IP de ton serveur RedHat avec utilisation du protocole SSH.
Pas besoin de te casser la tête avec les certificats, c'est transparent pour une utilisation de base de SSH.
Ce que tu as généré sur ton serveur SSH c'est la clé publique et la clé privée de ton *serveur*.
Lors de la première connection, Putty va recevoir (automatiquement) la clé publique du serveur et va te demander de confirmer l'acceptation du certificat. Tu peux vérifier à cette occasion que le certificat en question correspond bien (compare l'empreinte, c'est à celà qu'elle sert). Celui-ci sera stocké en cache par Putty et tu n'auras plus ce message lors de tes prochaines connexions.... à moins que tu changes le couple clé privée/publique de ton serveur. Tu auras alors un avertissement de sécurité qui te préviendra que le certificat a changé et te demandera d'accepter le nouveau.
Le certificat public du serveur est utilisé pour crypter les communications et tu peux, une fois la session établie, tranquillement taper ton login et mot de passe (sauf si quelqu'un regarde par dessus ton épaule :P).
Saisit ton nom d'utilisateur et ton mot de passe. Celà devrait fonctionner avec un utilisateur normal, et avec root aussi sauf si la connexion root a été interdite dans le paramétrage de ton serveur SSH (ce qui est une bonne mesure).
Une fois loggé, tu disposes d'un shell distant sur ton serveur RedHat (SSH c'est pour "Secured Shell"). Tu peux y lancer des commandes, comme si tu étais directement au clavier de ton serveur.
Quant à la clé privée du serveur... tu la gardes sur le serveur !
Dal
asevere
Messages postés
13084
Date d'inscription
lundi 28 janvier 2002
Statut
Webmaster
Dernière intervention
3 février 2022
426
25 nov. 2004 à 14:55
25 nov. 2004 à 14:55
Salut vous! :)
Juste une petite précision sur:
Lors de la première connection, Putty va recevoir (automatiquement) la clé publique du serveur et va te demander de confirmer l'acceptation du certificat. Tu peux vérifier à cette occasion que le certificat en question correspond bien (compare l'empreinte, c'est à celà qu'elle sert). Celui-ci sera stocké en cache par Putty et tu n'auras plus ce message lors de tes prochaines
L'utilisation normal du protocol SSH, dans le meilleur des mondes, la clé publique du serveur ne doit jamais etre acceptée lors de la demande au moment de la connexion!
Elle doit être transmise à l'avance, de main a main (he voui, mails a proscrire aussi ;) )
Mais bon, c'est du top sécurisé, et beaucoup moins pratique :)
...Mana mana
Tutudutu...
Juste une petite précision sur:
Lors de la première connection, Putty va recevoir (automatiquement) la clé publique du serveur et va te demander de confirmer l'acceptation du certificat. Tu peux vérifier à cette occasion que le certificat en question correspond bien (compare l'empreinte, c'est à celà qu'elle sert). Celui-ci sera stocké en cache par Putty et tu n'auras plus ce message lors de tes prochaines
L'utilisation normal du protocol SSH, dans le meilleur des mondes, la clé publique du serveur ne doit jamais etre acceptée lors de la demande au moment de la connexion!
Elle doit être transmise à l'avance, de main a main (he voui, mails a proscrire aussi ;) )
Mais bon, c'est du top sécurisé, et beaucoup moins pratique :)
...Mana mana
Tutudutu...
[Dal]
Messages postés
6194
Date d'inscription
mercredi 15 septembre 2004
Statut
Contributeur
Dernière intervention
11 octobre 2024
1 092
25 nov. 2004 à 17:45
25 nov. 2004 à 17:45
Je ne suis pas sûr que Putty permette de le faire (si tu sais comment faire, je suis preneur... peut être en bidouillant le registre.. hmmff). Je n'ai pas vu cette fonctionnalité dans les versions de Putty que j'ai utilisées.
Maintenant, la comparaison de l'empreinte est là pour t'éviter cette manipulation et présente une bonne sécurité si le client SSH vérifie correctement la cohérence du certificat... non ?
Dal
Maintenant, la comparaison de l'empreinte est là pour t'éviter cette manipulation et présente une bonne sécurité si le client SSH vérifie correctement la cohérence du certificat... non ?
Dal
asevere
Messages postés
13084
Date d'inscription
lundi 28 janvier 2002
Statut
Webmaster
Dernière intervention
3 février 2022
426
>
[Dal]
Messages postés
6194
Date d'inscription
mercredi 15 septembre 2004
Statut
Contributeur
Dernière intervention
11 octobre 2024
25 nov. 2004 à 21:27
25 nov. 2004 à 21:27
Logiquement, c'est réalisable, puTTy est une bon prog :)
Modifier la base de registre est sans doute la solution puisque par défault puTTy ne cré pas de fichier de configuration.
Mais comme tu le dit, et coomme je le dis plus bas, c'est effectivement pas le plus important (Enfin si l'utilisateur verifie la clé oralement avec l'admin).
Ceci dit, pour quelque chose de vraiment fiable, je pencherai plus pour transmettre la clé part un autre support. Soit papier pour pouvoir la confirmer, soit numerique pour l'enregistrer.
...Mana mana
Tutudutu...
Modifier la base de registre est sans doute la solution puisque par défault puTTy ne cré pas de fichier de configuration.
Mais comme tu le dit, et coomme je le dis plus bas, c'est effectivement pas le plus important (Enfin si l'utilisateur verifie la clé oralement avec l'admin).
Ceci dit, pour quelque chose de vraiment fiable, je pencherai plus pour transmettre la clé part un autre support. Soit papier pour pouvoir la confirmer, soit numerique pour l'enregistrer.
...Mana mana
Tutudutu...
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Ok merci pour tt ces réponses mais il y a un truk ki me chagrine.
Imaginons que qq1 prenne putty sur 1 pc qu'il tappe mon @de mon serveur et la putty lui demande l'acceptation du certificat.Puis il a plus qu'a trouver mon mot de pass et mon login.
Alors ou intervient les clefs?
Y a un truk que j'ai pas du comprenrdre.
Merci
Imaginons que qq1 prenne putty sur 1 pc qu'il tappe mon @de mon serveur et la putty lui demande l'acceptation du certificat.Puis il a plus qu'a trouver mon mot de pass et mon login.
Alors ou intervient les clefs?
Y a un truk que j'ai pas du comprenrdre.
Merci
Normalement, si quelqu'un a ton login et ton mot de pass tu es foutu de toute facon. Peut-etre on peut ajouter quelque chose avec ssh en sorte qu'une seule machine aura acces a ton server mais a ma connaissance ce n'est pas le comportement par default. Je crois tu peux restreindre l'acces a ton serveur ssh en utilisant les fichiers /etc/hosts.allow et /etc/hosts.deny. De cette facon il est possible de dire que seulement certains clients avec des numeros IP specifiques on acces a ton serveur.
On peut faire la meme chose au niveau firewall en utilsant iptables.
C'est une couche supplementaire.
Le grand avantage de ssh (par rapport a telnet) est que le login et le mot de pass ne voyagent pas ouvertement mais de facon crypte sur le reseau. Donc les logiciels de genre sniffer qui captent le traffique internet ne permettent plus d'obtenir le mot de pass! De plus, toute info, texte, telechargement qui passe par ta connexion est crypte.
Les cles servent pour empecher qu'une autre machine decrypte les infos qui sont reserve a toi. Si tu transferes quelchose (un fichier, text, etc.) de ton serveur vers ton client le serveur utilise pour le cryptage la cles publique de ton client (qu'il a du recevoir avec ta connection). Pour decrypter il faut avoir la cles privee de ton client. Comme cette cles ne quitte jamais ton ordinateur client il est impossible pour quelqu'un ailleur qui aurait capte ton traffique de decrypter ton message.
Pour un transfer inverse de ton client vers le serveurs ca marche pareil.
Ton client utilise la cles publique de ton serveur pour crypter le message et ceci garantie que seulement ce serveur peut decrypter le message en utilisant sa cles privee.
On peut faire la meme chose au niveau firewall en utilsant iptables.
C'est une couche supplementaire.
Le grand avantage de ssh (par rapport a telnet) est que le login et le mot de pass ne voyagent pas ouvertement mais de facon crypte sur le reseau. Donc les logiciels de genre sniffer qui captent le traffique internet ne permettent plus d'obtenir le mot de pass! De plus, toute info, texte, telechargement qui passe par ta connexion est crypte.
Les cles servent pour empecher qu'une autre machine decrypte les infos qui sont reserve a toi. Si tu transferes quelchose (un fichier, text, etc.) de ton serveur vers ton client le serveur utilise pour le cryptage la cles publique de ton client (qu'il a du recevoir avec ta connection). Pour decrypter il faut avoir la cles privee de ton client. Comme cette cles ne quitte jamais ton ordinateur client il est impossible pour quelqu'un ailleur qui aurait capte ton traffique de decrypter ton message.
Pour un transfer inverse de ton client vers le serveurs ca marche pareil.
Ton client utilise la cles publique de ton serveur pour crypter le message et ceci garantie que seulement ce serveur peut decrypter le message en utilisant sa cles privee.
[Dal]
Messages postés
6194
Date d'inscription
mercredi 15 septembre 2004
Statut
Contributeur
Dernière intervention
11 octobre 2024
1 092
25 nov. 2004 à 20:05
25 nov. 2004 à 20:05
[Dal] <--- d'accord avec kmf
Sinon... rjcb
Imaginons que qq1 prenne putty sur 1 pc qu'il tappe mon @de mon serveur et la putty lui demande l'acceptation du certificat.Puis il a plus qu'a trouver mon mot de pass et mon login.
Oui, dans le fonctionnement de base de SSH, c'est ce qui arrive... d'où l'intérêt d'interdire la connexion SSH à root.
Alors ou intervient les clefs?
Y a un truk que j'ai pas du comprenrdre.
Comme indiqué dans mon post, la session qui s'établit au moyen du certificat public permet le chiffrement des informations échangées avec le serveur disposant de la clé privée correspondante.
J'ajouterai aux commentaires de kmf que, de plus, si la procédure d'installation de la clé publique est sécurisée (comme l'indique asevere ou par vérification de l'empreinte), celà est sensé te "garantir" que le serveur auquel tu es connecté est bien celui auquel tu souhaites accéder (et que personne n'essaye de se mettre entre toi et le serveur à ton insu - attaque "man in the middle").
Bon, sinon, bonne nouvelle, il y a des méthodes alternatives d'authentification avec ton serveur SSH. Celle que tu as en tête existe : une authentification basée sur des certificats.
Là c'est l'utilisateur qui crée une paire de clés (les clés que tu as créées, ce sont des clés pour ton serveur ou pour un utilisateur ?).
La clé publique de l'utilisateur est dans le répertoire /home/user/.ssh/ de l'utilisateur et la clé privée sur ta machine distante (elle même protégée par un mot de passe). Il te faudra utiliser Pageant en connection avec Putty (disponible à la même URL). Pageant chargera le certificat de la clé privée en mémoire, après que tu l'aies débloqué avec ton mot de passe associé au certificat, pour permettre la connexion via Putty. Il n'y a plus de login et de mot de passe correspondant au compte unix à taper.
Vois http://dsg.port.ac.uk/~garry/dev/ssh-cert-login.html pour plus d'infos sur la création des clés, et sur où et comment les placer, le nom des fichiers, les permissions,... Tu peux aussi utiliser PuTTYgen pour générer les clés.
Enfin, si tu veux vraiment interdire complètement toute tentative d'authentification intéractive login/mot de passe... je n'ai jamais fait çà ... mais il me semble qu'il faudrait désactiver l'utilisation de pam avec SSH. Celà doit être dans /etc/pam.d/ssh
Il y a aussi des options dans sshd_config (voir man sshd_config), mais je ne suis pas convaincu.
Condamner cette méthode d'authenfication signifie que tu as intérêt à avoir un accès physique à ton serveur si tu perds ton certificat... c'est à toi de voir.
Dal
Sinon... rjcb
Imaginons que qq1 prenne putty sur 1 pc qu'il tappe mon @de mon serveur et la putty lui demande l'acceptation du certificat.Puis il a plus qu'a trouver mon mot de pass et mon login.
Oui, dans le fonctionnement de base de SSH, c'est ce qui arrive... d'où l'intérêt d'interdire la connexion SSH à root.
Alors ou intervient les clefs?
Y a un truk que j'ai pas du comprenrdre.
Comme indiqué dans mon post, la session qui s'établit au moyen du certificat public permet le chiffrement des informations échangées avec le serveur disposant de la clé privée correspondante.
J'ajouterai aux commentaires de kmf que, de plus, si la procédure d'installation de la clé publique est sécurisée (comme l'indique asevere ou par vérification de l'empreinte), celà est sensé te "garantir" que le serveur auquel tu es connecté est bien celui auquel tu souhaites accéder (et que personne n'essaye de se mettre entre toi et le serveur à ton insu - attaque "man in the middle").
Bon, sinon, bonne nouvelle, il y a des méthodes alternatives d'authentification avec ton serveur SSH. Celle que tu as en tête existe : une authentification basée sur des certificats.
Là c'est l'utilisateur qui crée une paire de clés (les clés que tu as créées, ce sont des clés pour ton serveur ou pour un utilisateur ?).
La clé publique de l'utilisateur est dans le répertoire /home/user/.ssh/ de l'utilisateur et la clé privée sur ta machine distante (elle même protégée par un mot de passe). Il te faudra utiliser Pageant en connection avec Putty (disponible à la même URL). Pageant chargera le certificat de la clé privée en mémoire, après que tu l'aies débloqué avec ton mot de passe associé au certificat, pour permettre la connexion via Putty. Il n'y a plus de login et de mot de passe correspondant au compte unix à taper.
Vois http://dsg.port.ac.uk/~garry/dev/ssh-cert-login.html pour plus d'infos sur la création des clés, et sur où et comment les placer, le nom des fichiers, les permissions,... Tu peux aussi utiliser PuTTYgen pour générer les clés.
Enfin, si tu veux vraiment interdire complètement toute tentative d'authentification intéractive login/mot de passe... je n'ai jamais fait çà ... mais il me semble qu'il faudrait désactiver l'utilisation de pam avec SSH. Celà doit être dans /etc/pam.d/ssh
Il y a aussi des options dans sshd_config (voir man sshd_config), mais je ne suis pas convaincu.
Condamner cette méthode d'authenfication signifie que tu as intérêt à avoir un accès physique à ton serveur si tu perds ton certificat... c'est à toi de voir.
Dal
asevere
Messages postés
13084
Date d'inscription
lundi 28 janvier 2002
Statut
Webmaster
Dernière intervention
3 février 2022
426
25 nov. 2004 à 21:13
25 nov. 2004 à 21:13
Bonche, je me suis un peu planter dans le protocole.
Pour le warning il faut normlement demander une confirmation de la clé publique à l'administrateur.
Cette clé publique est utilisée pour echanger une clé privée de session, à partir e là, tout est chiffré.
Pour une authentification sans mot de passe ou plus exactement en RSA, le client génére aussi un couple de clés
Il conserve sa clé publique, et place sa clé privée dans son /home/.ssh/ du serveur sous le nom de autorized_keys
C'est à ce niveau là qu'il faut faire gaffe, cette clé doit absolument etre placé sur le serveur par un moyen autre que le réseau ;)
Lors de la création du couple de clé, un mot de psse est demandé pour chiffrer la clé privée (il sera demandé a la connexion) si ce mot de passe est vide, la connexion par ssh ne demande rien, la clé n'est plus protégé que par ses droits (600 absolument! Tout comme la clé privée du serveur, la publique peut elle etre en 644).
Dans ce cas, lors de la connexion, il y a un "challenge" le serveur envoie un message crypté a l'aide de la clé publique de l'utilisateur si l'utilisateur peut renvoyer la réponse correcte au serveur (il a nécéssairement la clé privée dans ce cas.) la connexion est alors accéptée :)
...Mana mana
Tutudutu...
Pour le warning il faut normlement demander une confirmation de la clé publique à l'administrateur.
Cette clé publique est utilisée pour echanger une clé privée de session, à partir e là, tout est chiffré.
Pour une authentification sans mot de passe ou plus exactement en RSA, le client génére aussi un couple de clés
Il conserve sa clé publique, et place sa clé privée dans son /home/.ssh/ du serveur sous le nom de autorized_keys
C'est à ce niveau là qu'il faut faire gaffe, cette clé doit absolument etre placé sur le serveur par un moyen autre que le réseau ;)
Lors de la création du couple de clé, un mot de psse est demandé pour chiffrer la clé privée (il sera demandé a la connexion) si ce mot de passe est vide, la connexion par ssh ne demande rien, la clé n'est plus protégé que par ses droits (600 absolument! Tout comme la clé privée du serveur, la publique peut elle etre en 644).
Dans ce cas, lors de la connexion, il y a un "challenge" le serveur envoie un message crypté a l'aide de la clé publique de l'utilisateur si l'utilisateur peut renvoyer la réponse correcte au serveur (il a nécéssairement la clé privée dans ce cas.) la connexion est alors accéptée :)
...Mana mana
Tutudutu...
asevere
Messages postés
13084
Date d'inscription
lundi 28 janvier 2002
Statut
Webmaster
Dernière intervention
3 février 2022
426
25 nov. 2004 à 21:22
25 nov. 2004 à 21:22
A noter qu'avec une authentification en RSA avec ou sans mot de passe, il n'est nécéssaire de bloquer l'utilisateur root, ça ne pose aucun probleme de sécuritée :)
Dans tout les cas, les couples de clés ne servent qu'a authentifier le serveur dans le cas d'une configuration par défaut, le serveur et l'utilisateur dans le cas du RSA, une fois authentifiés, des clés de session sont générée qui servent a crypter les informations, les deux methodes sont aussi fiable l'une que l'autre, la methode RSA permet plus de souplesse :)
...Mana mana
Tutudutu...
Dans tout les cas, les couples de clés ne servent qu'a authentifier le serveur dans le cas d'une configuration par défaut, le serveur et l'utilisateur dans le cas du RSA, une fois authentifiés, des clés de session sont générée qui servent a crypter les informations, les deux methodes sont aussi fiable l'une que l'autre, la methode RSA permet plus de souplesse :)
...Mana mana
Tutudutu...
Excuses moi, asevere, mais a mon avis tu t'es presque completement trompe pour deux choses:
1) Il conserve sa clé publique, et place sa clé privée dans son /home/.ssh/ du serveur sous le nom de autorized_keys
C'est l'inverse et il conserve sa cle privee (fichier "id_rsa") et place sa cle publique (fichier "id_rsa.pub") dans son /home/.ssh/ su serveur sous le nom de autorized_keys. Pour ca je suis sur car je l'ai fait je l'utilise.
La cle privee ne doit jamais quitter la machine sur la quelle elle a ete cree. On peut se creer de nouvelles paires de cles differentes pour chaque machine ou on travaille et on n'a pas besoin des transmettre la cle privee.
Le fichier "autorized_keys" peut justement contenir plusieures cles publiques pour permettre l'acces depuis plusieurs clients differents sur lesquelles il y a des cles privees uniques et differentes n'ayant jamais quittees leur clients.
C'est à ce niveau là qu'il faut faire gaffe, cette clé doit absolument etre placé sur le serveur par un moyen autre que le réseau
C'est bien d'eviter la transmission par reseau mais c'est loin d'etre indispensable. Un "scp" fait tres bien l'affaire. Bien sur ca ce serait en mode avec mot de pass et non par l'authentification directe qu'on veut justement mettre en place.
Mais encore plus important, il n'y a meme pas danger!! On ne transmet que la cles publique. Meme si cette cle publique tombe dans de mauvaises mains ce n'est pas grave. Une tierce personne pourrait techniquement l'utiliser pour donner a toi l'acces a sa propre machine a lui mais en aucune cas elle aurait acces a des machines-serveurs sur lequelles tu as depose cette cle publique. Pour ca il faut absolument avoir ta cle privee originale qui ne doit pas quitter ton client.
La seule facon de compromettre ton compte sur le serveur (sans craquer l'algorithme de cryptage) serait de voler la cle privee sur ta machine cliente par piratage complet ou cambriolage chez toi. Si ca arrive il faut le plus rapidement effacer la cle publique associe dans le fichier "autorized_keys" du serveur pour couper l'acces au serveur. Cependant ce scenario ne depend pas de la transmission par reseau ou non de la cle publique.
Par contre ou il faut faire gaffe c'est une situation avec plusieurs clients, qui sont aussi serveurs.
Exemple: Chez toi a la maison il y a l'ordinateur A connecte a l'internet avec lequel tu peux acceder a un ordinateur B a distance. Apres il te faut acceder a un autre ordinateur C mais qui est derrier un firewall (peut-etre gere par l'ordinateur B) tel que la connection A-C n'est pas possible. Il faut passer par l'intermediaire de B.
Tu crees sur A une paire de cles privee/publique et tu mets la cle publique dans le "autorized_keys" a B. Jusqu'ici c'est bon et tu peux acceder a B. Maintenant pour acceder a C on pourrait envisager de mettre la meme cle publique (cree sur A) aussi sur C. Mais ca ne fonctionne pas parce que la cle privee qui se trouve sur A n'est pas diponible sur B. On pourrait la copier sur B mais c'est la ou il y aurait le danger. De toute facon il ne faut pas faire comme ca. La solution consiste simplement a recreer (avec la commande "ssh-keygen" en linux) sur B une nouvelle paire de cles et mettre la version publique de cette nouvelle cle sur C et ca roule. On n'a jamais transmis une cle privee d'une facon quelconque, reseau ou autre.
1) Il conserve sa clé publique, et place sa clé privée dans son /home/.ssh/ du serveur sous le nom de autorized_keys
C'est l'inverse et il conserve sa cle privee (fichier "id_rsa") et place sa cle publique (fichier "id_rsa.pub") dans son /home/.ssh/ su serveur sous le nom de autorized_keys. Pour ca je suis sur car je l'ai fait je l'utilise.
La cle privee ne doit jamais quitter la machine sur la quelle elle a ete cree. On peut se creer de nouvelles paires de cles differentes pour chaque machine ou on travaille et on n'a pas besoin des transmettre la cle privee.
Le fichier "autorized_keys" peut justement contenir plusieures cles publiques pour permettre l'acces depuis plusieurs clients differents sur lesquelles il y a des cles privees uniques et differentes n'ayant jamais quittees leur clients.
C'est à ce niveau là qu'il faut faire gaffe, cette clé doit absolument etre placé sur le serveur par un moyen autre que le réseau
C'est bien d'eviter la transmission par reseau mais c'est loin d'etre indispensable. Un "scp" fait tres bien l'affaire. Bien sur ca ce serait en mode avec mot de pass et non par l'authentification directe qu'on veut justement mettre en place.
Mais encore plus important, il n'y a meme pas danger!! On ne transmet que la cles publique. Meme si cette cle publique tombe dans de mauvaises mains ce n'est pas grave. Une tierce personne pourrait techniquement l'utiliser pour donner a toi l'acces a sa propre machine a lui mais en aucune cas elle aurait acces a des machines-serveurs sur lequelles tu as depose cette cle publique. Pour ca il faut absolument avoir ta cle privee originale qui ne doit pas quitter ton client.
La seule facon de compromettre ton compte sur le serveur (sans craquer l'algorithme de cryptage) serait de voler la cle privee sur ta machine cliente par piratage complet ou cambriolage chez toi. Si ca arrive il faut le plus rapidement effacer la cle publique associe dans le fichier "autorized_keys" du serveur pour couper l'acces au serveur. Cependant ce scenario ne depend pas de la transmission par reseau ou non de la cle publique.
Par contre ou il faut faire gaffe c'est une situation avec plusieurs clients, qui sont aussi serveurs.
Exemple: Chez toi a la maison il y a l'ordinateur A connecte a l'internet avec lequel tu peux acceder a un ordinateur B a distance. Apres il te faut acceder a un autre ordinateur C mais qui est derrier un firewall (peut-etre gere par l'ordinateur B) tel que la connection A-C n'est pas possible. Il faut passer par l'intermediaire de B.
Tu crees sur A une paire de cles privee/publique et tu mets la cle publique dans le "autorized_keys" a B. Jusqu'ici c'est bon et tu peux acceder a B. Maintenant pour acceder a C on pourrait envisager de mettre la meme cle publique (cree sur A) aussi sur C. Mais ca ne fonctionne pas parce que la cle privee qui se trouve sur A n'est pas diponible sur B. On pourrait la copier sur B mais c'est la ou il y aurait le danger. De toute facon il ne faut pas faire comme ca. La solution consiste simplement a recreer (avec la commande "ssh-keygen" en linux) sur B une nouvelle paire de cles et mettre la version publique de cette nouvelle cle sur C et ca roule. On n'a jamais transmis une cle privee d'une facon quelconque, reseau ou autre.
Un copier-coller de "man ssh":
The file $HOME/.ssh/authorized_keys lists the public keys that are permitted for logging in. When the user logs in, the ssh program tells the
server which key pair it would like to use for authentication. The server checks if this key is permitted, and if so, sends the user (actually
the ssh program running on behalf of the user) a challenge, a random number, encrypted by the user's public key. The challenge can only be
decrypted using the proper private key. The user's client then decrypts
the challenge using the private key, proving that he/she knows the private key but without disclosing it to the server.
The file $HOME/.ssh/authorized_keys lists the public keys that are permitted for logging in. When the user logs in, the ssh program tells the
server which key pair it would like to use for authentication. The server checks if this key is permitted, and if so, sends the user (actually
the ssh program running on behalf of the user) a challenge, a random number, encrypted by the user's public key. The challenge can only be
decrypted using the proper private key. The user's client then decrypts
the challenge using the private key, proving that he/she knows the private key but without disclosing it to the server.
asevere
Messages postés
13084
Date d'inscription
lundi 28 janvier 2002
Statut
Webmaster
Dernière intervention
3 février 2022
426
>
kmf
25 nov. 2004 à 23:28
25 nov. 2004 à 23:28
Voui, bon effectivement j'ai pas fait attention, je suis un poil fatigué en fin de journée...
Effectivement il y a la solution SCP, mais SCP c'est un peu SSH quand même ;) si tu n'as pas ta clé sur le serveur, a moins de commencer par une config standard, de demander a chaque utilisateurs de transferer leurs clés, puis de refaire la configuration, tu n'as pas de protocole pour transferer les clés de manires securisée.
Bref, pour les droits, c'est une recommendation, c'est dans le man aussi, s'il y a des protocols pour lesquel c'est une bonne idée de suivre les recommandations, c'est bien ceux qui concernent la sécuritée ;)
...Mana mana
Tutudutu...
Effectivement il y a la solution SCP, mais SCP c'est un peu SSH quand même ;) si tu n'as pas ta clé sur le serveur, a moins de commencer par une config standard, de demander a chaque utilisateurs de transferer leurs clés, puis de refaire la configuration, tu n'as pas de protocole pour transferer les clés de manires securisée.
Bref, pour les droits, c'est une recommendation, c'est dans le man aussi, s'il y a des protocols pour lesquel c'est une bonne idée de suivre les recommandations, c'est bien ceux qui concernent la sécuritée ;)
...Mana mana
Tutudutu...
Je suis un peu perdu avec tt les authentification:
Il y a jsute avec le login et le mot de passe
et le système de clé ou l'on peut ou pas mettre un mot de pass et login une fois que le serveur a été authentifié.
J'ai vu dans un forum, avec les clef qu'il fallait se promener avec sa clef publique pour pouvoir se conncter depuis n'importe quel endroit sur son serveur.
Pour générer les clef sur mon serveur j'ai fait ssh-keygen et il m'a crée les clef et donné une empreinte.
Merci
Il y a jsute avec le login et le mot de passe
et le système de clé ou l'on peut ou pas mettre un mot de pass et login une fois que le serveur a été authentifié.
J'ai vu dans un forum, avec les clef qu'il fallait se promener avec sa clef publique pour pouvoir se conncter depuis n'importe quel endroit sur son serveur.
Pour générer les clef sur mon serveur j'ai fait ssh-keygen et il m'a crée les clef et donné une empreinte.
Merci
[Dal]
Messages postés
6194
Date d'inscription
mercredi 15 septembre 2004
Statut
Contributeur
Dernière intervention
11 octobre 2024
1 092
26 nov. 2004 à 11:31
26 nov. 2004 à 11:31
Salut rjcb,
La crypto c'est pas simple hein ? Hehehe, plus sérieusement.. celà te semblera moins abstrait dès que tu commencera à l'utiliser.
Il y a jsute avec le login et le mot de passe
et le système de clé ou l'on peut ou pas mettre un mot de pass et login une fois que le serveur a été authentifié.
Les types d'authentification que j'ai cités sont :
- pam avec ssh (login/mot de passe),
- certificats clients
Tu peux les faire fonctionner simultanément ou les désactiver séparément. Il y a d'autres méthodes (citées dans "man sshd_config"), mais je ne les ai pas essayées... et je ne pense pas qu'elles correspondent à ce que tu cherches.
J'ai vu dans un forum, avec les clef qu'il fallait se promener avec sa clef publique pour pouvoir se conncter depuis n'importe quel endroit sur son serveur.
C'est faux (ou mal exprimé). Comme on te le répète c'est sur ta machine Windows (ton client d'après l'énoncé de ton problème) que tu dois charger ta clé privée. Avec la suite de logiciels Putty, le module qui se charge de celà s'appelle Pageant (en revanche, si tu veux te promener avec la clé publique du *serveur*, tu peux le faire,... ou plus simplement avec son empreinte).
Celà signifie que si tu veux avoir une utilisation itinérante de ta connexion SSH au serveur RedHat, avec des ordinateurs clients divers et variés, et utiliser ce mode d'authentification, tu dois te balader avec ta clé *privée* d'utilisateur et l'installer successivement sur ces différentes machines (et désinstaller après, en vérifiant que tout est bien effacé).
Une meilleure solution pourrait consister à te balader avec une clé USB, sur laquelle tu as Pageant, Putty, ta clé *privée* d'utilisateur et la clé *publique* du serveur. Le concepteur de Putty te dira que cette solution n'est pas non plus tout à fait sûre, en raison de la façon dont Windows gère la mémoire, le swap, etc. (une fois débloquée par la saisine du mot de passe, la clé privée décryptée est chargée en mémoire par Pageant... vois http://the.earth.li/~sgtatham/putty/0.56/htmldoc/Chapter9.html#S9.5).
Il y a des boites qui développent des produits commerciaux qui stockent les certificats dans des puces (sur des cartes, avec des lecteurs de cartes associés), des Micro-circuits, ou sur des clés USB "sécurisées" (avec des logiciels spécifiques qui les pilotent). Certains de ces produits ont obtenu une certification en France dans le cadre du Décret 2002-535 délivrée par la DCSSI, http://www.ssi.gouv.fr/fr/politique_produit/catalogue/index.html http://www.ssi.gouv.fr/fr/confiance/certificats.html .. enfin, comme le dit la DCSSI, la "certification" ne suffit pas à te protéger, si ton système n'est pas sécurisé.. la valeur de cette certification est toute relative.
En en plus... OpenSSH c'est gratuit :)
Dal
La crypto c'est pas simple hein ? Hehehe, plus sérieusement.. celà te semblera moins abstrait dès que tu commencera à l'utiliser.
Il y a jsute avec le login et le mot de passe
et le système de clé ou l'on peut ou pas mettre un mot de pass et login une fois que le serveur a été authentifié.
Les types d'authentification que j'ai cités sont :
- pam avec ssh (login/mot de passe),
- certificats clients
Tu peux les faire fonctionner simultanément ou les désactiver séparément. Il y a d'autres méthodes (citées dans "man sshd_config"), mais je ne les ai pas essayées... et je ne pense pas qu'elles correspondent à ce que tu cherches.
J'ai vu dans un forum, avec les clef qu'il fallait se promener avec sa clef publique pour pouvoir se conncter depuis n'importe quel endroit sur son serveur.
C'est faux (ou mal exprimé). Comme on te le répète c'est sur ta machine Windows (ton client d'après l'énoncé de ton problème) que tu dois charger ta clé privée. Avec la suite de logiciels Putty, le module qui se charge de celà s'appelle Pageant (en revanche, si tu veux te promener avec la clé publique du *serveur*, tu peux le faire,... ou plus simplement avec son empreinte).
Celà signifie que si tu veux avoir une utilisation itinérante de ta connexion SSH au serveur RedHat, avec des ordinateurs clients divers et variés, et utiliser ce mode d'authentification, tu dois te balader avec ta clé *privée* d'utilisateur et l'installer successivement sur ces différentes machines (et désinstaller après, en vérifiant que tout est bien effacé).
Une meilleure solution pourrait consister à te balader avec une clé USB, sur laquelle tu as Pageant, Putty, ta clé *privée* d'utilisateur et la clé *publique* du serveur. Le concepteur de Putty te dira que cette solution n'est pas non plus tout à fait sûre, en raison de la façon dont Windows gère la mémoire, le swap, etc. (une fois débloquée par la saisine du mot de passe, la clé privée décryptée est chargée en mémoire par Pageant... vois http://the.earth.li/~sgtatham/putty/0.56/htmldoc/Chapter9.html#S9.5).
Il y a des boites qui développent des produits commerciaux qui stockent les certificats dans des puces (sur des cartes, avec des lecteurs de cartes associés), des Micro-circuits, ou sur des clés USB "sécurisées" (avec des logiciels spécifiques qui les pilotent). Certains de ces produits ont obtenu une certification en France dans le cadre du Décret 2002-535 délivrée par la DCSSI, http://www.ssi.gouv.fr/fr/politique_produit/catalogue/index.html http://www.ssi.gouv.fr/fr/confiance/certificats.html .. enfin, comme le dit la DCSSI, la "certification" ne suffit pas à te protéger, si ton système n'est pas sécurisé.. la valeur de cette certification est toute relative.
En en plus... OpenSSH c'est gratuit :)
Dal
