Sécurité
scp sans password
La commande scp permet de copier un fichier d’une machine à une autre en SSH. Selon comment est configuré SSH, il faut à chaque fois redonner un password pour la copie.
Voici comment faire pour autoriser une machine A à se connecter sur une machine B et copier facilement les fichiers.
1 - Genération des clés
Sur la machine A :
$ ssh-keygen -t rsa
(je ne mets pas de passphrase)
On va ainsi avoir 2 fichiers (clé publique et clé privées) dans ~/.ssh/
2 - Autorisation de la machine A à se connecter à B
Sur la machine B:
Copier/Récupérer le fichier ~/.ssh/id_rsa.pub généré précédemment, puis le rajouter dans la liste des clés autorisées.
cat id_pub.rsa >> ~/.ssh/authorized_keys
3 - Copier les fichiers sans password.
Maintenant, on peut copier des fichiers depuis A vers B sans devoir entrer un password à chaque fois.
Préservez votre vie privée !
Article rédigé par Arnaud Rolly
Nous allons mettre en place une partition cryptée, /dev/hdb1 par exemple (première partition du disque esclave de la première nappe IDE).
Attention : les commandes modprobe, losetup et mkfs.ext3 doivent être exécutées avec le super utilisateur (root).
Avant tout, il faut s’assurer que le noyau supporte le cryptage. Normalement, soit votre noyau est compilé avec l’option, soit il faut insérer le module approprié, cryptoloop (sous une Mandrake 10.0 par exemple) :
# modprobe cryptoloop
Lire la suite ce cet article »
SSH et REMOTE HOST IDENTIFICATION HAS CHANGED
Article rédigé par Jérémy Fressard
Que faire quand on veut se connecter sur une machine distante et que ssh nous répond la phrase suivante ??
[root@ben root]# ssh root@192.168.0.206
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING : REMOTE HOST IDENTIFICATION HAS CHANGED ! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY ! Someone could be eavesdropping on you right now (man-in-the-middle attack) ! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is da:49 :f9:2c:91:2c :b1 :c9 :b4:20:41:91:56:77:2d :a7. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending key in /root/.ssh/known_hosts:11 RSA host key for 192.168.0.206 has changed and you have requested strict checking. Host key verification failed.
En fait c’est la clé publique de chiffrement du destinataire qui a changé (réinstallation de ssh par exemple). Il faut donc, tout simplement, aller supprimer la ligne correspondante de cette machine dans le fichier de son compte :
# vi .ssh/known_hosts
Puis tapper dd (suppression/couper de la ligne sous vi) sur la ligne ou il y à l’@ IP du destinataire.
Exemple en détail :
- Sur une machine B Mr.Y ré-installe le serveur ssh :
rpm -e ssh.. rpm -ivh ssh.. - Mr. X sur sa machine A essaie de s’y connecter en ssh (SACHANT QU’IL S’ETAIT DEJA CONNECTE AUPARAVANT et que son système avait donc memorisé la clé publique dans le fameux fichier known_host). Hors sur la machine distante B ssh à été reinstallé, ce serveur ssh ne peut pas avoir générer la même clé qu’auparavant (random) donc la clé qui se trouve dans le fichier known_host de Mr. X sur la machine A n’est plus la bonne !
- Et que va t’il se passer après la suppression de cette ligne ?? Lorsque Mr.X va vouloir se connecter à la machine B, le système va lui demander s’il veut enregistrer la clé publique d’un nouveau destinataire inconnu (car on a detruit la ligne correspondante) dans ton fichier knowhost. (YES/NO) Il faut bien sur mettre YES.
J’espère que ca pourra aider ceux qui débutent sous Linux.
[Kerberos] Mise en place
Article rédigé par Jérémy Fressard
Sommaire :
1. INSTALLATION DE KERBEROS 5 SUR UNE SOLARIS 9
2. CONFIGURER LE SERVEUR KDC
2.1. MODIFIER LES FICHIERS DE CONFIGURATION SUIVANTS
2.2. CREER LA BASE DE DONNEE
2.3. MODIFIER LES ACL (AUTORISATION)
2.4. LANCER LA COMMANDE KADMIN.LOCAL
2.5. DEMARRER LES DEMONS KERBEROS
2.6. LANCER KADMIN
2.7. SYNCHRONISER TOUTES LES HORLOGES
3. CONFIGURER LES MACHINES CLIENTES SOLARIS 9 ET 8
3.1. KERBERIZATION DE RLOGIN, TELNET, FTP, RSH, RCP
3.2. KERBERIZATION DU LOGIN
3.3. KERBERIZATION D’OPENSSH
4. NFS KERBERIZE SUR LES MACHINES SOLARIS 9
4.1. POUR COMMENCER DANS LA BASE DE DONNEE DU SERVEUR
4.2. ENSUITE IL FAUT CREER LA « CREDENTIAL TABLE »
4.3. RENDRE ACTIVE LA SECURITE KERBEROS POUR NFS
4.4. PARTAGE ET MONTAGE
4.4. PROBLEME NFS INDUIT PAR LA VERSION SOLARIS 8
5. SERVICES KERBERIZES SUR LES MACHINES MACOS X
5.1. TELNET KERBERIZE
5.2. FTP KERBERIZE
5.3. OBTENTION DU TICKET LORS DU LOGIN
5.4. NFS KERBERIZE
5.5. RLOGIN KERBERIZE
5.6. SSH KERBERIZE
6. SERVICES KERBERIZES SUR LES MACHINES WINDOWSNT
6.1. TELNET
6.2. FTP
6.3. NFS
7. CREATION D’UN SCRIPT POUR SIMPLIFIER LA CREATION DES PRINCIPAUX
8. SECURISER LES COMMANDES LDAP AVEC KERBEROS
8.1. INSTALLATION DE IPLANET DIRECTORY SERVER 5.1
8.2. INSTALLATION D’OPEN LDAP
[Kerberos 5] Compréhension
Article rédigé par Jérémy Fressard
1. Les points forts de Kerberos sont :
- En terme de sécurité sur le réseau :
a.Il permet d’empêcher dans un premier lieu, le transit des mots de passe en clair sur le réseau, il part du principe que le mot de passe ne doit jamais circuler sur le réseau, que ce soit en clair ou sous une forme chiffrée quelconque.
b.Il permet d’empêcher que des personnes se fassent passer pour d’autres sur le réseau. - En terme de souplesse d’utilisation, il permettra aux utilisateurs de s’authentifier une fois pour toutes lors du login. Dès lors, ils pourront utiliser tous les services d’accès à distance sans avoir à fournir à chaque fois leur login et mot de passe, mais en étant tout de même authentifiés par Kerberos de facon transparentes pour eux.
2. Principe du tiers de confiance - le KDC
Kerberos s’appuie sur deux services pour fonctionner, le serveur d’authentification, ou AS, et le service de délivrement de tickets de service, ou TGS. Ces deux services sont la clé de voûte de tout le système, ce sont eux qui font sa force, mais aussi sa principale faiblesse. Si ces deux rôles sont bien distincts dans les concepts qui sont à la base de Kerberos, il en va différemment dans la réalité. En effet, ces deux rôles complémentaires sont toujours regroupés en une même entité logicielle, appelée Centre de Distribution des Clés, ou KDC, Key Distribution Center.
Le découpage des rôles n’en est pas moins crucial dans Kerberos :
- L’AS prend en charge toute la partie authentification pure des clients. C’est lui, et lui seul, qui peut délivrer un TGT (Ticket-Granting Ticket), qui permettra ensuite à l’entité souhaitant s’authentifier de communiquer avec les autres services Kerberos.
- Le TGS, quant à lui, prend en charge les demandes d’accès aux services, une fois que les entités (qui sont en majorité des utilisateurs) se sont authentifiées une fois auprès de l’AS, et disposent donc d’un TGT.