QuickSilver 1.0b18
osx2x 2.2.0
DesktopManager 0.5.1
SSHTunnel Manager 1.0
SSHLogin 1.2

Packages
Icones grises T610 (60.3 ko)
Postfix-1.1.11 (3.9 Mo)
fink-0.10.0-cvs (8.9 Mo)
MySql 3.23.52 (3.8 Mo)

Un T610 gris dans Salling Clicker et iSync
Postfix en SMTP local
Améliorer le ftp de Jaguar
Les scripts de démarrage
Compiler PHP/Support GD

Trucs & astuces

Dock(3) Général(11) (Path) Finder(7) Terminal(2)

iApps(3) Word(1) Internet(1) Système(1)

Lorsqu’un client SSH se connecte au serveur, il essaye plusieurs méthode d’authentification, principalement l’échange de clés et la saisie du mot de passe si celle-ci est permise (oui par défaut, même pour root). Une clé consiste en deux fichiers, l’un étant appelé clé privée, et l’autre clé publique. ces deux fichiers portent la même base de nom, mais la clé publique se termine par ".pub". Les clés sont en général stockées dans le répertoire /.ssh/ (le désigne votre répertoire de base). Appelé sans arguments, ssh essayera d’utiliser par défaut, et si elle existe la clé /.ssh/id_dsa (.pub pour la publique). Il est possible de préciser une autre clé via l’argument -i.

Les clés sont générées grâce à la commande ssh-keygen qui, après nous avoir posé quelques questions, créera les deux fichiers constituants la clé privée et la clé publique. La passphrase sera nécéssaire pour débloquer une clé, demanière à ce que même si quelqu’un entre en possession de votre clé privée, il lui soit nécéssaire de connaître la passphrase pour l’utiliser. Il est possible de ne pas en préciser, au détriment de la sécurité. Choisissez donc une phrase assez longue (10/20 caractères) dont vous vous rappelerez. N’hésitez pas à mélanger les majuscules et les minuscules.

Vous disposez à présent d’une clé que vous allez pouvoir utiliser pour vos connexions SSH. La clé publique (.pub) peut être distribuée sans risques, la clé privée par contre doit impérativement rester secrète.

Le principe est que le compte de la machine distante sur laquelle vous vous connectez doit avoir connaissance de votre clé publique pour pouvoir vous authentifier. Pour cela SSH prévoit un fichier qui stockera toute les clés publiques des utilisateurs pouvant se connecter, il s’agit du fichier /.ssh/authorized_keys2 (le fichier authorized_keys, si vous l’avez, est réservé à l’usage du protocole 1 de ssh, cette différentiation est ammenée à disparaître). Un moyen commode donc pour ajouter votre clé à celles d’un compte distant est de l’envoyer... en ssh ! Vous devez bien sûr disposer du mot de passe de l’utilisateur distant, donc être déjà en mesure de vous connecter :

Ceci a pour effet d’ajouter le contenu de id_dsa.pub au fichier distant authorized_keys2. A présent, vous devriez pouvoir vous connecter en utilisant votre clé :

Et là vous me dites "C’est génial, avant je tapais un mot de passe court, maintenant j’ai carrément une phrase à taper !", et je vous répond que c’est le prix de la sécurité, mais ne partez pas tout de suite, ce n’est pas fini, nous allons étudier un moyen de nous éviter la saisie de cette passphrase.

C’est notre sauveur, nous allons lui déléguer la gestion des clés, et il s’occupera de nous demander les passphrases une bonne fois pour toutes. Pour cela, il faut déjà lancer l’agent :

Interessant n’est il pas ? l’agent nous retourne des lignes de shell à éxécuter si nous voulons l’utiliser. En effet, les connexions ssh que nous allons lancer devront connaitre ces information pour utiliser l’agent, alors pourquoi l’agent n’exporte t’il pas lui même ces valeurs ? Eh bien parceque s’il nous les donne, on peut les retenir, et donc les utiliser pour les futurs shell que nous allons ouvrir. Le but final étant de saisir la/les passphrase à l’ouverture du premier terminal. Pour éxécuter ces lignes, on peut utiliser la souris et copier/coller dans une ligne de commande :

Un moyen commode de lancer l’agent tout en exportant les variables est de l’éxécuter comme ceci :

(Notez que les guillemets sont inversés, il s’agit de backquotes, la même touche que la livre £ sur le clavier d’un Macintosh)

Maintenant que l’agent est lancé, et l’environnement exporté, il ne sert à rien sans connaitre les clés, qu’il faut lui fournir avec l’outil ssh-add :

A présent, toute authentification nécéssitant l’usage d’une clé gérée par l’agent ne demandera plus de passphrase. On peut ajouter autant de clé que l’on veut dans l’agent, pour chaque clé, l’agent tentera de les déverrouiller avec les passphrase fournies précédemment, donc si vous utilisez toujours la même passphrase, elle ne vous sera demandée qu’une fois.

C’est mieux non ? Quoique un peu lourd à l’ouverture du premier terminal de devoir lancer l’agent n’est-ce pas ? Coninuez donc à lire, cette dernière partie est consacrée à keychain, originaire de la distribution Linux gentoo, il va s’occuper de lancer l’agent quand besoin est et y ajouter les clés voulues.

Le principe de cet outil est de vérifier si un agent tourne sur le système, et si ce n’est pas le cas, il le lance et y ajoute les clés passées en argument. Pour l’installer, commencez par le télécharger, et après l’avoir décompressé, copiez le fichier keychain dans un répertoire standard de votre système :

Sa mise en oeuvre est très simple, il s’agit juste de deux lignes dans votre fichier .bash_profile (bash), .zprofile (zsh) ou .cshrc (compatible csh).

Si votre shell est celui par défaut de MacOS X, il s’agit de tcsh, vous devez donc insérer ceci dans votre fichier /.cshrc :

Si vous utilisez un autre shell, compatible bash, ces lignes sont pour vous :

Respectez scrupuleusement la syntaxe de ces lignes (la deuxième commence par un "."). Vous pouvez en outre préciser autant de clé que vous le désirez après la commande keychain, j’ai juste précisé la clé par défaut dans l’exemple.

Ouvrez un nouveau terminal :

Voilà ce que cela donne chez moi, je dispose de deux clés, une personelle id_dsa et une professionelle pour mes clients clients avec la même passphrase, que keychain ne me demande qu’une fois puisqu’elle lui permet de déverrouiller les deux clés.

C’est tout ! A présent, vous êtes sûrs de ne taper qu’une fois vos passphrase dans une session, et vos connexions restent sécurisée (aucun mot de passe ou passphrase est stocké dans un fichier, le mécanisme est fiable).