Se connecter à votre serveur de messagerie en SSH

L’accès au shell d’un serveur cripta.to se fait par clé SSH, non par mot de passe. Une fois votre clé publique ajoutée au serveur (depuis l’écran Clés SSH du tableau de bord, ou via le générateur de clés SSH dans le navigateur), vous utilisez la clé privée correspondante pour vous connecter. Cet article montre exactement comment procéder sur chaque système d’exploitation — et traite les deux ou trois erreurs sur lesquelles presque tout le monde bute la première fois.

Dans tous les exemples, nous supposons que le fichier de clé privée que vous avez téléchargé s’appelle cripta_ssh et que votre serveur est mail.votredomaine.com. Remplacez par votre propre nom d’hôte (il figure sur la fiche du serveur dans le tableau de bord). La connexion se fait toujours en tant que root.

La clé privée est un secret. Quiconque la détient peut se connecter à votre serveur. Conservez le fichier en lieu sûr, ne l’envoyez jamais par e-mail et ne le collez jamais dans une conversation ; ne partagez que la moitié publique (.pub).

macOS

macOS est livré avec OpenSSH : il n’y a rien à installer, le Terminal suffit.

1. Déplacez la clé dans votre dossier SSH et restreignez ses permissions. SSH refuse d’utiliser une clé privée que d’autres utilisateurs de la machine pourraient lire ; l’étape chmod n’est donc pas facultative :

   mkdir -p ~/.ssh
   mv ~/Downloads/cripta_ssh ~/.ssh/cripta_ssh
   chmod 600 ~/.ssh/cripta_ssh

2. Connectez-vous :

   ssh -i ~/.ssh/cripta_ssh root@mail.votredomaine.com

3. Facultatif — ne plus saisir -i à chaque fois. Ajoutez une entrée d’hôte dans ~/.ssh/config :

   Host mail.votredomaine.com
     User root
     IdentityFile ~/.ssh/cripta_ssh

   Désormais, ssh mail.votredomaine.com suffit.

Linux

Identique à macOS — OpenSSH est soit préinstallé, soit à un paquet de distance (apt install openssh-client, dnf install openssh-clients, …).

1. Déplacez la clé et restreignez ses permissions :

   mkdir -p ~/.ssh
   mv ~/Downloads/cripta_ssh ~/.ssh/cripta_ssh
   chmod 600 ~/.ssh/cripta_ssh

2. Connectez-vous :

   ssh -i ~/.ssh/cripta_ssh root@mail.votredomaine.com

3. Entrée facultative dans ~/.ssh/config :

   Host mail.votredomaine.com
     User root
     IdentityFile ~/.ssh/cripta_ssh

Windows

Windows 10 et 11 incluent le client OpenSSH : vous pouvez donc tout faire depuis PowerShell, sans PuTTY.

1. Déplacez la clé dans votre dossier SSH :

   mkdir "$HOME.ssh" -Force
   Move-Item "$HOMEDownloadscripta_ssh" "$HOME.sshcripta_ssh"

2. Restreignez ses permissions. OpenSSH sur Windows les vérifie également : le fichier ne doit être lisible que par votre compte.

   icacls "$HOME.sshcripta_ssh" /inheritance:r /grant:r "$($env:USERNAME):R"

3. Connectez-vous :

   ssh -i "$HOME.sshcripta_ssh" root@mail.votredomaine.com

Si vous préférez PuTTY, convertissez cripta_ssh en .ppk avec PuTTYgen (Load le fichier, puis Save private key) et indiquez le .ppk à PuTTY dans Connection → SSH → Auth.

Économisez-vous l’option -i avec ssh-agent

Si vous vous connectez souvent, chargez la clé une fois dans votre agent SSH et chaque commande ssh la trouvera automatiquement :

ssh-add ~/.ssh/cripta_ssh      # macOS / Linux

Sous Windows, démarrez l’agent une fois (Start-Service ssh-agent) puis lancez ssh-add "$HOME\.ssh\cripta_ssh".

Quand ça ne marche pas

Permission denied (publickey) — le serveur n’a pas accepté votre clé. Généralement pour l’une de ces raisons :

• La clé publique n’est pas encore arrivée sur le serveur. Les modifications prennent effet à la prochaine vérification programmée de la machine ; comptez donc jusqu’à environ 15 minutes après l’ajout.
• Vous avez indiqué à -i le mauvais fichier, ou le fichier .pub (public) au lieu du fichier privé. -i attend la clé privée, c’est-à-dire le fichier sans .pub.
• Vous vous connectez avec le mauvais utilisateur. C’est toujours root@….

Unprotected private key file / bad permissions — la clé est lisible par d’autres. Relancez le chmod 600 (macOS/Linux) ou la commande icacls (Windows) des étapes ci-dessus.

Host key verification failed / « REMOTE HOST IDENTIFICATION HAS CHANGED » — vous voyez une empreinte de serveur différente de la dernière fois. C’est normal si le serveur a été reconstruit sous le même nom d’hôte : supprimez l’entrée obsolète et reconnectez-vous.

ssh-keygen -R mail.votredomaine.com

Si en revanche vous ne vous attendiez pas à ce que le serveur change, arrêtez-vous et vérifiez pourquoi avant de taper yes : c’est précisément l’avertissement qui vous protège contre une connexion à un imposteur.

Si vous perdez la clé

Il n’existe aucune « réinitialisation » pour une clé privée : elle n’a jamais existé que sur votre machine. Si vous la perdez, générez une nouvelle paire de clés, ajoutez la nouvelle clé publique depuis le tableau de bord et supprimez l’ancienne. Tant que l’accès du support cripta.to est encore activé (ou que vous disposez d’une autre clé fonctionnelle), vous ne restez jamais à la porte : c’est tout l’intérêt de conserver une seconde voie d’accès jusqu’à avoir vérifié que la première fonctionne.