Ce tuto fonctionne parfaitement sur les serveurs SSH Dropbear et OpenSSH (ce qui inclue quasiment toute les distributions Linux dont Debian et OpenWRT mais aussi OpenBSD entre autres).

L'authentification par clef publique va se servir de la cryptographie pour vérifier que l'utilisateur qui essaye de se connecter est bien la personne qu'il prétend être. Cette méthode (comme toutes les méthodes d'ailleurs) n'est pas inviolable loin de là, mais il ne suffit plus de regarder taper un mot de passe sur un clavier pour se connecter.

Comment ça marche ?

Dans un premier temps, l'utilisateur va générer un couple de clef (une privée pour lui et une publique pour la vérification de son identité). Ensuite, il va installer la clef publique sur le serveur.
A partir de maintenant, il est possible pour lui de se connecter. Pour cela il envoie par l'intermédiaire de son client SSH une demande de connexion en spécifiant qu'il va utiliser sa clef privée.
Le serveur va lui envoyer un message aléatoire qu'il va demander de signer avec sa clef privée. Le client SSH chiffre le message après que l'utilisateur ait débloqué la clef privée par l'intermédiaire d'un mot de passe, et le renvoie au serveur.
Le serveur vérifie la signature avec le clef publique et si elle correspond, autorise l'utilisateur à se connecter.
L'interêt de cette méthode réside dans le fait qu'il faille un fichier pour se connecter, le vol est nettement plus compliqué (sachant qu'il faut aussi voler le mot de passe).

Cette méthode peut sembler plus lourde car elle rajoute un intermédiaire supplémentaire, mais il existe des programmes qui gérent les clefs et on se retrouve dans un cas aussi simple qu'avant (saisie du mot de passe de la clef privée) voire même plus simple (le programme se souvient du mot de passe).

Insallation

Dropbear
Avec un serveur de type Dropbear, il n'y a rien à faire, l'authentification par clef publique est active par défaut.
Pour désactiver l'accès simple (après avoir installé ses clefs et vérifié que ça marche!) par mot de passe, il faut lancer le serveur avec l'attribut -s

Avec OpenWRT, ça se passe dans le fichier /etc/init.d/S50dropbear , la dernière ligne étant :
/usr/sbin/dropbear
à remplacer par :
/usr/sbin/dropbear -s

OpenSSH
Tout se passe dans le fichier /etc/ssh/sshd_config, normallement l'authentification par clef publique est activée par défaut, mais dans le cas contraire, ça se passe ici :

PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys

La deuxième ligne indique où trouver les clefs publiques.

Cette ligne est pour interdire l'authentification par mot de passe (je me répéte, attention!) :
PasswordAuthentication no

Les Clefs

Pour générer les clefs, le plus simple est d'utiliser la suite PuTTY (tous les outils clients SSH pour UNIX et Windows).
Pour une debian, il suffit de faire : apt-get install putty putty-tools
Et pour windows, ça se passe ici : Download page. (prendre l'installeur ou au minimun PuTTY, Pageant et PuTTYgen)

Génération des clefs 

Avec Puttygen, le bouton Generate va générer le couple clef privée/publique (pour de raisons de sécurité, il faut mettre un mot de passe pour protéger la clef privée!). Ensuite, les enregistrer.

Installation de la clef sur le serveur

Il faut faire un copier-coller du bloc commençant par ssh-rsa (ou ssh-dss selon le type de clef générée) dans le fichier ~/.ssh/authorized_keys  (~ est le répertoire home de l'utilisateur que l'on veut authentifier par clef publique). Attention, il faut faire attention à ce que des caractères parasites ne s'insèrent pas dans le fichier!

Pour des raisons de sécurité, il faut restreindre le plus possible les droits sur ce fichier, soit un droit de lecture/écriture pour l'utilisateur seulement. De même pour la clef privée.

Utilisation d'un agent SSH (pas obligatoire, loin de là)

Pour les utilisateurs devant jongler entre les sessions SSH différentes, il est difficile de se souvenir de tous les mots de passe, c'est pourquoi les agents SSH sont là pour s'en souvenir.

Un agent SSH va en fait garder en mémoire la clef privée déchiffrer pour se connecter directement au serveur SSH sans intervention de l'utilisateur.

Pageant est l'agent de la suite PuTTY, il suffit de faire "Add key" et de sélectionner sa clef privée pour qu'il la déchiffre.

Attention à la sécurité de cette solution, il ne faut pas oublier que n'importe quelle personne qui utilise votre session peut accéder sans rien demander aux serveurs!
De plus sous Windows, il est parfois possible de retrouver la clef privée déchiffrée dans le fichier de swap du disque dur (faille de sécurité de windows connue depuis des années et touchant tous les logiciels tournant sur cet OS).

Test de la connexion

Le moment de vérité!
Il faut configurer une session SSH avec PuTTY et mettre l'emplacement de la clef privée dans Connection -> SSH -> Auth pour que Pageant sache quelle clef utiliser (si Pageant ne tourne pas, PuTTY demande lui même le mot de passe de la clef privée, mais ne s'en souvient pas ensuite).

Si le client indique un message du style : Server refused our key , il faut vérifier toute la configuration ( configuration du serveur, le nom de l'utilisateur, bonne clef privée, bonne clef publique copiée-collée ).

Dans le cas contraire, le client doit indiquer directement le prompt du sytème distant et c'est gagné!

Plusieurs clefs pour un même utilisateur

Il est possible d'utiliser plusieurs clefs publiques pour un seul utilisateur, pour cela il suffit de copier-coller les autres clefs publiques sur une nouvelle ligne chaque fois dans le fichier authorized_keys .