---
tags: [note, ssh, vps, windows, yunohost, securite, Securite]
type: "note"
nature: documentation
ressource: true
univers: PERSO
projects:
  - "[[03_PROJETS/VPS-IA]]"
date: "[[01_JOURNAL/2026/2026-10-17]]"
status: active
description: "Connexion SSH par clé depuis Windows 11 sans ssh-copy-id : enchaînement PowerShell et pièges."
---
# SSH vers le VPS — connexion par clé depuis Windows 11

> Mise en œuvre de l'étape 1 du plan : [[04_NOTES/OVH/VPS-OVH_Securisation_20261016]].
> Contexte sécurité : [[04_NOTES/VPS-IA_Audit-Securite-VPS-2026-10-16]].

## Pourquoi

Le serveur subit ~2 000 tentatives de force brute par jour. Une **clé publique** rend ce type d'attaque inutile : le mot de passe n'est plus proposé, donc plus testable.

**Spécifique Windows** : la commande `ssh-copy-id` **n'existe pas** sous Windows 11 (OpenSSH Microsoft ne l'inclut pas) → on la remplace par un enchaînement PowerShell. Deux pièges à connaître :

1. ta clé porte un nom personnalisé (`id_ed25519_grk-2026`) → `ssh` ne la détecte **pas** toute seule (elle doit être déclarée) ;
2. Windows masque les extensions → le fichier `.pub` peut sembler absent.

## 1. Vérifier la paire de clés (PowerShell)

```powershell
# La clé publique existe-t-elle ?
Get-Content "$env:USERPROFILE.sshid_ed25519_grk-2026.pub"

# Si elle manque, on la régénère à partir de la clé privée :
ssh-keygen -y -f "$env:USERPROFILE.sshid_ed25519_grk-2026" `
           > "$env:USERPROFILE.sshid_ed25519_grk-2026.pub"
```

## 2. Publier la clé sur le VPS (équivalent de `ssh-copy-id`)

```powershell
$k = Get-Content "$env:USERPROFILE.sshid_ed25519_grk-2026.pub"
ssh -p 222 shizendo@datagrandest.net `
  "mkdir -p ~/.ssh; grep -qxF '$k' ~/.ssh/authorized_keys 2>/dev/null || echo '$k' >> ~/.ssh/authorized_keys; chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys; wc -l < ~/.ssh/authorized_keys"
```

- `grep -qxF` rend l'opération **idempotente** : pas de doublon si tu relances la commande.
- Ça demande le mot de passe **une dernière fois**.
- Le dernier champ affiche le nombre de clés présentes sur le serveur.

## 3. Déclarer la clé dans `~/.ssh/config`

Sans cela, `ssh` cherche `id_ed25519`, `id_rsa`… et pas ton nom personnalisé.

```
Host vps
    HostName datagrandest.net
    Port 222
    User shizendo
    IdentityFile ~/.ssh/id_ed25519_grk-2026
    IdentitiesOnly yes
```

Fichier : `C:\Users\<utilisateur>\.ssh\config` (créer le fichier s'il n'existe pas).

## 4. Tester (nouveau terminal)

```powershell
ssh vps
# attendu : connexion SANS saisie de mot de passe
```

## 5. Vérifier côté serveur

Sur le VPS, dans `/var/log/auth.log` :

```bash
grep "Accepted publickey for shizendo" /var/log/auth.log | tail -3
# attendu : une ligne par connexion réussie, avec l'empreinte ED25519 de ta clé
```

## 6. Couper le mot de passe

**Méthode retenue : le réglage YunoHost** (et non une édition manuelle de `/etc/ssh/sshd_config`, fichier **généré** donc régénérable/écrasable).

- **Webadmin** : Réglages globaux → section **SSH** → **« Authentification par mot de passe »** → désactivé.
- ou en ligne de commande : ```bash
sudo yunohost settings set security.ssh.ssh_password_authentication -v no
```

YunoHost régénère la config et exécute `sshd -t` automatiquement : rien à recharger à la main.

**Vérifier dans un second terminal** :
```bash
ssh vps                                            # clé : OK, sans mot de passe
ssh -o PreferredAuthentications=password vps       # attendu : Permission denied (publickey,password)
```

**Conservé** : `PermitRootLogin no`, le bloc `Match Group sftp.app` (mot de passe conservé pour les SFTP d'apps), et la console OVH en secours.
**Rollback** : réactiver l'interrupteur, ou `sudo yunohost settings set security.ssh.ssh_password_authentication -v yes`.

## Dépannage

| Symptôme | Cause | Correctif |
|---|---|---|
| `Permission denied (publickey,password)` | la clé n'est pas proposée | vérifier `IdentityFile` + `IdentitiesOnly yes` dans `~/.ssh/config` |
| le mot de passe est redemandé malgré la clé | mauvaise clé ou clé non publiée | `ssh -v vps` → regarder `Offering public key` |
| `UNPROTECTED PRIVATE FILE` | droits trop ouverts sur la clé privée | sous Windows : rien à faire (norme POSIX non applicable) ; côté Linux : `chmod 600` |
| refus après restauration du serveur | `authorized_keys` vidé | refaire l'étape 2 |
| connexions lentes | brute force en cours sur le port | normal : fail2ban bannit (voir plan, étape 2) |

## FAQ : le message « You have no mail. »

Affiché à chaque connexion, **sans rapport avec ta messagerie** :

- Source : `/etc/pam.d/sshd` → `session optional pam_mail.so standard noenv`. Le module cherche un fichier **mbox** classique dans `/var/mail/<utilisateur>`.
- Chez toi, Dovecot est configuré en **maildir** (`mail_location = maildir:/var/mail/%n`) : `/var/mail/shizendo` est un **dossier**, pas un fichier → pam_mail ne trouve pas de `mbox` → « You have no mail. ».
- Ta boîte `shizendo@shizendo.ovh` fonctionne (IMAP/webmail) : le message est **cosmétique**, l'option `optional` signifie aussi que PAM ignore ce module en cas de souci.

**Verdict** : rien d'anormal, aucun impact sécurité. Pour ne plus le voir : commenter la ligne `pam_mail` dans `/etc/pam.d/sshd` + `systemctl reload ssh` — mais YunoHost peut la remettre lors d'une régénération de configuration (c'est sans danger dans les deux cas).

---

→ Plan : [[04_NOTES/OVH/VPS-OVH_Securisation_20261016]] 
→ Audit : [[04_NOTES/VPS-IA_Audit-Securite-VPS-2026-10-16]] 
→ Coffre : [[04_NOTES/VPS-IA_Installation-Pass-Gestionnaire-Secrets]]