« SshAvecAfs » : différence entre les versions

De Wiki du LAMA (UMR 5127)
Aller à la navigation Aller à la recherche
 
(6 versions intermédiaires par 3 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
== Sur le client ==
== Sur le client ==


Avec kerberos, on ne peut plus utiliser des clef RSA/SSH pour se connecter sans mot de passe.
Dans /etc/ssh/ssh_config, ajouter :
On peut toujours se connecter avec mot de passe.

À la place des clefs ssh, on utilise des "tickets kerberos". Voici les instructions (pour linux et mac os, la même
chose doit être possible sous Windows).

Sous mac os, au moins jusqu'à la version 10.6, il faut commencer par installer la version ssh fournie par macports, celle d'apple n'étant pas compatible avec GSSAPI (même si l'option de configuration existe).

Malheureusement, sous linux comme sous mac os, l'utilisation de ticket kerberos n'est pas activé par défaut. Dans /etc/ssh/ssh_config,
il faut ajouter :
Host *
Host *
...
...
Ligne 7 : Ligne 16 :
GSSAPIDelegateCredentials yes
GSSAPIDelegateCredentials yes


De plus, il faut installer kerberos avec
Dans /etc/krb5.conf, vérifier que le royaume est bien connu :

apt-get install heimdal-clients

Dans /etc/krb5.conf, vérifier que le royaume est bien connu (cela évite de donner
le royaume à chaque fois que l'on se connecte, pour info le "royaume" c'est les machines
du lama qui utilisent des tickets kerberos, en gros) :
[libdefaults]
[libdefaults]
default_realm = LAMA.UNIV-SAVOIE.FR
default_realm = LAMA.UNIV-SAVOIE.FR
Ligne 27 : Ligne 42 :
kinit login_sur_lama
kinit login_sur_lama


On a alors un ticket kerberos. On peut vérifier que le ticket est encore valable
On donne son mot de passe (sur le serveur lama) et on a alors un ticket kerberos. On peut vérifier que le ticket est encore valable
avec
avec
klist
klist


Ensuite, tous les ssh marcheront sans mot de passe avec:
Ensuite, tous les ssh sur le serveur marcheront sans mot de passe avec:
ssh lama.univ-savoie.fr
ssh lama.univ-savoie.fr
ou (toujours si le login n'est pas le même)
ou (toujours si le login n'est pas le même)
ssh login@lama.univ-savoie.fr
ssh login@lama.univ-savoie.fr

RAPPEL: il faut que votre mot de passe soit transféré du codage unix dans le codage kerberos, pour cela rien de plus simple:
une connexion sur le serveur (par ssh ou en local) en tapant le mot de passe le transfert automatiquement.


== Pour chaque serveur SSH ==
== Pour chaque serveur SSH ==
Ligne 78 : Ligne 96 :
# scp www.lama.univ-savoie.fr:/tmp/d45.keytab /etc/krb5.keytab
# scp www.lama.univ-savoie.fr:/tmp/d45.keytab /etc/krb5.keytab
# chmod 600 /etc/krb5.keytab
# chmod 600 /etc/krb5.keytab

'''Note''' : pour tester, assurez-vous de renouveler votre ticket Kerberos sur votre machine client (il doit être plus récent que les modifications qui viennent d'être effectuées sur le serveur SSH).

Dernière version du 19 mars 2015 à 13:59

Sur le client

Avec kerberos, on ne peut plus utiliser des clef RSA/SSH pour se connecter sans mot de passe. On peut toujours se connecter avec mot de passe.

À la place des clefs ssh, on utilise des "tickets kerberos". Voici les instructions (pour linux et mac os, la même chose doit être possible sous Windows).

Sous mac os, au moins jusqu'à la version 10.6, il faut commencer par installer la version ssh fournie par macports, celle d'apple n'étant pas compatible avec GSSAPI (même si l'option de configuration existe).

Malheureusement, sous linux comme sous mac os, l'utilisation de ticket kerberos n'est pas activé par défaut. Dans /etc/ssh/ssh_config, il faut ajouter :

Host *
...
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

De plus, il faut installer kerberos avec

 apt-get install heimdal-clients

Dans /etc/krb5.conf, vérifier que le royaume est bien connu (cela évite de donner le royaume à chaque fois que l'on se connecte, pour info le "royaume" c'est les machines du lama qui utilisent des tickets kerberos, en gros) :

[libdefaults]
       default_realm = LAMA.UNIV-SAVOIE.FR
       forwardable = true
[realms]
       LAMA.UNIV-SAVOIE.FR = {
               kdc = lama.univ-savoie.fr
               admin_server = lama.univ-savoie.fr
       }

Vérifiez aussi dans le même fichier que "forwardable=yes"

On peut alors faire du ssh sur lama.univ-savoie.fr presque sans mot de passe:

on fait

 kinit 

ou si votre login n'est pas le même sur votre client et sur le serveur du lama

 kinit login_sur_lama

On donne son mot de passe (sur le serveur lama) et on a alors un ticket kerberos. On peut vérifier que le ticket est encore valable avec

 klist

Ensuite, tous les ssh sur le serveur marcheront sans mot de passe avec:

 ssh lama.univ-savoie.fr

ou (toujours si le login n'est pas le même)

 ssh login@lama.univ-savoie.fr

RAPPEL: il faut que votre mot de passe soit transféré du codage unix dans le codage kerberos, pour cela rien de plus simple: une connexion sur le serveur (par ssh ou en local) en tapant le mot de passe le transfert automatiquement.

Pour chaque serveur SSH

On peut vouloir se connecter sur d'autres machines au labo que le serveur du LAMA ... grâce au ticket Kerberos que l'on détient dans le royaume LAMA.UNIV-SAVOIE.FR.

On pourrait utiliser les clefs publiques/clefs privées de SSH, mais on a mieux avec Kerberos, car en plus le ticket AFS suit.

Il faut alors faire en plus, pour chaque machine, les choses suivantes :

Sur le serveur du LAMA

Le serveur SSH de d45.lama.univ-savoie.fr a besoin d'un principal qui l'identifie dans le royaume. Ce principal c'est host/d45.lama.univ-savoie.fr@LAMA.UNIV-SAVOIE.FR et il faut le créer sur le serveur du LAMA.

# kadmin -l
kadmin> add -r host/d45.lama.univ-savoie.fr@LAMA.UNIV-SAVOIE.FR
Max ticket life [1 week]:
Max renewable life [1 month 1 day]:
Principal expiration time [never]:
Password expiration time [never]:
Attributes []:
kadmin> ext_keytab -k /tmp/d45.keytab host/d45.lama.univ-savoie.fr
kadmin> quit

Ne pas oublier de virer à la fin le fichier /tmp/d45.keytab (c'est une clef secrète) !

Sur la machine à kerbériser

Il faut activer le support Kerberos sur d45.lama.univ-savoie.fr dans SSH ; dans /etc/ssh/sshd_config :

# Kerberos options
KerberosAuthentication yes
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
GSSAPIStrictAcceptorCheck no # ça c'est super important

Et il faut lui donner son principal secret :

# scp www.lama.univ-savoie.fr:/tmp/d45.keytab /etc/krb5.keytab
# chmod 600 /etc/krb5.keytab

Note : pour tester, assurez-vous de renouveler votre ticket Kerberos sur votre machine client (il doit être plus récent que les modifications qui viennent d'être effectuées sur le serveur SSH).