Par Claire Vernet — 22 avril 2026
Piège du drop-in : sur Bookworm, la directive PasswordAuthentication peut aussi être redéfinie dans un fichier de /etc/ssh/sshd_config.d/*.conf (par exemple 50-cloud-init.conf si tu as utilisé Pi Imager). Vérifie avec grep -ri PasswordAuthentication /etc/ssh/ qu’une autre ligne ne te contredit pas. Sinon, tu penses avoir désactivé l’auth par mot de passe alors qu’elle est toujours active.
Ne ferme pas ta session en cours avant de vérifier qu’une nouvelle connexion fonctionne avec la clé dans un second terminal. Si tu te loques dehors par erreur de config, la seule solution est de remettre la carte SD dans un PC et d’éditer manuellement /etc/ssh/sshd_config.
fail2ban : bloquer les brutes
sudo apt install fail2ban -yLa configuration par défaut (maxretry = 3 échecs en 10 minutes = ban 10 minutes) est raisonnable pour un usage maison. Pas besoin d’y toucher pour commencer. fail2ban surveille le journal systemd (ou /var/log/auth.log selon la config) et bloque les IP suspectes via nftables sur Debian 12 Bookworm (avec un fallback iptables pour la rétrocompatibilité).
Vie quotidienne en SSH : les outils qui changent tout
~/.ssh/config : arrêter de taper des adresses
Au lieu de taper ssh claire@bureau-serveur.local chaque fois, crée un alias dans ~/.ssh/config sur ton ordinateur :
Host bureau
HostName bureau-serveur.local
User claire
IdentityFile ~/.ssh/id_ed25519
ServerAliveInterval 60
# ForwardAgent yes : à activer uniquement pour les hôtes 100% de confiance
# (un hôte compromis peut utiliser tes clés SSH)Maintenant, ssh bureau suffit. Le ServerAliveInterval 60 envoie un ping toutes les 60 secondes pour éviter que la connexion ne se coupe après quelques minutes d’inactivité (certains routeurs tuent les connexions TCP idle).
tmux : garder les sessions en vie
Sans tmux, si ta connexion Wi-Fi tombe ou si tu fermes ton laptop, le processus que tu as lancé sur le Pi meurt avec la session SSH. Avec tmux, la session continue de tourner sur le Pi même si tu es déconnecté. Tu la retrouves exactement où tu l’as laissée en te reconnectant.
# Installer tmux
sudo apt install tmux -y
# Créer une session nommée
tmux new -s mon-projet
# ... travailler normalement ...
# Se détacher (la session continue en arrière-plan)
# Ctrl+B, puis D
# Se rattacher plus tard
tmux attach -t mon-projet
# Lister les sessions en cours
tmux lsSans tmux, quand tu fermes ton laptop, ton process meurt. Avec tmux, il continue. C’est cette différence qui fait qu’un Pi serveur en est vraiment un.
Transférer des fichiers : scp et rsync
Pas besoin de FTP, pas besoin de clé USB, pas besoin de client lourd. Tout passe par la même connexion SSH :
# Copier un fichier vers le Pi
scp script.py bureau:~/projets/
# Copier un fichier depuis le Pi
scp bureau:~/logs/app.log ./
# Synchroniser un dossier complet (rsync, plus malin que scp)
rsync -avz --progress ./mon-projet/ bureau:~/projets/mon-projet/rsync est mon outil préféré parce qu’il ne transfère que les fichiers modifiés. Quand tu développes un script Python en local et que tu le testes sur le Pi, un rsync après chaque modification prend une seconde au lieu de recopier tout le dossier. Le -avz active le mode archive (préserve les permissions), verbose (affiche ce qui se passe) et compression (accélère le transfert).
Questions fréquentes
Puis-je accéder à mon Raspberry Pi depuis l’extérieur de chez moi ?
Oui, mais pas en ouvrant bêtement le port 22 sur ta box. La bonne approche est un VPN : installe WireGuard sur le Pi, importe le profil sur ton smartphone ou laptop, et tu accèdes à tout ton réseau domestique comme si tu étais chez toi. Alternative grand public : Tailscale (gratuit pour usage personnel, configuration en 5 minutes).
Que faire si ssh nom-du-pi.local ne fonctionne pas ?
Trois causes typiques : (1) Windows antérieur à la version 1803 ne supporte pas mDNS nativement — utilise l’adresse IP directe, (2) ton réseau d’entreprise bloque le multicast, (3) Avahi n’est pas actif sur le Pi (vérifie avec sudo systemctl status avahi-daemon). La solution de repli : trouver l’IP du Pi dans l’interface DHCP de ta box, ou scanner le réseau avec nmap -sn 192.168.1.0/24.
fail2ban suffit-il à sécuriser mon Pi si je l’expose à Internet ?
Non, c’est une couche parmi d’autres. La combinaison minimale : authentification par clé uniquement (pas de mot de passe), fail2ban pour bloquer les tentatives de brute force, et idéalement un changement de port SSH (de 22 vers 2222 par exemple) pour éviter le bruit des scans automatiques. Pour une vraie exposition Internet, ajoute un VPN comme WireGuard plutôt que d’exposer SSH directement.
Ma session SSH se coupe toute seule au bout de quelques minutes
Certains routeurs tuent les connexions TCP inactives après 5 à 10 minutes. Solution côté client : ajouter ServerAliveInterval 60 dans ~/.ssh/config. Cela envoie un paquet keep-alive chaque minute pour maintenir la connexion. Sur un réseau mobile ou en déplacement, utilise Mosh (Mobile Shell) qui survit aux changements de réseau et aux coupures de Wi-Fi.
Quelle différence entre ssh-keygen -t ed25519 et -t rsa ?
Ed25519 est l’algorithme moderne recommandé depuis OpenSSH 6.5 (2014) : clés plus courtes, signature plus rapide, meilleure résistance cryptographique. RSA reste compatible avec tous les serveurs anciens mais nécessite au moins 3072 bits en 2026 pour rester sûr. Pour un Pi et des serveurs modernes : Ed25519 sans hésitation.
Quand headless ne suffit pas
Deux cas où on branche quand même un écran : le débogage d’un problème réseau (le Pi ne se connecte plus au Wi-Fi, donc SSH ne marche pas non plus), et les projets multimédia où l’écran est le produit final (kiosque, retrogaming, media center). Dans ces cas, le Pi sert de machine à afficher, pas de serveur invisible.
Pour un dépannage ponctuel sans écran, il existe une solution intermédiaire : brancher un câble Ethernet entre le Pi et ton ordinateur en direct (pas via la box). Le Pi obtient une adresse en link-local (169.254.x.x) et tu peux t’y connecter via ssh toncompte@raspberrypi.local même sans Wi-Fi. C’est le dernier recours avant de sortir la carte SD.
Piège classique que j’ai vécu 4-5 fois : quand tu reflashes la carte SD d’un Pi qui a gardé le même hostname, la clé SSH serveur change. Ton client refuse la connexion avec un WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED. La commande à retenir : ssh-keygen -R nom-du-pi.local pour virer l’ancienne entrée, puis reconnexion normale.
Le guide ultime du Raspberry Pi donne plus de contexte sur les cas d’usage où le headless est recommandé par défaut, et ceux où un écran a du sens. Si tu veux aller plus loin dans la sécurisation de ton Pi exposé sur Internet, la prochaine étape logique est d’installer WireGuard pour un accès VPN plutôt que de laisser le port 22 ouvert au monde.
Mes huit Raspberry Pi tournent tous à la maison sans clavier, sans souris, sans écran branché dessus. Le seul moment où j’ai physiquement touché un clavier sur un Pi récemment, c’était quand j’ai dû remplacer une carte SD grillée il y a quatre mois. Le reste du temps, tout se pilote depuis mon laptop, en SSH. Ce mode d’administration « headless » est plus rapide à configurer que l’option avec écran, plus propre, et c’est surtout celui qui correspond à la réalité d’un Pi qui tourne dans un coin en serveur permanent.
Si tu viens de flasher ta carte SD en suivant le guide d’installation Raspberry Pi OS, tu as normalement activé SSH dans les paramètres avancés de Pi Imager. Ce tuto part de là et couvre tout ce qui se passe après : première connexion, découverte du Pi sur le réseau, transfert de fichiers, sessions persistantes avec tmux, et les bases de sécurité que je considère non négociables.
Pourquoi headless par défaut
Brancher un écran et un clavier sur un Pi serveur, c’est pratique pour le premier boot et la phase d’apprentissage. Passé ces 15 minutes, tu peux tout débrancher. Le Pi tourne seul dans son coin, tu t’y connectes depuis n’importe quel ordinateur du réseau. Un Pi qui sert de serveur (Home Assistant, Pi-hole, NAS, caméra de surveillance) n’a pas besoin d’interface graphique. Lui en imposer une, c’est 200 à 400 Mo de RAM consommés selon le modèle, plus un compositeur Wayland (labwc depuis Bookworm en 2023, devenu standard sur tous les modèles depuis novembre 2024) qui tourne en arrière-plan sur le CPU et le GPU.
En mode headless avec Raspberry Pi OS Lite (la version sans bureau), le système tient autour de 260 Mo de RAM au repos. Sur un Pi 4 avec 4 Go, ça laisse environ 3,7 Go disponibles pour tes services. Avec le bureau graphique complet (labwc + Pixel), il reste plutôt 3,3-3,5 Go. Sur un Pi Zero 2 W avec ses 512 Mo, c’est la différence entre un serveur qui tient et un serveur qui swap en permanence.
Première connexion SSH
Le Pi est branché, la LED verte clignote, il est quelque part sur ton réseau local. Ouvre un terminal sur ton ordinateur habituel (Terminal sur macOS et Linux, PowerShell ou Windows Terminal sur Windows 11) et tape :
ssh toncompte@nom-du-pi.localRemplace toncompte par le nom d’utilisateur que tu as choisi dans Pi Imager et nom-du-pi par le hostname. Si tu as nommé ton Pi « bureau-serveur », ça donne ssh claire@bureau-serveur.local. La première connexion te demande d’accepter l’empreinte du serveur (tape yes), puis de saisir ton mot de passe (qui ne s’affiche pas pendant la saisie, comportement normal).
Si tu vois le prompt toncompte@nom-du-pi:~ $, tu es connecté. Tout ce que tu tapes ici s’exécute sur le Pi, pas sur ton ordinateur. Première commande rituelle :
sudo apt update && sudo apt upgrade -ySi .local ne fonctionne pas
Le suffixe .local s’appuie sur le protocole mDNS (RFC 6762). Ça fonctionne nativement sur macOS (via Bonjour), sur la plupart des Linux récents (via Avahi), et sur Windows 10+ depuis les builds 2018+. Si ça ne marche pas chez toi, deux alternatives :
- Trouver l’IP dans ta box : connecte-toi à l’interface web de ta box (souvent 192.168.1.1 ou 192.168.0.1), cherche la section « Appareils connectés » ou « DHCP Leases ». Le Pi apparaît avec son hostname et une adresse IP du type 192.168.1.42. Utilise cette IP directement :
ssh toncompte@192.168.1.42. - Scanner le réseau local : si tu as
nmapinstallé, un scan rapide trouve tous les Pi du réseau :
nmap -sn 192.168.1.0/24 | grep -B2 "Raspberry"Le plus simple à moyen terme : attribuer une IP fixe au Pi via les réglages DHCP de ta box. Comme ça, l’adresse ne change jamais, et tu n’as plus à la chercher.
Sécuriser l’accès SSH (pas optionnel)
Un Pi accessible en SSH avec un mot de passe, même long, est vulnérable aux attaques par force brute dès qu’il est exposé à Internet. Aucun FAI français (Free, Orange, SFR, Bouygues) n’ouvre le port 22 par défaut sur les box domestiques : elles sont en NAT, donc ton Pi n’est pas joignable depuis l’extérieur tant que tu n’as pas configuré une redirection de port. Mais si tu ouvres un jour le port 22 (pour y accéder depuis le travail ou en vacances), ton Pi sera attaqué par des bots dans les minutes qui suivent. Mieux vaut durcir la configuration dès maintenant, tant que c’est facile.
Passer aux clés SSH
Sur ton ordinateur (pas sur le Pi), génère une paire de clés si tu n’en as pas encore :
ssh-keygen -t ed25519 -C "claire@laptop"Accepte l’emplacement par défaut (~/.ssh/id_ed25519). Choisis une passphrase ou laisse vide (j’utilise une passphrase personnellement, mais c’est un choix). Ensuite, copie la clé publique sur le Pi. Sur macOS et Linux :
ssh-copy-id toncompte@nom-du-pi.localSur Windows PowerShell (OpenSSH natif n’inclut pas ssh-copy-id) :
type $env:USERPROFILE.sshid_ed25519.pub | ssh toncompte@nom-du-pi.local "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"Teste que la connexion passe sans mot de passe : ssh toncompte@nom-du-pi.local. Si le prompt apparaît directement (ou avec juste la passphrase de la clé), c’est bon. Désactive alors l’authentification par mot de passe côté Pi :
sudo nano /etc/ssh/sshd_config
# Trouver la ligne : #PasswordAuthentication yes
# La remplacer par : PasswordAuthentication no
# Sauver (Ctrl+O, Enter), quitter (Ctrl+X)
sudo systemctl reload ssh # reload > restart : ne coupe pas les sessions activesPiège du drop-in : sur Bookworm, la directive PasswordAuthentication peut aussi être redéfinie dans un fichier de /etc/ssh/sshd_config.d/*.conf (par exemple 50-cloud-init.conf si tu as utilisé Pi Imager). Vérifie avec grep -ri PasswordAuthentication /etc/ssh/ qu’une autre ligne ne te contredit pas. Sinon, tu penses avoir désactivé l’auth par mot de passe alors qu’elle est toujours active.
Ne ferme pas ta session en cours avant de vérifier qu’une nouvelle connexion fonctionne avec la clé dans un second terminal. Si tu te loques dehors par erreur de config, la seule solution est de remettre la carte SD dans un PC et d’éditer manuellement /etc/ssh/sshd_config.
fail2ban : bloquer les brutes
sudo apt install fail2ban -yLa configuration par défaut (maxretry = 3 échecs en 10 minutes = ban 10 minutes) est raisonnable pour un usage maison. Pas besoin d’y toucher pour commencer. fail2ban surveille le journal systemd (ou /var/log/auth.log selon la config) et bloque les IP suspectes via nftables sur Debian 12 Bookworm (avec un fallback iptables pour la rétrocompatibilité).
Vie quotidienne en SSH : les outils qui changent tout
~/.ssh/config : arrêter de taper des adresses
Au lieu de taper ssh claire@bureau-serveur.local chaque fois, crée un alias dans ~/.ssh/config sur ton ordinateur :
Host bureau
HostName bureau-serveur.local
User claire
IdentityFile ~/.ssh/id_ed25519
ServerAliveInterval 60
# ForwardAgent yes : à activer uniquement pour les hôtes 100% de confiance
# (un hôte compromis peut utiliser tes clés SSH)Maintenant, ssh bureau suffit. Le ServerAliveInterval 60 envoie un ping toutes les 60 secondes pour éviter que la connexion ne se coupe après quelques minutes d’inactivité (certains routeurs tuent les connexions TCP idle).
tmux : garder les sessions en vie
Sans tmux, si ta connexion Wi-Fi tombe ou si tu fermes ton laptop, le processus que tu as lancé sur le Pi meurt avec la session SSH. Avec tmux, la session continue de tourner sur le Pi même si tu es déconnecté. Tu la retrouves exactement où tu l’as laissée en te reconnectant.
# Installer tmux
sudo apt install tmux -y
# Créer une session nommée
tmux new -s mon-projet
# ... travailler normalement ...
# Se détacher (la session continue en arrière-plan)
# Ctrl+B, puis D
# Se rattacher plus tard
tmux attach -t mon-projet
# Lister les sessions en cours
tmux lsSans tmux, quand tu fermes ton laptop, ton process meurt. Avec tmux, il continue. C’est cette différence qui fait qu’un Pi serveur en est vraiment un.
Transférer des fichiers : scp et rsync
Pas besoin de FTP, pas besoin de clé USB, pas besoin de client lourd. Tout passe par la même connexion SSH :
# Copier un fichier vers le Pi
scp script.py bureau:~/projets/
# Copier un fichier depuis le Pi
scp bureau:~/logs/app.log ./
# Synchroniser un dossier complet (rsync, plus malin que scp)
rsync -avz --progress ./mon-projet/ bureau:~/projets/mon-projet/rsync est mon outil préféré parce qu’il ne transfère que les fichiers modifiés. Quand tu développes un script Python en local et que tu le testes sur le Pi, un rsync après chaque modification prend une seconde au lieu de recopier tout le dossier. Le -avz active le mode archive (préserve les permissions), verbose (affiche ce qui se passe) et compression (accélère le transfert).
Questions fréquentes
Puis-je accéder à mon Raspberry Pi depuis l’extérieur de chez moi ?
Oui, mais pas en ouvrant bêtement le port 22 sur ta box. La bonne approche est un VPN : installe WireGuard sur le Pi, importe le profil sur ton smartphone ou laptop, et tu accèdes à tout ton réseau domestique comme si tu étais chez toi. Alternative grand public : Tailscale (gratuit pour usage personnel, configuration en 5 minutes).
Que faire si ssh nom-du-pi.local ne fonctionne pas ?
Trois causes typiques : (1) Windows antérieur à la version 1803 ne supporte pas mDNS nativement — utilise l’adresse IP directe, (2) ton réseau d’entreprise bloque le multicast, (3) Avahi n’est pas actif sur le Pi (vérifie avec sudo systemctl status avahi-daemon). La solution de repli : trouver l’IP du Pi dans l’interface DHCP de ta box, ou scanner le réseau avec nmap -sn 192.168.1.0/24.
fail2ban suffit-il à sécuriser mon Pi si je l’expose à Internet ?
Non, c’est une couche parmi d’autres. La combinaison minimale : authentification par clé uniquement (pas de mot de passe), fail2ban pour bloquer les tentatives de brute force, et idéalement un changement de port SSH (de 22 vers 2222 par exemple) pour éviter le bruit des scans automatiques. Pour une vraie exposition Internet, ajoute un VPN comme WireGuard plutôt que d’exposer SSH directement.
Ma session SSH se coupe toute seule au bout de quelques minutes
Certains routeurs tuent les connexions TCP inactives après 5 à 10 minutes. Solution côté client : ajouter ServerAliveInterval 60 dans ~/.ssh/config. Cela envoie un paquet keep-alive chaque minute pour maintenir la connexion. Sur un réseau mobile ou en déplacement, utilise Mosh (Mobile Shell) qui survit aux changements de réseau et aux coupures de Wi-Fi.
Quelle différence entre ssh-keygen -t ed25519 et -t rsa ?
Ed25519 est l’algorithme moderne recommandé depuis OpenSSH 6.5 (2014) : clés plus courtes, signature plus rapide, meilleure résistance cryptographique. RSA reste compatible avec tous les serveurs anciens mais nécessite au moins 3072 bits en 2026 pour rester sûr. Pour un Pi et des serveurs modernes : Ed25519 sans hésitation.
Quand headless ne suffit pas
Deux cas où on branche quand même un écran : le débogage d’un problème réseau (le Pi ne se connecte plus au Wi-Fi, donc SSH ne marche pas non plus), et les projets multimédia où l’écran est le produit final (kiosque, retrogaming, media center). Dans ces cas, le Pi sert de machine à afficher, pas de serveur invisible.
Pour un dépannage ponctuel sans écran, il existe une solution intermédiaire : brancher un câble Ethernet entre le Pi et ton ordinateur en direct (pas via la box). Le Pi obtient une adresse en link-local (169.254.x.x) et tu peux t’y connecter via ssh toncompte@raspberrypi.local même sans Wi-Fi. C’est le dernier recours avant de sortir la carte SD.
Piège classique que j’ai vécu 4-5 fois : quand tu reflashes la carte SD d’un Pi qui a gardé le même hostname, la clé SSH serveur change. Ton client refuse la connexion avec un WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED. La commande à retenir : ssh-keygen -R nom-du-pi.local pour virer l’ancienne entrée, puis reconnexion normale.
Le guide ultime du Raspberry Pi donne plus de contexte sur les cas d’usage où le headless est recommandé par défaut, et ceux où un écran a du sens. Si tu veux aller plus loin dans la sécurisation de ton Pi exposé sur Internet, la prochaine étape logique est d’installer WireGuard pour un accès VPN plutôt que de laisser le port 22 ouvert au monde.
