WardtermClient SSH
FR
Télécharger

Comment modifier des fichiers distants en SSH

Le plus rapide est de modifier le fichier directement sur le serveur : ssh -t user@server nano /path/to/file, ou vi, presque toujours installé. Pour les fichiers de root, utilisez sudoedit. Pour travailler avec l'éditeur de votre machine, rapatriez le fichier avec scp, modifiez-le et renvoyez-le, ou laissez vim faire l'aller-retour avec vim scp://user@server//path/to/file. Pour un projet entier, montez le dossier avec sshfs.

Mis à jour le . Exécuté avec OpenSSH 10.0 sur Debian 13 dans des conteneurs jetables, en passant par un jump host : scp aller-retour, la vérification des modifications faites entre-temps, scp refusé sur un fichier de root, envoi dans /tmp avec sudo install, sudoedit avec SUDO_EDITOR et vim scp:// (Vim 9.1 avec netrw) en lecture et en écriture.

Modifier sur le serveur : nano, vi ou vim

ssh -t user@server nano /etc/nginx/sites-available/site.conf
ssh -t user@server vi /etc/nginx/sites-available/site.conf

L'éditeur tourne sur le serveur et vous le voyez à travers la session. -t demande un terminal, dont un éditeur a besoin quand vous le passez comme commande. Sans lui, vous obtenez Pseudo-terminal will not be allocated. Les images minimales n'ont souvent pas nano, alors que vi est presque toujours là.

Pour un fichier qui appartient à root, utilisez sudoedit plutôt que sudo nano :

ssh -t user@server sudoedit /etc/demo.conf
ssh -t user@server SUDO_EDITOR=nano sudoedit /etc/demo.conf

sudoedit copie le fichier, ouvre la copie dans votre éditeur lancé sous votre utilisateur, et la réécrit en root quand vous quittez. Votre éditeur et ses extensions ne tournent jamais en root, et dans notre test le fichier a gardé son propriétaire et ses droits :

-rw-r--r-- 1 root root 4 Nov  6 15:27 /etc/demo.conf

Utiliser un éditeur local : scp aller-retour

Pour modifier avec l'éditeur installé sur votre machine, récupérez le fichier, modifiez-le et renvoyez-le :

scp user@server:/etc/nginx/sites-available/site.conf .
cp site.conf site.conf.orig
# edit site.conf in your editor, then:
ssh user@server cat /etc/nginx/sites-available/site.conf | diff -q site.conf.orig -
scp site.conf user@server:/etc/nginx/sites-available/site.conf

La ligne diff évite l'accident classique : quelqu'un d'autre a modifié le fichier sur le serveur pendant que vous l'éditiez, et votre envoi efface sa modification. Aucune sortie signifie que la copie du serveur est toujours celle que vous avez récupérée.

scp écrit sous votre utilisateur, donc un fichier de root échoue :

scp: dest open "/etc/demo.conf": Permission denied
scp: failed to upload file demo.conf to /etc/demo.conf

Envoyez-le dans /tmp et mettez-le en place avec sudo install, qui règle aussi les droits :

scp demo.conf user@server:/tmp/demo.conf
ssh -t user@server sudo install -m 644 /tmp/demo.conf /etc/demo.conf

D'autres formes de la commande, avec ports, clés et dossiers, sont dans les exemples de scp.

Laisser vim faire l'aller-retour

vim scp://user@server//etc/nginx/sites-available/site.conf
vim scp://user@server/notes.txt

Le plugin netrw de vim télécharge le fichier dans une copie temporaire, et :w le renvoie avec scp. Deux barres obliques après l'hôte indiquent un chemin absolu. Une seule indique un chemin dans votre dossier personnel sur le serveur. Il utilise vos clés et votre ~/.ssh/config, donc un nom de Host et un jump host fonctionnent aussi. Dans notre test, un enregistrement passé par un jump host est arrivé aussitôt sur le serveur.

Emacs fait la même chose avec TRAMP : ouvrez /ssh:user@server:/etc/hosts avec C-x C-f, et l'enregistrement écrit sur le serveur.

Monter le dossier avec sshfs

sshfs user@server:/var/www ~/mnt/server

Tous les éditeurs et outils de votre machine voient alors le dossier distant comme un dossier local. Pour un projet avec beaucoup de fichiers, c'est mieux que de les copier un par un. L'installation, le démontage et que faire quand la connexion tombe sont dans monter un dossier distant avec sshfs.

Les éditeurs avec un mode distant

Plusieurs éditeurs de code savent travailler sur un serveur en SSH. Ils copient un petit programme d'assistance dans votre dossier personnel sur le serveur et le lancent sous votre utilisateur : recherche, complétion et terminal tournent là-bas, tandis que la fenêtre reste sur votre machine. C'est l'option la plus confortable pour de longues sessions sur un même projet. Il faut un peu d'espace disque sur le serveur et un système d'exploitation pris en charge par ce programme, qui tourne avec tous les droits de votre compte.

Avant d'enregistrer un fichier de configuration

  • Testez avant de recharger. Lancez sudo nginx -t, sudo sshd -t ou sudo visudo -c, selon le fichier. Une faute de frappe dans une configuration rechargée peut arrêter un service.
  • Gardez une deuxième session ouverte quand vous modifiez sshd_config, les règles du pare-feu ou les fichiers PAM, pour qu'une erreur ne vous enferme pas dehors.
  • Surveillez les fins de ligne. Un fichier enregistré avec des fins de ligne Windows casse les scripts shell avec des erreurs comme /bin/bash^M: bad interpreter.
  • Gardez une copie. Un sudo cp file file.bak avant de commencer permet de revenir en arrière en une seule commande.

Questions

Comment modifier en SSH un fichier qui appartient à root ?

Lancez ssh -t user@server sudoedit /etc/file. sudoedit copie le fichier, ouvre la copie dans votre éditeur sous votre propre utilisateur et la réécrit en root quand vous quittez. Choisissez l'éditeur avec SUDO_EDITOR=nano.

Pourquoi nano répond command not found sur le serveur ?

Les images de serveur minimales sont souvent livrées sans nano. vi est presque toujours présent, ou installez nano avec le gestionnaire de paquets, par exemple sudo apt install nano.

Peut-on modifier un fichier distant avec un éditeur local sans le copier ?

Pas vraiment : quelque chose le copie toujours. sshfs, vim scp:// et les éditeurs avec un mode distant font simplement la copie à votre place, à chaque ouverture et à chaque enregistrement.

Pourquoi mon éditeur se plaint du terminal en SSH ?

Vous avez lancé ssh server nano file sans -t, donc aucun terminal n'a été alloué. Ajoutez -t : ssh -t server nano file.

Sources

Autres guides : SFTP et transfert de fichiers

Tous les guides