Corriger l’erreur « Server refused to allocate pty » en SSH

Gérer un VPS ou un serveur dédié se passe en général sans accroc, jusqu’au jour où vous vous retrouvez soudain enfermé hors de votre propre terminal. Si vous lisez ces lignes, vous êtes sans doute devant un écran SSH figé, avec une légère montée de panique : vos frappes ne s’affichent pas ou renvoient d’étranges erreurs de permissions. Pas d’inquiétude ! Vous n’êtes pas seul, et surtout, votre serveur n’est pas complètement cassé. Dans ce guide technique, je vous explique comment corriger l’erreur « Server refused to allocate pty » à distance, rapidement, et retrouver votre ligne de commande en quelques minutes

Comment corriger « Server refused to allocate pty » et un terminal SSH figé

Vous êtes-vous déjà connecté avec succès à votre VPS en SSH, pour constater que vous ne pouvez taper aucune commande ? Votre terminal se fige, le texte que vous saisissez descend en escalier, et vous voyez peut-être défiler une rafale d’erreurs comme celle-ci :

/etc/profile: line 70: /dev/null: Permission denied

Ou pire, votre client SSH vous rejette purement et simplement avec :

PTY allocation request failed on channel 0 Server refused to allocate pty

Pas de panique. Votre serveur n’est pas définitivement mort, et vous n’avez pas forcément besoin de réinstaller le système. Ce problème courant vient de permissions manquantes ou corrompues sur les fichiers de périphériques de votre système Linux, en particulier /dev/null et /dev/ptmx.

Comme vous ne pouvez pas agir depuis l’intérieur du serveur, il faut forcer la réparation depuis l’extérieur. Voici le guide complet pour résoudre ce problème.

Comprendre le problème : pourquoi le terminal se fige-t-il ?

Pour comprendre la solution, il faut comprendre ce qui s’est cassé. Quand vous vous connectez en SSH, le serveur Linux vous attribue un pseudo-terminal (PTY), un écran virtuel qui fait le lien entre vos frappes et le shell du serveur.

• /dev/ptmx (Pseudo-Terminal Master Multiplexer) : ce fichier se charge de créer ces terminaux virtuels. Si ses permissions sont modifiées ou si le fichier est supprimé par erreur, le serveur ne peut tout simplement plus générer d’interface de terminal pour vous, d’où l’erreur « Server refused to allocate pty ».

• /dev/null (le trou noir) : c’est là que Linux envoie les sorties dont il n’a pas besoin. À la connexion, des scripts en arrière-plan (comme /etc/bashrc ou /etc/profile) tentent d’y écrire. Si les permissions de ce fichier sont cassées, ces scripts échouent en boucle avec des erreurs « permission denied » qui figent complètement le shell.

La solution : exécuter des commandes à distance via SSH

Votre shell interactif étant cassé, il faut le contourner. Nous allons utiliser SSH pour envoyer des commandes directement au serveur, sans demander d’interface de terminal.

Fermez votre session SSH figée (PuTTY ou votre terminal local). Ouvrez une nouvelle invite de commandes, PowerShell ou un terminal local sur votre ordinateur, puis suivez les deux étapes ci-dessous.

Étape 1 : rétablir les permissions de /dev/null

Il faut d’abord empêcher les scripts d’arrière-plan d’échouer, en recréant /dev/null avec le bon format et des droits d’écriture pour tous.

Exécutez la commande suivante depuis votre machine locale. (Remarque : remplacez user, YOUR_SERVER_IP et YOUR_PASSWORD par les vrais identifiants de votre serveur).

ssh user@YOUR_SERVER_IP "echo 'YOUR_PASSWORD' | sudo -S su -c 'rm -f /dev/null && mknod -m 0666 /dev/null c 1 3'"

Ce que fait cette commande : elle transmet votre mot de passe à sudo -S afin que la commande s’exécute avec les droits root sans rien demander sur un écran cassé. Elle supprime de force le fichier /dev/null corrompu et utilise mknod pour le recréer sous forme de fichier de périphérique en mode caractère (c 1 3), avec des droits de lecture et d’écriture ouverts à tous (0666).

Étape 2 : réparer /dev/ptmx et monter le terminal

Une fois les scripts calmés, il faut réparer l’allocateur de terminal pour pouvoir de nouveau taper. Exécutez cette deuxième commande depuis votre machine locale :

ssh user@YOUR_SERVER_IP "echo 'YOUR_PASSWORD' | sudo -S su -c 'rm -f /dev/ptmx && mknod -m 666 /dev/ptmx c 5 2 && chmod 666 /dev/ptmx && mount -t devpts devpts /dev/pts'"

Ce que fait cette commande : comme à l’étape 1, elle supprime tout fichier /dev/ptmx défectueux et le reconstruit (c 5 2). Les permissions 666 garantissent que tous les utilisateurs peuvent demander un terminal. Enfin, mount -t devpts monte le système de fichiers des pseudo-terminaux, dernière pièce nécessaire pour afficher correctement votre ligne de commande.

Nettoyage et bonnes pratiques de sécurité

Patientez quelques secondes, le temps que les commandes se terminent. Une fois de retour à votre invite de commandes locale, ouvrez votre client SSH et connectez-vous normalement. Votre serveur devrait maintenant répondre parfaitement.

Étapes de sécurité importantes après la réparation :

1. Effacez votre historique local : comme vous avez saisi votre mot de passe en clair dans la ligne de commande, il est maintenant enregistré dans l’historique de votre terminal local. Effacez votre historique bash local (history -c) ou changez immédiatement le mot de passe administrateur de votre serveur.

2. Renforcez votre configuration SSH : ce type de corruption de fichiers système peut parfois être la conséquence d’attaques automatisées ou de scripts mal écrits. Consultez les journaux de votre serveur pour repérer d’éventuelles tentatives de force brute. Si ce n’est pas déjà fait, remplacez le port SSH par défaut 22 par un port personnalisé, désactivez l’authentification par mot de passe au profit des clés SSH et installez Fail2Ban pour bloquer automatiquement les adresses IP malveillantes.

Tomber sur l’erreur « Server refused to allocate pty » ou « /dev/null permission denied » peut ressembler au cauchemar d’un administrateur système, surtout quand vous êtes complètement privé de shell. Pourtant, en contournant le terminal interactif et en envoyant ces deux commandes SSH à distance, vous pouvez facilement rétablir vos fichiers de périphériques et retrouver un accès complet sans réinstaller votre système.

Ce guide vous a-t-il évité un redémarrage forcé de votre serveur ? Ou avez-vous une autre astuce pour gérer les sessions SSH figées ? Dites-le-moi dans les commentaires ci-dessous, et pensez à mettre cette page en favori pour vos futurs besoins d’administration système !