Côté client

Génération du bi-clés

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/bonbon/.ssh/id_rsa):  
Created directory '/home/bonbon/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/bonbon/.ssh/id_rsa.
Your public key has been saved in /home/bonbon/.ssh/id_rsa.pub.
The key fingerprint is:
66:11:e3:73:26:13:60:2b:8d:81:f4:32:ed:83:cc:84 bonbon@localhost.localdomain
The key's randomart image is:
+--[ RSA 2048]----+
| .... o.+        |
| ..o = o +       |
|E + = o * o      |
| + = .   B       |
|  + o   S        |
|     . o         |
|                 |
|                 |
|                 |
+-----------------+

id_rsa est la clé privée à protéger et id_rsa.pub est la clé publique à déployer.

Déploiement de la clé publique sur un serveur distant

# cat id_rsa.pub | ssh USER_DISTANT@IP_SRV_SSH "cat - >> ~/.ssh/authorized_keys"

ou

# ssh-copy-id -i /home/bonbon/.ssh/id_rsa.pub USER_DISTANT@IP_SRV_SSH

ou
Copier le contenu de la clé publique dans le authorized_keys du serveur distant.

Côté client et serveur

Il faut limiter l'accès à la clé publique (et au dossier .ssh ainsi que son contenu) en y mettant une ACL (chmod -R 700 ~/.ssh/ et chmod 600 ~/.ssh/id_* ) et aussi dans le cas ou StrictModes soit positionné à Yes dans le sshd_config.
Un autre point à vérifier au cas ou l'on utilise SELinux, c'est les contextes positionnés sur les différents fichiers/dossier (surtout au cas ou le homedirectory de l'utilisateur n'est pas /home)

cd ~
$ ll -alSFZd
drwx------. bonbon bonbon unconfined_u:object_r:user_home_dir_t:s0 ./

$ ll -lSFZ .ssh
-rw-------. bonbon bonbon unconfined_u:object_r:ssh_home_t:s0 id_rsa
-rw-------. bonbon bonbon unconfined_u:object_r:ssh_home_t:s0 id_rsa.pub