Outils pour utilisateurs

Outils du site


services:accès_à_distance

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
Prochaine révision Les deux révisions suivantes
services:accès_à_distance [Wed Sep 2 14:48:05 2009]
gege2061 Demande de précisions
services:accès_à_distance [Tue Jan 10 22:21:36 2012]
fifou Infos SSHFP DNS
Ligne 8: Ligne 8:
  
 ===== SSH ===== ===== SSH =====
-FIXME Pourquoi changer le port ssh ? [[http://​fr.wikipedia.org/​wiki/​Nmap | nmap]] est capable de détecter le services quelque soit le port utilisé. 
  
-Deux contraintes :+==== Précautions d'​usage ====
  
-  * Validation des accès par clef publique UNIQUEMENT ! +Selon votre distribution, ​le serveur SSH est fourni dans un paquet nommé ''​ssh-server''​ ou ''​openssh-server'',​ qu'il vous suffit ​d'installer. Pour pouvoir accéder à votre serveur depuis l'​Internet,​ vous devrez définir une [[réseau:​routeur:​redirections de port|redirection de port]] pour le TCP 22.
-  * Déplacer ​le port d'accès du port 22 vers un port arbitraire choisi par vous !+
  
-Le reste... c'est de la routine;-)+Il est parfois recommandé de modifier le port d'écoute du serveur SSH (au niveau du routeur en cas de NAT, directement sur le serveur sinon). En effet, le port standard, TCP 22, est souvent l'​objet d'​attaques par force brute. Ces attaques sont cependant peu dangereuses si vous avez un bon mot de passe, et peuvent être bloquées avec des logiciels comme [[sécurité:​fail2ban]].
  
-===== SNMP =====+On recommande également d'​interdire à ''​root''​ de se connecter directement (option de configuration ''​PermitRootLogin''​) :​ en effet, un tel nom d'​utilisateur générique permet à un attaquant de n'​avoir à deviner que le mot de passe. Sachez également que OpenSSH propose un mécanisme d'​identification par clef publique, bien plus résistante que les mots de passe.
  
-Ici c'est la solution ​lourde ​qui permet d'utiliser des clicouillomètres graphiquesMais dans tout les cas il faut sécuriser ​l'​accès ​SNMP par un canal de chiffrement authentifié... et là mine de rien SSH est pas mal non plus.+==== Aparté concernant les enregistrements DNS SSHFP ==== 
 + 
 +La relation de confiance établie entre un client et un serveur SSH repose sur la vérification de l'​empreinte publique du serveur, exposée par ce dernier lorsqu'​une demande de connexion SSH survient. Normalement,​ il faudrait prendre le temps de calculer cette empreinte sur le serveur (avec l'​option -r de la commande ssh-keygen) afin de la comparer avec celle qui est proposée par l'​invite de commande, côté client. Si tout va bien et que l'​utilisateur valide, l'​hôte de destination est inscrit dans le fichier ~/​.ssh/​known_hosts du client qui n'aura plus à se soucier de contrôler l'​identité du serveur sauf si ce dernier réinitialise sa clef pour une raison ou pour une autre. Si cette vérification n'est pas faite avec sérieux, des attaques du type "man in the middle"​ pourront fonctionner et permettre à un tiers de récupérer nos accès au serveur. 
 + 
 +Pour effectuer ce premier contrôle, tous les moyens sont bons : 
 + 
 +    * Appeler l'​administrateur du serveur SSH et lui demander l'​empreinte ; 
 +    * Recevoir cette empreinte par e-mail ; 
 +    * Valider la comparaison sans se soucier de ces bêtises de Geek... 
 + 
 +Traditionnellement, ​c'​est ​plutôt ​la dernière ​solution qui est retenue ; il n'y a donc aucun contrôle effectué par le client et nous tombons dans les travers énoncés plus tôt. Heureusement,​ il existe un mécanisme pour faciliter la vérification de la clef : le protocole DNS permet d'exposer les empreintes publiques du serveur dans ses enregistrements SSHFPDe son côté, l'​option VerifyHostKeyDNS=yes du client SSH demandera au "​resolver DNS" local l'​empreinte de clef qui va bien pour la comparer avec celle retournée par le serveur SSH. 
 + 
 +Les empreintes peuvent être calculées de la façon suivante : 
 + 
 +<​code>​ 
 +# ssh-keygen -r machine 
 +machine IN SSHFP 1 1 26s7o07k725r27o2s166567s09np3620q9s95442 
 +machine IN SSHFP 2 1 1rs02s9k838r68sr13nn9qp6s6r16q6930p4nsnp 
 + 
 +"​machine"​ représente ​dans cet exemple le nom de l'hôte qui autorise un accès ​SSH et pour lequel ​un enregistrement ​de type A existe aussi. 
 +</​code>​ 
 + 
 +Il reste à les ajouter à la zone DNS adaptée pour obtenir ce résultat lors de 
 +la première connexion d'un client au serveur : 
 + 
 +<​code>​ 
 +    tintin@moulinsart:​~$ ssh -o VerifyHostKeyDNS=yes phil@machine.example.org -p 443 
 +    The authenticity of host '​[machine.example.org]:​443 ([77.23.45.67]:​22)'​ can't be established. 
 +    RSA key fingerprint is 64:​64:​67:​38:​14:​99:​0d:​b9:​53:​b7:​bd:​9e:​87:​64:​e1:​f4. 
 +--> Matching host key fingerprint found in DNS. 
 +    Are you sure you want to continue connecting (yes/no)? yes 
 +</​code>​ 
 + 
 +===== SNMP =====
  
-Cela reste une solution lourde ... juste pour clicouiller ​dans les coins... donc on verra ça plus tard ! hein ! Je laisse le clavier aux spécialiste de la chose si il y en a !+Ici c'est la solution lourde ​qui permet d'​utiliser des outils graphiquesMais dans tout les cas il faut sécuriser l'​accès SNMP par un canal de chiffrement authentifié… comme un canal SSHCela reste une solution lourde dédiée aux outils graphiques.
  
services/accès_à_distance.txt · Dernière modification: Tue Jan 10 23:11:27 2012 par exca