| TUTORIEL SSH | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| 1 : SSH Secure SHell | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
SSH est à la fois un protocole de communication et une commande (utilisant ce protocole). La suite de commandes ssh est basée sur une authentification chiffrée ainsi que des trames chiffrées pendant toute l'exécution.
SSH est également prévu pour « forwarder » des ports TCP d'une machine vers une autre, créant ainsi un tunnel.
Cette méthode est couramment utilisée afin de sécuriser une connexion qui ne l'est pas (exemple : le protocole POP3/courriel) en la faisant passer par un tunnel chiffré SSH.
Pourquoi une suite ssh (ssh,scp, sftp) pour remplacer la suite rxxx (rlogin/telnet, rsh/rexec, rcp, ftp) :
Avant tout une raison de sécurité, dans une session (ftp, telnet, ..) le mot de passe ainsi que le reste de la session passe en clair sur le réseau et donc tout est à la merci des sniffers.
Que peut-on faire avec la suite SSH :
┌──────────────────────────────────────────┬─────────────────────────────────────────────────────────────────────────────────────────┐
│ ssh login@host commande │ Exécution distante de la commande, sur la machine distante et sous le login spécifiés │
│ ssh login@host │ Ouverture d'un shell distant sur la machine distante et sous le login spécifiés │
│ scp sce login@host:dest │ Copie machine locale vers machine distante │
│ scp login@host:sce dest │ Copie machine distante vers machine locale │
│ scp login1@host1:sce login2@host2:dest │ Copie machine distante 1 vers machine distante 2 (lancée sur la machine locale) │
│ sftp login@host │ Ouverture d'une session sftp │
│ rsync -options sce login@host:dest │ Synchronisation machine locale vers machine distante │
│ rsync -options login@host:dest sce │ Synchronisation machine distante vers machine locale │
└──────────────────────────────────────────┴─────────────────────────────────────────────────────────────────────────────────────────┘
|
Les exemples ci-dessous ne sont que des exemples simples d'utilisation des commande de base mais on peut faire beaucoup plus de choses en utilisant les options de chaque commande (Voir donc le détail de chaque commande ci-dessous).
Historiquement il y a eu une version SSH 1.0 avant la version 2.x. Comme la version 2.x est maintenant la plus répandue, ce tutoriel ne traitera que du SSH 2x.
| 1.1 : Mise en place ssh | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Il n'y a pas de mise en place proprement dite à faire.
ssh est livré avec un fichier /etc/ssh_config prêt à l'emploi.
On pourra évidemment le personnaliser si nécessaire.
Si vous connaissez un serveur sshd distant essayez
ssh login_distant@adresse_distante
Si c'est votre première tentative vous aurez ce message (répondez par 'yes').
The authenticity of host 'xxx.yyy.zzz.www (xxx.yyy.zzz.www)' can't be established.
RSA key fingerprint is 44:77:18:43:xx:yy:zz:da:ad:93:86:40:36:2b:50.
Are you sure you want to continue connecting (yes/no)? yes
Ce message vient du contrôle de l'adresse IP d'un client et de sa clé host (clé générée lors de l'installation du système).
Ce contrôle permet de vérifier qu'il n'y a pas d'usurpation d'adresse IP de la part d'un serveur sshd qui essaierait de
se faire passer pour ce qu'il n'est pas.
Puis ssh va afficher l'acquittement de l'insertion de cla clé host dans le fichier ~/.ssh/known_hosts.
Warning: Permanently added 'xxx.yyy.zzz.www' (RSA) to the list of known hosts.
Normalement, après saisie d'un mot de passe vous serez dans le shell distant, pour revenir au point de départ composez :
exit
|
| 1.2 : Mise en place sshd | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Le serveur ssh doit avoir un démon sshd qui tourne en permanence en attente de requêtes clients.
Il existe un service dans /etc/init.d un script de démarrage de sshd et dans etc un fichier /etc/sshd_config préparamétré pour un usage standard.
Bien vérifier que le service sshd est automatique au boot.
Si le serveur est protégé par un Pare-Feu, il faudra prendre soin d'ouvrir le port 22.
Si le serveur est derrière un routeur avec NAT, il faudra configurer la redirection du port 22 sur l'adresse IP locale du serveur.
Pour vérifier le focntionnement du démon sshd
ssh 127.0.0.1
Si c'est votre première tentative vous aurez ce message (répondez par 'yes').
The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established.
RSA key fingerprint is 44:77:18:43:xx:yy:zz:da:ad:93:86:40:36:2b:50.
Are you sure you want to continue connecting (yes/no)? yes
Ce message vient du contrôle de l'adresse IP d'un client et de sa clé host (clé générée lors de l'installation du système).
Ce contrôle permet de vérifier qu'il n'y a pas d'usurpation d'adresse IP.
Puis ssh va afficher l'acquittement de l'insertion de cla clé host dans le fichier ~/.ssh/known_hosts.
Warning: Permanently added '127.0.0.1' (RSA) to the list of known hosts.
Normalement, après saisie d'un mot de passe vous serez dans le shell, mais à travers ssh, pour revenir au point de départ composez :
exit
Puis un test d'accès avec l'adresse_locale
ssh votre_adresse_locale
Vous aurez vraisemblablement le même message si vous utilisez votre adresse locale pour la première fois.
Ensuite d'une autre station locale
ssh votre_adresse_locale
Ensuite d'une accès extérieur
ssh votre_adresse_publique
Si de l'extérieur, vous n'arrivez ps à vous connecter sur votre serveur, vérifier le Pare-feu ou le NAT de votre routeur.
|
| 1.3 : Procédures d'authentification | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
La procédure d'authentification la plus simple (et naturelle) correspond au couple login/mot_de_passe que l'on utilise pour tout connexion.
publickey gssapi-with-mic password
Il existe une liste impressionnante d'authentifications :
RSAAuthentication
PubkeyAuthentication
RhostsRSAAuthentication
HostbasedAuthentication
RhostsRSAAuthentication et HostbasedAuthentication
PasswordAuthentication
ChallengeResponseAuthentication
KerberosAuthentication
GSSAPIAuthentication
|
Dans le cadre de ce tutoriel nous nous intéresserons à
PasswordAuthentication Méthode classique login/mot_de_passe
PubkeyAuthentication Authentification par mécanisme de clés publiques/privées
|
| 1.3.1 : Authentification login/mot_de_passe | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
C'est évidemment la plus simple des authentifications, mais la saisie obligatoire d'un mot de passe empêchera l'utilisation de cette méthode pour des travaux automatisés (script, batch, ...).
| 1.3.2 : Authentification par clés publiques/privées | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Avec SSH, l'authentification peut se faire grâce à une clé privée et une clé publiques en utilisant la cryptographie asymétrique.
L'utilisation d'un "agent ssh" permet de stocker en mémoire la phrase clef pendant la durée de la session utilisateur.
En règle générale une session graphique commence par demander cette phrase clé à l'utilisateur, la stocke (cryptée) en mémoire
et cette phrase clé participera à l'authentification de la clé privée.
Mais on peut aussi envisager de lancer l'agent ssh avec la phrase clé en cours de session.
Sans la phrase clé la clé privée ne sert à rien.
Si l'on a pas utilisé de phrase clé lors de la génération des clés publiques/privées, on n'aura pas besoin d'agent ssh.
En contrepartie, il faudra contrôler la sécurité d'accès à la clé privée.
Par défaut les clés publiques et privées seront générées dans le répertoire ~/.ssh. Pour des raisons de sécurité il faudra
un accès, à ce répertoire, restreint uniquement à l'utilisateur (chmod 700 ~/.ssh).
Les droits des fichiers contenant les clés privées/publiques sont gérés par les outils de génération et ne doivent pas être
modifiés.
Outils de génération de clés privées/publiques :
ssh-keygen sous Unix/Linux
Puttygen sous Win32
|
| 1.3.3 : Procédures de blocage des tentatives d'intrusion | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Toute tentative infructueuse d'authentification est enregistrée dans '/var/log/secure'.
On peut intervenir directement dans la configuration de sshd (sshd_config) pour maintenir une liste d'utilisateurs bloqués ou une liste d'IP bloquées avec le fichier hosts.deny
Il existe des outils annexes à ssh (denyhosts) qui permettent, en analysant les tentatives d'intrusion, de bloquer les adresses IP trop curieuses au bout de n tentatives infructueuses.
| 1.3.4 : EXEMPLE DE GENERATION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Il existe deux type de clé (rsa, dsa), cet exemple et ceux qui suivent sont basés sur le type 'rsa'.
# ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/xxxx/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /xxxx/.ssh/id_rsa. Your public key has been saved in /xxxx/.ssh/id_rsa.pub. The key fingerprint is: 7e:da:8f:c6:b0:66:f0:56:4a:a4:eb:e6:fb:a3:45:c7 xxxxx@yyyyy.zzzzzzz The key's randomart image is: +--[ RSA 2048]----+ | | | . | | o | | . ... | | o.oE | | oo+. | | . +o.. | | o..=o. | | o+*==o.. | +-----------------+ # ls -d ~/.ssh drwx------ 2 uuuu gggg 4096 nov. 16 07:56 .ssh # ls ~/.ssh -rw------- 1 uuuu gggg 1675 nov. 16 07:49 id_rsa -rw-r--r-- 1 uuuu gggg 405 nov. 16 07:49 id_rsa.pub |
Il est à noter que le répertoire ~/.ssh est créé (avec les bons droits) s'il n'existait pas. Les fichiers id_xxx (clé privée) et id_xxx.pub (clé publique) sont créés aussi avec les bons droits. Ne pas modifier les droits par la suite.
| 1.3.5 : MISE EN PLACE clé publique SUR SERVEUR SSHD | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Tant que la clé publique n'est pas en place, il faudra utiliser l'authentification par 'login/mod_de_passe' pour cette mise en place.
ENVOI FICHIER CLE PUBLIQUE
Copie du fichier contenant la clé publique sur la machine distante (serveur sshd).
scp ~/.ssh/id_rsa.pub login_distant@host_distant:/tmp/ma_cle_publique
La commande scp devra être authentifiée par la saisie du mot de passe du login_distant sur la machine_distante.
|
MISE EN PLACE CLE PUBLIQUE
Connexion sur la machine distante (serveur sshd).
ssh login_distant@host_distant
La commande ssh devra être authentifiée par la saisie du mot de passe du login_distant sur la machine_distante.
Création du répertoire .ssh s'il n'existe pas déjà.
mkdir ~/.ssh
chmod 700 ~/.ssh
Copie de la clé publique dans le fichier authorized_keys.
cat /tmp/ma_cle_publique >>~/ssh/authorized_keys
chmod 600 ~/ssh/authorized_keys
Effacement du fichier contenant la clé publique (il ne serait pas très grave de le laisser puisque c'est la partie publique
de l'authentification.
rm /tmp/ma_cle_publique
Retour à la machine locale
exit
Puis sur la machine locale
Si vous avec utilisé une phrase clé
ssh-agent
ssh-add
Puis faire un essai
ssh login_distant@host_distant
Normalement il devrait y avoir un accès direct sans avoir à saisir de mot de passe.
Pour tester ce qui se passe en mode debug
ssh -v login_distant@host_distant
ou
ssh -vvvv login_distant@host_distant
|
| 2 : SSHD DEMON SERVEURSSH | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| sshd | Début | Suivant | Sommaire | Préc.page.lue | Accueil |
| NOM | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| SYNOPSIS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| DESCRIPTION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
sshd est le démon qui attend des connexions des clients. Il est normalement démarré à l'amorçage de la machine (boot) depuis /etc/rc Il crée un nouveau démon à chaque connexion entrante. Les démons créés prennent en charge l'échange de clef, le cryptage, l'authentification, l'exécution de commandes et l'échange de données. Cette implémentation de sshd supporte simultanément les versions 1 et 2 du protocole SSH. sshd fonctionne comme décrit ci-après.
| Version 1 du protocole SSH | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Chaque machine a une clef RSA spécifique (normalement 1024 bits), que l'on utilise pour identifier la machine. En outre, quand le démon démarre, il génère une clef RSA de serveur (normalement 768 bits). Cette clef est regénérée toutes les heures si elle a été utilisée, et n'est pas stockée sur disque.
Lorsqu'un client se connecte, le démon répond avec sa clef de machine et sa clef de serveur. Le client compare la clef RSA de la machine avec celle qu'il a stockée dans sa base de données pour vérifier si elle a changé. Le client génère ensuite un nombre aléatoire sur 256 bits. Il crypte ce nombre aléatoire avec la clef de la machine et la clef du serveur, puis envoie le nombre crypté au serveur. Les deux parties utilisent alors ce nombre aléatoire comme clef de session pour crypter toutes les communications ultérieures de la session. Le reste de la session est crypté avec un cryptage conventionnel, actuellement Blowfish ou 3DES, 3DES étant utilisé par défaut. Le client choisit l'algorithme de cryptage parmi ceux que propose le serveur.
Ensuite, le serveur et le client entrent dans la phase d'authentification. Le client essaie de s'authentifier à l'aide d'une authentification par .rhosts d'une authentification par .rhosts combinée avec une authentification RSA par machine, d'une authentification stimulation-réponse (challenge-response), ou d'une authentification par mot de passe.
Normalement, l'authentification Rhosts est désactivée, parce qu'elle n'est par définition pas sécurisée, mais peut être activée dans le fichier de configuration du serveur. On n'améliore pas la sécurité du système, tant que rshd rlogind et rexecd sont activés (et par conséquent que rlogin et rsh sont activés sur la machine).
| Version 2 du protocole SSH | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
La version 2 fonctionne de manière similaire : Chaque machine a une clef spécifique de machine (RSA ou DSA), qui sert à identifier la machine. Toutefois, lorsque le démon démarre, il ne génère pas de clef de serveur. La sécurité ultérieure est assurée par un système de validation de clef Diffie-Hellman. Ce système de validation de clef aboutit à une clef de session partagée.
Le reste de la session est crypté à l'aide d'un cryptage symétrique, actuellement 128 bit AES, Blowfish, 3DES, CAST128, Arcfour, 192 bit AES, ou 256 bit AES. Le client choisit l'algorithme de cryptage à utiliser dans la liste proposée par le serveur. En outre, l'intégrité de la session est assurée par un code d'authentification de message cryptographique (hmac-sha1 ou hmac-md5).
La version 2 du protocole fournit une méthode d'authentification d'utilisateur par clef publique (PubkeyAuthentication) ou de machine cliente (HostbasedAuthentication), des méthodes d'authentification par mot de passe et stimulation-réponse (challenge-response).
| Exécution de commandes et transfert de données | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Si le client réussit à s'authentifier, on démarre un échange de préparation de la session. À ce moment, le client peut demander l'allocation d'un pseudo-terminal (pseudo-tty), des redirections de connexions X11, des redirections de connexions TCP/IP ou une redirection de la connexion à l'agent d'authentification par le tunnel sécurisé.
Enfin, le client demande soit un interpréteur de commandes (shell) ou l'exécution d'une commande. Les deux parties entrent alors dans un mode de session. Dans ce mode, chaque partie peut envoyer des données à tout moment, et ces données sont transférées depuis/vers l'interpréteur de commandes ou la commande sur le serveur, et le terminal de l'utilisateur du côté du client.
Quand le programme de l'utilisateur se termine, et que toutes les redirections X11 et autres connexions sont fermées , le serveur envoie le code de sortie de la commande au client, et les deux parties arrêtent leur exécution.
sshd peut être configuré à l'aide d'options sur la ligne de commande, ou dans un fichier de configuration. Les options de la ligne de commande outrepassent les valeurs spécifiées dans le fichier de configuration.
sshd relit son fichier de configuration quand il reçoit un signal de suspension, SIGHUP en s'exécutant lui-même avec le même nom que celui avec lequel il a été démarré, par exemple /usr/sbin/sshd
Les options sont les suivantes :
| FICHIER DE CONFIGURATION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| PROCESSUS DE CONNEXION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| FORMAT DU FICHIER AUTHORIZED_KEYS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Chaque ligne du fichier contient une clef (les lignes vides ou débutant par le caractère « # » sont ignorées et considérées comme des commentaires). Chaque clef publique RSA consiste en les champs suivants, séparés par des espaces : options, bits, exposant, modulo, commentaire. Chaque clef publique pour la version 2 du protocole consiste en : options, type de clef, clef encodée en base64, commentaire. Les champs d'option sont optionnels ; leur présence est déterminée par le fait que la ligne commence avec un nombre ou pas (le champ d'option ne commence jamais par un nombre). Les champs bits, exposant, modulo et commentaire déterminent la clef RSA pour la version 1 du protocole ; le champ commentaire n'est pas utilisé pour quoi que ce soit (mais peut servir à l'utilisateur pour identifier sa clef). Pour la version 2 du protocole, le type de clef est « ssh-dss » ou «ssh-rsa ».
Note : les lignes contenues dans ce fichier font en général quelques centaines de caractères (à cause de la taille du modulo de la clef RSA). Il n'est pas très judicieux de les saisir manuellement ; il est plus fiable de les copier dans les fichiers identity.pub id_dsa.pub ou id_rsa.pub puis de les coller.
sshd impose une taille minimale du modulo pour la clef RSA pour la version 1 du protocole et pour les clefs pour la version 2 du protocole de 768 bits.
Les options (s'il y en a) consistent en une liste d'entrées séparées par des virgules. Les espaces sont interdits, sauf entre des guillemets. Les spécifications d'options suivantes sont supportées. Note : les mots-clefs des options ne sont pas sensibles à la casse.
| Exemples | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
from="*.niksula.hut.fi,!pc.niksula.hut.fi" 1024 35 23...2334 ylo@niksula
command="dump /home",no-pty,no-port-forwarding 1024 33 23...2323 backup.hut.fi
permitopen="10.2.1.55:80",permitopen="10.2.1.56:25" 1024 33 23...2323
| FORMAT DU FICHIER SSH_KNOWN_HOSTS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Chaque ligne de ces fichiers contient les champs suivants : noms de machine, bits, exposant, modulo, commentaire. Les champs sont séparés par des espaces.
Les noms de machines sont une liste de motifs séparés par des virgules (« * » et « ? » sont des jokers) ; chaque motif l'un après l'autre est mis en correspondance avec le nom canonique de la machine (authentification d'un client) ou avec le nom fourni par l'utilisateur (authentification d'un serveur). On peut précéder un motif du caractère « ! » pour indiquer une négation : si le nom de la machine correspond à un motif nié, il n'est pas accepté (de par cette ligne), même s'il correspond à un autre motif de la ligne.
Les bits, exposant, et modulo sont pris directement dans la clef de machine RSA ; on peut les récupérer par exemple, depuis /etc/ssh/ssh_host_key.pub Le champ de commentaire optionnel continue jusqu'à la fin de la ligne et n'est pas utilisé.
Les lignes vides ou débutant par le caractère « # » sont ignorées et considérées comme des commentaires.
Lors d'une authentification de machine, l'authentification est acceptée si une ligne a la clef appropriée. Il est donc autorisé (mais pas recommandé) d'avoir plusieurs lignes ou des clefs de machines différentes pour les mêmes noms. Cela se produit inévitablement quand on met dans le fichier les noms abrégés des noms de machines depuis des domaines différents. Il est possible que le fichier contienne des informations en conflit ; on peut s'authentifier si on trouve une information valide dans l'un des fichiers.
Note : les lignes dans ces fichiers contiennent typiquement des centaines de caractères, et il n'est pas très intéressant de les saisir manuellement. On peut plutôt les générer à l'aide d'un script, ou les récupérer dans /etc/ssh/ssh_host_key.pub et les ajouter en tête du fichier.
| Exemples | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
closenet,...,130.233.208.41 1024 37 159...93 closenet.hut.fi cvs.openbsd.org,199.185.137.3 ssh-rsa AAAA1234.....=
| FICHIERS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Il est aussi possible d'utiliser des groupes réseau (netgroups) dans le fichier. Le nom de machine ou d'utilisateur peut être de la forme +@groupname pour spécifier toutes les machines ou tous les utilisateurs dans le groupe.
Si la machine/l'utilisateur client(e) est mis(e) en correspondance dans ce fichier, la connexion est automatiquement autorisée, pour peu que les noms d'utilisateur client et serveur soient identiques. En outre, une authentification de machine RSA réussie est normalement requise. Ce fichier ne doit être accessible en écriture qu'à root ; il est recommandé qu'il soit accessible en lecture par tout le monde.
Attention : Ce n'est presque jamais une bonne idée d'utiliser des noms d'utilisateurs dans" hosts.equiv Il faut bien être conscient du fait que cela signifie vraiment que le ou les utilisateur(s) peuvent se connecter en tant que n'importe qui et en particulier bin, daemon, adm, et les autres comptes propriétaires de binaires et de répertoires critiques pour le système. L'utilisation d'un nom d'utilisateur accorde pratiquement un accès de l'utilisateur root. La seule utilisation raisonnable des noms d'utilisateurs réside dans les entrées niées.
Note : Cet avertissement s'applique aussi à rsh/rlogin.
Le but premier de ce fichier est d'exécuter toutes les routines d'initialisation qui peuvent nécessaires avant que le répertoire de base (home directory) de l'utilisateur ne devienne accessible ; AFS fournit un exemple particulier d'un tel environnement.
Ce fichier contiendra probablement du code d'initialisation suivi par quelque chose comme :
if read proto cookie && [ -n "$DISPLAY" ]; then
if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
# X11UseLocalhost=yes
xauth add unix:`echo $DISPLAY |
cut -c11-` $proto $cookie
else
# X11UseLocalhost=no
xauth add $DISPLAY $proto $cookie
fi
fi
Si ce fichier n'existe pas, /etc/ssh/sshrc est exécuté, et s'il n'existe pas non plus, xauth est utilisé pour ajouter le cookie.
Ce fichier ne doit être accessible en écriture qu'à l'utilisateur, et n'a pas besoin d'être lisible par le groupe ou les autres.
| AUTEURS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| TRADUCTION FRANÇAISE | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| AVERTISSEMENT SUR LA TRADUCTION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| VOIR AUSSI | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| 3 : sshd_config Fichier de configuration de sshd | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| sshd_config | Début | Suivant | Sommaire | Préc.page.lue | Accueil |
Section: File Formats (5)
Sommaire
BSD mandoc
| NOM | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| SYNOPSIS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| DESCRIPTION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
sshd lit des données de configuration dans le fichier /etc/ssh/sshd_config (ou du fichier spécifié à l'aide de l'option -f sur la ligne de commande). Ce fichier contient des paires mot-clef/argument, une par ligne. Les lignes qui commencent par le caractère « # » et les lignes vides sont interprétées comme des commentaires.
Les mots-clefs possibles et leur signification sont listés ci-après (Note : les mots-clefs ne sont pas sensibles à la casse, mais les arguments le sont) :
Spécifie si on peut rediriger un jeton AFS (AFS token) vers le serveur. Par défaut « no ».
Ce mot-clef peut être suivi d'une liste de motifs de nom de groupe, séparés par des espaces. S'il est spécifié, seuls les utilisateurs dont le groupe principal ou les groupes supplémentaires correspondent à un des motifs sont autorisés à se connecter. On peut utiliser les caractères « * » ou « ? » comme jokers.
Seuls les noms de groupes sont valides ; les identifiants de groupes (GID) numériques ne sont pas reconnus. Par défaut, la connexion est autorisée pour tous les groupes.
Spécifie si les redirections TCP sont autorisées. Par défaut « yes ». Note : la désactivation des redirections TCP n'améliore pas la sécurité si les utilisateurs ont un accès à un interpréteur de commandes (shell), car ils peuvent toujours installer leurs propres outils de redirections.
Ce mot-clef peut être suivi d'une liste de motifs de noms d'utilisateurs, séparés par des espaces. S'il est spécifié, seuls les noms d'utilisateurs correspondant à un des motifs sont autorisés à se connecter. On peut utiliser les caractères « * » ou « ? » comme des jokers.
Seuls les noms d'utilisateurs sont valides ; les identifiants d'utilisateurs (UID) ne sont pas reconnus. Par défaut, la connexion est autorisée pour tous les utilisateurs.
Si le motif est de la forme UTILISATEUR@MACHINE, alors UTILISATEUR et MACHINE sont vérifiés séparément, en restreignant les connexions à des utilisateurs en particulier sur des machines en particulier.
Spécifie le fichier contenant les clefs publiques à utiliser pour l'authentification de l'utilisateur. AuthorizedKeysFile peut contenir des jetons de la forme %T qui sont substitués lors des réglages de la connexion. Les jetons suivant sont définis : %% est remplacé par le caractère « % », %h est remplacé par le répertoire de base (home directory) de l'utilisateur qui s'authentifie et %u est remplacé par le nom de cet utilisateur. Après substitution, AuthorizedKeysFile peut être un chemin absolu ou relatif au répertoire de base de l'utilisateur. Par défaut « .ssh/authorized_keys ».
Pour certaines juridictions, l'envoi d'un message avant l'authentification est nécessaire pour disposer d'une protection légale. Le contenu du fichier spécifié est envoyé à l'utilisateur distant avant d'autoriser la connexion. Cette option n'est disponible qu'avec la version 2 du protocole. Par défaut, on n'affiche pas de message.
Spécifie si on autorise l'authentification par stimulation-réponse (challenge response). Toutes les formes d'authentification de login.conf5 sont gérées.
Par défaut « yes ».
Spécifie le cryptage autorisé pour le version 2 du protocole. On peut en spécifier plusieurs en les séparant par des virgules.
Par défaut :
« aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
aes192-cbc,aes256-cbc »
Règle un intervalle de temporisation en secondes après lequel, si aucune donnée n'est reçue de la part du client, sshd envoie un message dans le canal crypté pour demander une réponse du client. Par défaut 0, ce qui signifie que ces messages ne sont pas envoyés au client. Cette option ne s'applique qu'à la version 2 du protocole.
Règle le nombre de messages de maintien de la connexion (voir ci-dessus) à envoyer sans réponse de la part du client pour sshd Si ce seuil est atteint tandis que les messages de maintien de la connexion ont été envoyés, sshd déconnecte le client et termine la session. Il est important de noter que ces messages de maintien de la connexion sont très différents de l'option KeepAlive (ci-dessous). Les messages de maintien de la connexion sont envoyés par le tunnel crypté, et par conséquent ne sont pas falsifiables. Le maintien de la connexion au niveau TCP activé par l'option KeepAlive est falsifiable. Le mécanisme de maintien de la connexion est intéressant quand le client ou le serveur ont besoin de savoir si la connexion est inactive.
Par défaut 3. Si l'option ClientAliveInterval (ci-dessus) est réglée à 15, et ClientAliveCountMax est réglée à sa valeur par défaut, les clients ssh qui ne répondent pas sont déconnectés après environ 45 secondes.
Spécifie si on autorise la compression. L'argument doit être « yes » ou « no ». Par défaut « yes ».
Ce mot-clef est suivi d'une liste de motifs de noms de groupes, séparés par des espaces. Les utilisateurs dont le groupe principal ou les groupes secondaires correspondent à un des motifs ne sont pas autorisés à se connecter. Dans les motifs, on peut utiliser les caractères « * » et « ? » comme des jokers. On ne spécifie que des noms de groupes ; les identifiants numériques de groupes ne sont pas autorisés.
Par défaut, tous les groupes sont autorisés à se connecter.
Ce mot-clef est suivi d'une liste de motifs de noms d'utilisateurs, séparés par des espaces. Les utilisateurs dont le nom correspond à un des motifs ne sont pas autorisés à se connecter. Dans les motifs, on peut utiliser les caractères « * » et « ? » comme des jokers.
On ne spécifie que des noms d'utilisateurs ; les identifiants numériques d'utilisateurs ne sont pas autorisés. Par défaut, tous les utilisateurs sont autorisés à se connecter. Si le motif est de la forme UTILISATEUR@MACHINE, UTILISATEUR et MACHINE sont vérifiés séparément, et la connexion est restreinte à certains utilisateurs de certaines machines.
Spécifie si les machines distantes sont autorisées à se connecter à des ports redirigés par le client. Par défaut, sshd branche les redirections de ports à l'adresse de bouclage (loopback address). Ceci évite que les autres machines distantes ne se connectent aux ports redirigés. On peut utiliser l'option GatewayPorts pour spécifier que sshd doit brancher les redirections de ports distantes à l'adresse joker, et par conséquent autoriser les machines distantes à se connecter à des ports redirigés. L'argument doit être « yes » et « no ». Par défaut « no ».
Spécifie si on autorise une authentification par rhosts ou /etc/hosts.equiv conjointement avec une authentification de machine cliente réussie par clef publique (authentification par machines). Cette option est similaire à l'option RhostsRSAAuthentication et ne s'applique qu'à la version 2 du protocole. Par défaut « no ».
Spécifie un fichier contenant une clef privée de machine utilisée par SSH. Par défaut /etc/ssh/ssh_host_key pour la version 1 du protocole, et /etc/ssh/ssh_host_rsa_key et /etc/ssh/ssh_host_dsa_key pour la version 2 du protocole. Note : sshd refuse d'utiliser un fichier accessible au groupe ou aux autres.
On peut avoir plusieurs fichiers de clef de machine. Les clefs « rsa1 » sont utilisées pour la version 1 du protocole, et les clefs « dsa » ou « rsa » sont utilisées pour la version 1 du protocole SSH.
Spécifie que l'on utilise pas les fichiers .rhosts et .shosts pour les authentification activées par les options RhostsAuthentication RhostsRSAAuthentication ou HostbasedAuthentication
Les fichiers /etc/hosts.equiv et /etc/ssh/shosts.equiv sont néanmoins utilisés.
Par défaut « yes ».
Spécifie si sshd doit ignorer le fichier $HOME/.ssh/known_hosts de l'utilisateur lors des authentifications des options RhostsRSAAuthentication ou HostbasedAuthentication Par défaut « no ».
Spécifie si le système doit envoyer des messages TCP de maintien de la connexion. Si ces messages sont envoyés, la rupture d'une connexion ou le plantage d'une des machines seront correctement signalés.
Toutefois, cela signifie que la connexion sera interrompue si la route entre le serveur et le client est temporairement coupée, et quelques personnes trouvent ceci gênant. D'un autre côté, si on n'envoie pas de messages de maintien de la connexion, il est possible que des sessions restent en suspens indéfiniment sur le serveur, en laissant des utilisateurs fantômes, et en consommant les ressources du serveur.
Par défaut « yes » (pour envoyer les messages de maintien de la connexion), et le serveur signale les coupures réseau ou les plantages des machines.
Ceci évite les sessions indéfiniment en suspens.
Pour désactiver ces messages de maintien de la connexion, il faut régler cette valeur à « no ».
Spécifie si on autorise l'authentification Kerberos. Elle peut être de la forme d'un ticket Kerberos, ou si l'option PasswordAuthentication est réglée à « yes », le mot de passe fourni par l'utilisateur est validé par le KDC Kerberos.
Pour utiliser cette option, le serveur a besoin d'un servtab Kerberos qui autorise la vérification de l'identité du KDC. Par défaut « no ».
Si cette option est réglée, alors si l'authentification par mot de passe par Kerberos échoue, le mot de passe est validé via n'importe quel mécanisme local tel que /etc/passwd Par défaut « yes ».
Spécifie si on redirige un TGT Kerberos vers le serveur. Par défaut « no », car ceci ne fonctionne que si le KDC Kerberos est vraiment un kaserver AFS.
Spécifie si on détruit automatiquement le fichier cache du ticket de l'utilisateur à la déconnexion. Par défaut « yes ».
Dans la version 1 du protocole, la clef éphémère du serveur est regénérée automatiquement après ce nombre de secondes (si elle a été utilisée). Le but de la regénération est d'éviter le décryptage de sessions capturées en s'introduisant plus tard sur la machine et en volant la clef. La clef n'est jamais stockée nulle part. Si la valeur est 0, la clef n'est jamais regénérée. Par défaut 3600 (secondes).
Spécifie l'adresse locale d'écoute sur laquelle le démon sshd doit attendre les connexions.
On peut utiliser les formes suivantes :
host | IPv4_addr | IPv6_addr
host | IPv4_addr : port
[host | IPv6_addr : port ]
Si port n'est pas spécifié, le démon sshd écoute sur l'adresse et toutes les options Port spécifiées au préalable. Par défaut, on écoute sur toutes les adresses locales.
On peut spécifier de multiples options ListenAddress En outre, toute option Port doit précéder cette option pour les adresses sans port spécifié.
Le serveur se déconnecte après ce délai si l'utilisateur ne s'est pas connecté. Si la valeur est 0, il n'y a aucune limite de temps.
Par défaut 600 (secondes).
Donne le niveau de verbosité utilisé lors de l'enregistrement des messages du démon sshd Les valeurs possibles sont : QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2 and DEBUG3. Par défaut INFO. DEBUG et DEBUG1 sont équivalents. DEBUG2 et DEBUG3 spécifient des niveaux plus élevés de sortie de débogage. L'enregistrement à l'aide d'un niveau DEBUG a tendance à empiéter sur la vie privée des utilisateurs et n'est pas recommandé.
L'algorithme MAC est utilisé dans la version 2 du protocole pour la protection de l'intégrité des données.
On peut spécifier plusieurs algorithmes en les séparant par des virgules.
Par défaut « hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 ».
Spécifie un nombre maximal de connexions concurrentes au démon sshd non authentifiées.
Les connexions supplémentaires sont purgées si elles ne peuvent pas s'authentifier ou si le délai de grâce défini à l'aide de l'option LoginGraceTime expire pour une connexion. Par défaut 10.
Par ailleurs, on peut activer une purge hâtive aléatoire en spécifiant un triplet « début:taux:total » (par exemple, « 10:30:60 »). sshd refuse les tentatives de connexion avec une probabilité de « taux/100 » (30 %) s'il y a « début » (10) connexions non authentifiées en cours.
La probabilité augmente linéairement et toutes les tentatives de connexion sont refusées si le nombre de connexions non authentifiées atteint « total » (60).
Spécifie si l'authentification PAM par stimulation/réponse est autorisée. Ceci permet d'utiliser la plupart des modules d'authentification PAM par stimulation/réponse, mais peut autoriser l'authentification par mot de passe sans se soucier de l'option PasswordAuthentication
Spécifie si l'authentification par mot de passe est autorisée. Par défaut « yes ».
Si l'authentification par mot de passe est autorisée, spécifie si le serveur autorise les connexions à des comptes dont les mots de passe sont des chaînes de caractères vides.
Par défaut « no ».
Spécifie si root peut se connecter par ssh(1). L'argument est « yes », « without-password », « forced-commands-only » ou « no ». Par défaut « yes ».
Si cette option est réglée à « without-password », l'authentification par mot de passe est désactivée pour root.
Si cette option est réglée à « forced-commands-only », les connexions de root sont autorisées avec une authentification par clef publique, mais seulement si l'option command est spécifiée (ce qui peut être utile pour effectuer des sauvegardes à distance même si les connexions de root sont normalement interdites). Toutes les autres méthodes d'authentification sont désactivées pour root.
Si cette option est réglée à « no », root n'est pas autorisé à se connecter.
Spécifie l'emplacement du fichier contenant l'identifiant du processus du démon sshd Par défaut /var/run/sshd.pid
Spécifie le port d'écoute du démon sshd Par défaut 22. On peut spécifier plusieurs de ces options.
Voir aussi ListenAddress
Spécifie si sshd doit afficher la date et l'heure de la dernière connexion de l'utilisateur. Par défaut « yes ».
Spécifie si sshd doit afficher le contenu du fichier /etc/motd quand un utilisateur se connecte en mode interactif. Sur certains systèmes, il est aussi affiché par l'interpréteur de commandes (shell), par le fichier /etc/profile ou équivalent. Par défaut « yes ».
Spécifie les versions du protocole que le démon sshd gère. Les valeurs possibles sont « 1 » et « 2 ». Pour spécifier plusieurs versions, il suffit de les séparer par des virgules.
Par défaut « 2,1 ».
Spécifie si on autorise l'authentification par clef publique. Par défaut « yes ». Note : Cette option ne s'applique qu'à la version 2 du protocole.
Spécifie si l'authentification par les fichiers rhosts ou /etc/hosts.equiv est suffisante. Normalement, cette méthode ne devrait pas être autorisée parce qu'elle n'est pas sécurisée. Il est préférable d'utiliser RhostsRSAAuthentication à la place, parce qu'elle effectue une authentification de machine basée sur RSA en plus de l'authentification normale par rhosts ou /etc/hosts.equiv. Par défaut « no ». Cette option ne s'applique qu'à la version 1 du protocole.
Spécifie si on autorise une authentification par rhosts ou /etc/hosts.equiv couplée avec une authentification de machine RSA réussie. Par défaut « no ». Cette option ne s'applique qu'à la version 1 du protocole.
Spécifie si on autorise la pure authentification RSA. Par défaut « yes ». Cette option ne s'applique qu'à la version 1 du protocole.
Définit le nombre de bits de la clef éphémère pour la version 1 du protocole. La valeur minimale est 512 et la valeur par défaut est 768.
Spécifie si sshd doit vérifier les modes et le propriétaire des fichiers de l'utilisateur et du répertoire de base (home directory) de l'utilisateur avant d'accepter une connexion. C'est normalement souhaitable, parce que quelquefois, les novices laissent accidentellement leur répertoire ou leurs fichiers en accès complet à tout les monde. Par défaut « yes ».
Configure un sous-système externe (par exemple un démon de transfert de fichiers). Les arguments doivent être un nom de sous-système et une commande à exécuter lors d'une requête à ce sous-système. La commande sftp-server8 implémente le sous-système de transfert de fichiers « sftp ». Par défaut, aucun sous-système n'est défini. Note : Cette option ne s'applique qu'à la version 2 du protocole.
Donne le code de facilité utilisé lors de l'enregistrement des messages du démon sshd Les valeurs possibles sont : DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. Par défaut AUTH.
Spécifie si on utilise login(1) pour les connexions à des sessions interactives.
Par défaut « no ». Note 1 : On n'utilise jamais login(1) pour l'exécution de commandes à distance. Note 2 : Si cette option est activée, on désactive X11Forwarding parce que login(1) ne sait pas traiter les cookies xauth(1). Si on spécifie l'option UsePrivilegeSeparation elle sera désactivée après l'authentification.
Spécifie si sshd sépare les privilèges en créant un processus fils non privilégié pour prendre en charge le trafic réseau entrant. Après une authentification réussie, un autre processus est créé avec les privilèges de l'utilisateur authentifié. Le but de la séparation de privilèges est d'éviter l'escalade de privilèges si le processus non privilégié est corrompu. Par défaut « yes ».
Spécifie si sshd essaie de vérifier que le nom de la machine distante et le nom obtenu par résolution de l'adresse IP distante correspondent à la même adresse IP. Par défaut « no ».
Spécifie le premier numéro d'affichage disponible pour les redirections X11 de sshd Ceci évite à sshd d'interférer avec les vrais serveurs X11. Par défaut 10.
Spécifie si on autorise les redirections X11. Par défaut « no ». Note : La désactivation des redirections X11 n'améliore en aucun cas la sécurité, puisque les utilisateurs peuvent installer leurs propres redirecteurs.
La redirection X11 est automatiquement désactivée si l'option UseLogin est activée.
Spécifie si sshd branche le serveur X11 de redirection sur l'adresse de bouclage (loopback address) ou sur l'adresse joker (wildcard address). Par défaut sshd branche le serveur de redirection sur l'adresse de bouclage et règle la partie du nom de machine de la variable d'environnement DISPLAY à « localhost ». Ceci évite à des machines distantes de se connecter à de faux affichages. Néanmoins, quelques vieux clients X11 peuvent ne pas fonctionner avec cette configuration. On peut régler X11UseLocalhost à « no » pour spécifier que le serveur de redirection est branché sur l'adresse joker. L'argument doit être « yes » ou « no ». Par défaut « yes ».
Spécifie l'emplacement du programme xauth(1). Par défaut /usr/X11R6/bin/xauth
| Formats de durées | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
On peut exprimer les arguments de la ligne de commande et les options du fichier de configuration de sshd qui spécifient des durées à l'aide d'une séquence de la forme : time [qualifier ] où time est une valeure entière positive et qualifier est l'un des suivants :
secondes
secondes
minutes
heures
jours
semaines
Tous les membres de la séquence sont additionnés pour obtenir la valeur totale de la durée.
Exemples de formats de durées :
600 secondes (10 minutes)
10 minutes
1 heure 30 minutes (90 minutes)
| FICHIERS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Contient les données de configuration de sshd Ce fichier ne doit être accessible en écriture qu'à root, mais il est recommandé (bien que pas nécessaire) qu'il soit accessible en lecture à tous.
| AUTEURS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
OpenSSH est dérivé de la version originale et libre ssh 1.2.12 par Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt et Dug Song ont corrigé de nombreux bugs, ré-ajouté des nouvelles fonctionnalité et créé OpenSSH. Markus Friedl a contribué au support des versions 1.5 et 2.0 du protocole SSH. Niels Provos et Markus Friedl ont contribué au support de la séparation de privilèges.
| TRADUCTION FRANÇAISE | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| VOIR AUSSI | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
sshd(8)
| 4 : SSH CLIENT SSH | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| ssh | Début | Suivant | Sommaire | Préc.page.lue | Accueil |
Section: User Commands (1)
Sommaire
BSD mandoc
| NOM | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| SYNOPSIS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
ssh [-1246AaCfgkMNnqsTtVvXxY ] [-b adr_assoc ] [-c crypt_spec ] -words [-D port ] [-e char_echap ] [-F fich_config ] [-i fich_identite ] [-L port host hostport ] [-l nom_login ] [-m mac_spec ] [-o option ] -words [-p port ] [-R port host hostport ] [-S ctl ] [utilisateur @ hostname ] [commande ]
| DESCRIPTION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
ssh (client SSH) est un programme qui permet de se connecter sur une machine distante, ou d'exécuter des commandes sur une machine distante. Il a pour objectif de remplacer rlogin et rsh, et fournit des transmissions sécurisées et cryptées entre deux machines qui ne sont pas sûres, et ce à travers un réseau non sécurisé. On peut transférer des connexions X11 et des ports TCP/IP arbitraires à travers un tunnel sécurisé.
ssh se connecte et ouvre une session sur la machine hostname (avec éventuellement un nom d' utilisateur ). L'utilisateur doit prouver son identité sur la machine distante à l'aide d'une méthode parmi plusieurs qui dépendent de la version du protocole SSH utilisée :
Si commande est spécifiée, alors commande est exécutée sur la machine distante à la place du shell de login.
| Version 1 du protocole SSH | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Tout d'abord, si la machine à partir de laquelle l'utilisateur tente de se connecter est listée dans le fichier /etc/hosts.equiv ou le fichier /etc/ssh/shosts.equiv de la machine distante, et que les noms d'utilisateurs sont identiques des deux côtés, l'utilisateur est immédiatement autorisé à se connecter. Ensuite, si le fichier .rhosts ou .shosts existe dans le répertoire personnel de l'utilisateur sur la machine distante et qu'il contient une ligne avec le nom de la machine cliente et le nom de l'utilisateur sur cette machine, l'utilisateur est autorisé à se connecter. Cette méthode d'authentification utilisée toute seule est normalement refusée par le serveur parce qu'elle n'est pas sécurisée.
La seconde méthode d'authentification utilise les fichiers rhosts ou hosts.equiv avec une authentification par machine basée sur RSA. Ce qui signifie que la connexion est autorisée, si et seulement si la connexion est autorisée par les fichiers $HOME/.rhosts $HOME/.shosts /etc/hosts.equiv ou /etc/ssh/shosts.equiv et qu'en plus le serveur peut vérifier la clef d'hôte (cf. les fichiers /etc/ssh/ssh_known_hosts et $HOME/.ssh/known_hosts dans la section Sx FICHIERS ). Cette méthode d'authentification comble les failles de sécurité liées à l'usurpation d'adresses IP et la falsification de DNS ou de routage. [Note aux administrateurs : /etc/hosts.equiv $HOME/.rhosts et les protocoles rlogin/rsh en général ne sont pas sécurisés de par leur conception. Par conséquent, s'il y a un besoin de sécurité, il est judicieux de les désactiver.]
La troisième méthode d'authentification de ssh est une authentification basée sur RSA. Cette méthode utilise la cryptographie par clef publique : dans certains cryptosystèmes, on crypte et décrypte à l'aide de clefs différentes, et il n'est pas possible de déduire la clef de décryptage à partir de la clef de cryptage. Le système RSA fonctionne de cette manière. Chaque utilisateur crée une paire clef publique/clef privée à des fins d'authentification. Le serveur connaît la clef publique, mais seul l'utilisateur connaît sa clef privée.
Le fichier $HOME/.ssh/authorized_keys contient la liste des clefs publiques autorisée à se connecter. Quand un utilisateur se connecte, le programme ssh indique au serveur la paire de clefs qu'il souhaite utiliser lors de l'authentification. Le serveur vérifie si la clef est autorisée, et si c'est le cas, envoie à l'utilisateur (en fait, au programme ssh lancé par l'utilisateur) un défi (challenge) : un nombre aléatoire crypté à l'aide de la clef publique de l'utilisateur. Ce défi ne peut être décrypté qu'à l'aide de la bonne clef privée. Le client de l'utilisateur relève le défi en le décryptant à l'aide de la clef privée. Il prouve ainsi qu'il connaît la clef privée, mais il ne la révèle pas pour autant au serveur.
ssh implémente en standard le protocole d'authentification RSA. L'utilisateur peut créer une paire de clef RSA à l'aide du programme ssh-keygen1. Ce programme enregistre la clef privée dans $HOME/.ssh/identity et la clef publique dans $HOME/.ssh/identity.pub dans le répertoire personnel de l'utilisateur. L'utilisateur peut alors copier identity.pub vers $HOME/.ssh/authorized_keys dans son répertoire personnel sur la machine distante (le fichier authorized_keys est l'équivalent du fichier $HOME/.rhosts et contient une clef par ligne, par conséquent les lignes sont parfois très longues). Grâce à ça, l'utilisateur peut se connecter sans fournir de mot de passe. L'authentification RSA est beaucoup plus sécurisée que l'authentification à l'aide des fichiers rhosts.
En utilisant un agent d'authentification, on rend l'authentification RSA encore plus pratique. Référez-vous à ssh-agent1 pour plus d'informations à ce sujet.
Si ces autres méthodes d'authentifications échouent, ssh réclame un mot de passe à l'utilisateur. Ce mot de passe est alors envoyé par le réseau à la machine distante. Toutefois, comme toutes les transmissions sont cryptées, on ne peut pas voir le mot de passe en surveillant le réseau.
| Version 2 du protocole SSH | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Si un utilisateur se connecte à l'aide de la version 2 du protocole, il a à sa disposition des méthodes semblables. Les valeurs par défaut de la variable PreferredAuthentications précisent que tout d'abord, le client tente une authentification à l'aide de la méthode basée sur les machines connues (hostbased). En cas d'échec, il tente une authentification par clef publique. Si l'authentification n'est toujours pas possible, il tente une authentification par saisie interactive au clavier et par mot de passe.
La méthode d'authentification par clef publique est semblable à celle de l'authentification RSA décrite dans la section précédente, et peut utiliser les algorithmes RSA ou DSA : Le client utilise sa clef privée $HOME/.ssh/id_dsa ou $HOME/.ssh/id_rsa pour signer l'identifiant de session, puis envoie le résultat au serveur. Le serveur vérifie si la clef publique correspondante apparaît dans $HOME/.ssh/authorized_keys et accorde l'accès si la clef existe et que sa signature est correcte. L'identifiant de session est dérivé d'une valeur partagée de Diffie-Hellman et n'est connue que du client et du serveur.
Si l'authentification par clef publique échoue ou n'est pas disponible, l'utilisateur peut envoyer un mot de passe crypté pour prouver son identité.
En outre, ssh supporte l'authentification par machine et l'authentification par défi (challenge response).
La version 2 du protocole fournit des mécanismes supplémentaires pour assurer la confidentialité (les communications sont cryptées à l'aide de AES, 3DES, Blowfish, CAST128 ou Arcfour) et l'intégrité (hmac-md5, hmac-sha1, hmac-ripemd160) des données. Il est à noter que la version 1 du protocole ne fournit pas de mécanisme fiable pour garantir l'intégrité de la connexion.
| Connexion et exécution de commandes à distance | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Quand un utilisateur a prouvé son identité, le serveur exécute une commande donnée ou connecte l'utilisateur en lui fournissant un interpréteur de commandes (shell) normal sur la machine distante. Toutes les communications avec la commande distante ou l'interpréteur de commandes distant sont automatiquement cryptées.
Dans le cas où l'utilisateur dispose d'un pseudo-terminal (session de connexion normale), on peut utiliser les caractères d'échappement listés ci-après.
Si l'utilisateur ne dispose pas de pseudo-terminal, la session est transparente, et peut servir à transmettre de manière fiable des données binaires. Sur la plupart des systèmes, si le caractère d'échappement est réglé à « none », la session est transparente, même si on utilise un terminal.
La session prend fin quand la commande ou l'interpréteur de commandes sur la machine distante se termine, et que toutes les connexions X11 ou TCP/IP ont été fermées. Le code de retour du programme distant est retourné comme code de retour de ssh
| Caractères d'échappement | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Quand on utilise un pseudo-terminal, ssh supporte quelques fonctions via l'utilisation du caractère d'échappement.
Pour envoyer un simple tilde, il faut taper ~~ ou faire suivre un unique tilde d'un caractère différent de ceux énumérés ci-après. Pour que le caractère d'échappement soit interprété de manière spéciale, il doit toujours être précédé d'un retour à la ligne. Il est possible de changer le caractère d'échappement dans les fichiers de configuration à l'aide la directive EscapeChar ou sur la ligne de commande à l'aide de l'option -e
Les séquences d'échappement supportées (on considère que « ~ » est le caractère d'échappement, la configuration par défaut) sont :
Déconnecte.
Fait passer ssh en arrière-plan.
Liste les connexions transférées.
Fait passer ssh en arrière-plan lors de la déconnexion, si des transferts de connexions ou des sessions X11 sont toujours en cours.
Affiche la liste des caractères d'échappement.
Émet un BREAK au système distant (uniquement pour la version 2 du protocole SSH, et si la machine d'en face le supporte).
Ouvre une ligne de commande. Utile pour ajouter des transferts de port (port forwarding) à l'aide des options -L et -R (cf ci-après). Cela permet également la fermeture de transfert de port en cours, en utilisant -KR hostport Une aide rudimentaire est disponible avec l'option -h
Demande un nouvel échange de clef pour la connexion (uniquement pour la version 2 du protocole SSH, et si la machine d'en face le supporte).
| Transfert X11 et TCP (X11 and TCP forwarding) | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Si la variable ForwardX11 est réglée à « yes » (voir, à ce sujet, la description des options -X et -x ci-après) et que l'utilisateur utilise X11 (la variable d'environnement DISPLAY est réglée), la connexion à l'affichage X11 est transférée automatiquement à la machine distante. De cette manière, tout programme X11 démarré depuis l'interpréteur de commandes, ou depuis une commande, passe par le canal crypté, et la connexion au serveur X est réalisée sur la machine locale. On ne doit pas régler manuellement la variable DISPLAY Le transfert des connexions X11 peut être configuré en la ligne de commande ou à l'aide des fichiers de configuration.
La valeur de la variable DISPLAY réglée par ssh pointe vers la machine serveur, mais avec un numéro d'affichage plus grand que zéro. C'est normal, puisque ssh crée un serveur X « mandataire » (proxy) qui sert à transférer les connexions à travers le canal crypté.
ssh règle aussi automatiquement Xauthority sur la machine serveur. Pour ce faire, il génère un cookie d'authentification aléatoire, l'enregistre dans le Xauthority du serveur, puis vérifie que toutes les connexions sont bien porteuses de ce cookie, et le remplace par le vrai cookie lors de l'ouverture de la connexion. Le vrai cookie d'authentification n'est jamais envoyé au serveur (et aucun cookie n'est envoyé en clair).
Si la variable ForwardAgent est réglée à « yes » (voir, à ce sujet, la description des options -A et -a ci-après) et que l'utilisateur se sert d'un agent d'authentification, la connexion à l'agent est transférée automatiquement vers la machine distante.
On peut spécifier le transfert de connexions TCP/IP arbitraires via le canal sécurisé sur la ligne de commande, ou dans un fichier de configuration. Une application possible du transfert TCP/IP est la connexion à une bourse électronique. Le transfert TCP/IP peut aussi permettre de passer à travers des pare-feux (firewalls).
| Authentification du serveur | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
ssh maintient automatiquement une base de données qui contient les identifiants de toutes les machines déjà visitées.
Les clefs des machines sont enregistrées dans le fichier $HOME/.ssh/known_hosts du répertoire personnel de l'utilisateur. ssh vérifie en plus automatiquement le fichier /etc/ssh/ssh_known_hosts pour contrôler si des machines sont connues.
Les nouvelles machines sont ajoutées automatiquement au fichier de l'utilisateur. En cas de changement dans un identifiant de machine, ssh le signale, et désactive la méthode d'authentification par mot de passe pour empêcher la capture du mot de passe par un cheval de Troie, par exemple. Ce mécanisme a aussi pour but d'éviter les attaques de type « man-in-the-middle » qui permettraient autrement de contourner le cryptage. L'option StrictHostKeyChecking permet d'empêcher de se connecter à des machines dont la clef d'hôte serait inconnue ou aurait changé.
ssh peut être configuré pour vérifier l'identité d'une machine distante à l'aide d'une base de ressource d'empreintes (SSHFP) publiée par un DNS. L'option VerifyHostKeyDNS peut être utilisée pour contrôler la manière avec laquelle les requêtes DNS sont effectuées. Une base de ressource d'empreintes peut être générée en utilisant ssh-keygen1.
Les options sont les suivantes :
Force ssh à n'essayer que la version 1 du protocole.
Force ssh à n'essayer que la version 2 du protocole.
Force ssh à n'utiliser que des adresses IPv4.
Force ssh à n'utiliser que des adresses IPv6.
Active le transfert de connexion de l'agent d'authentification. Peut aussi être spécifié machine par machine dans un fichier de configuration.
Il ne faut activé le transfert d'agent qu'avec précaution. En effet, les utilisateurs capables de contourner les permissions des fichiers sur la machines distante (pour obtenir la socket unix-domain de l'agent) peuvent accéder à l'agent local via le transfert de connexion. Un attaquant ne peut pas obtenir d'information sur les clefs à partir de l'agent, en revanche il peut effectuer des opérations sur les clefs lui permettant de s'authentifier avec l'identité chargée dans l'agent.
Désactive le transfert de connexion de l'agent d'authentification.
Précise une interface réseau émettrice sur une machine qui en possède plusieurs, ou qui a des alias d'adresses réseau.
Active la compression de toutes les données (entrée standard, sortie standard, erreur standard, et toutes les connexion X11 et TCP/IP transférées). L'algorithme de compression est le même que celui de gzip(1), et le « niveau » de compression peut être défini par l'option CompressionLevel La compression est souvent souhaitable sur les lignes modem ou les connexions lentes, mais elle ne cause que le ralentissement du trafic si elle est activée sur un réseau rapide. On peut aussi spécifier la valeur par défaut pour une machine donnée dans les fichiers de configuration. Voir l'option Compression
Choisit une spécification de cryptage pour la session.
La version 1 du protocole ne supporte la sélection que d'un cryptage. Les valeurs disponibles sont « 3des », « blowfish » et « des ». 3des (triple-des) est un algorithme de cryptage-décryptage-cryptage triple qui utilise trois clefs différentes. C'est un bon choix, du point de vue de la sécurité. blowfish est un cryptage de bloc rapide. Il semble très bien sécurisé et est beaucoup plus rapide que 3des des n'est supporté dans le client ssh que pour l'interopérabilité avec les implantations de la version 1 du protocole qui ne supportent pas le cryptage 3des Compte tenu de ses faiblesses cryptographiques, son utilisation est fortement déconseillée. L'option par défaut est « 3des ».
En ce qui concerne la version 2 du protocole, crypt_spec est une liste des cryptages classés par ordre de préférence et séparés par des virgules.
Les cryptages supportés sont « 3des-cbc », « aes128-cbc », « aes192-cbc », « aes256-cbc », « aes128-ctr », « aes192-ctr », « aes256-ctr », « arcfour », « blowfish-cbc » et « cast128-cbc ». La valeur par défaut est
« aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
aes192-cbc,aes256-cbc »
Spécifie un transfert « dynamique » des ports au niveau applicatif. Ceci fonctionne grâce à l'allocation d'une socket qui écoute sur le port port de la machine locale, et qui, dès qu'une connexion est établie sur ce port, la transfère à travers le canal sécurisé. Le protocole applicatif est alors utilisé pour déterminer vers où se connecter à partir de la machine distante. À l'heure actuelle, les protocoles SOCKS4 et SOCKS5 sont supportés, et ssh se comporte alors comme un serveur SOCKS. Seul root peut transférer des ports privilégiés.
On peut aussi spécifier un transfert de port dynamique dans le fichier de configuration.
Spécifie le caractère d'échappement pour les sessions avec un pseudo-terminal (pty). Par défaut « ~ ». Le caractère d'échappement est reconnu uniquement en début de ligne. Le caractère d'échappement suivi d'un point (« . ») ferme la connexion ; suivi de Contrôle-Z suspends la connexion, et suivi de lui-même, envoie le caractère d'échappement une seule fois.
En réglant le caractère d'échappement à « none », on supprime tout caractère d'échappement, et on rend la session totalement transparente.
Spécifie un autre fichier de configuration utilisateur. Si on fournit un chemin vers un fichier sur la ligne de commande, le fichier (/etc/ssh/ssh_config ) qui est utilisé pour toute la machine, est ignoré. L'emplacement par défaut pour le fichier de configuration utilisateur est $HOME/.ssh/config
Demande à ssh de basculer en arrière-plan juste avant d'exécuter la commande. C'est particulièrement utile si ssh demande des mots de passe ou des phrases de passe, mais que l'utilisateur veuille que le reste de son exécution s'effectue en arrière-plan. Cela implique l'option -n La méthode recommandée pour exécuter des programmes X11 d'un site distant ressemble à quelque chose comme : ssh -f host xterm
Permet à des machines distantes de se connecter à des ports transférés locaux.
Spécifie quel lecteur de carte à puces utiliser. Le paramètre est le fichier spécial correspondant au lecteur de carte à puces que le programme ssh utilisera pour stocker la clef privée RSA de l'utilisateur.
Spécifie un fichier qui contient l'identité (la clef privée) à utiliser pour l'authentification RSA ou DSA. Par défaut $HOME/.ssh/identity pour la version 1 du protocole, et $HOME/.ssh/id_rsa et $HOME/.ssh/id_dsa pour la version 2 du protocole. On peut aussi spécifier l'emplacement des fichiers d'identité pour une machine donnée dans le fichier de configuration. On peut spécifier plusieurs options -i (et plusieurs identités dans les fichiers de configuration).
Désactive les transferts (délégation) d'identifiants GSSAPI vers le serveur.
l'hôte et le port donné depuis la machine distante. Ceci fonctionne grâce à l'allocation d'une socket qui écoute sur le port port de la machine locale, et qui, dès qu'une connexion est établie sur ce port, la transfère à travers le canal sécurisé, et se connecte à host sur le port hostport depuis la machine distante. On peut aussi spécifier des transferts de port (port forwardings) dans le fichier de configuration. Seul root peut transférer des ports privilégiés.
Il est possible de spécifier des adresses IPv6 à l'aide d'une autre syntaxe : N° port / N° host hostport
Spécifie un nom d'utilisateur à utiliser pour la connexion sur la machine distante. On peut aussi le spécifier pour une machine donnée dans le fichier de configuration.
Place le client ssh en mode « maître » pour effectuer du partage de connexion. Pour de plus amples détails, veuillez vous référer à la description de ControlMaster dans ssh_config5.
Pour la version 2 du protocole, spécifie une liste d'algorithmes MAC (Message Authentification Code, code d'authentification de message) séparés par des virgules et classés par ordre de préférence. Voir le mot-clef MACs pour plus d'information.
N'exécute aucune commande distante. Utilisé pour les transferts de ports (seulement dans la version 2 du protocole).
redirige l'entrée standard vers /dev/null (en fait, empêche la lecture depuis l'entrée standard). À utiliser lors d'une utilisation de ssh en arrière-plan. On peut s'en servir pour exécuter des programmes X11 sur une machine distante. Par exemple, ssh -n shadows.cs.hut.fi emacs démarre un emacs sur shadows.cs.hut.fi, et la connexion X11 est transférée automatiquement dans le canal crypté. Le programme ssh est basculé en arrière-plan. Ne fonctionne pas si ssh a besoin d'un mot de passe ou d'une phrase de passe ; Voir l'option -f
Utilisé pour passer des options dans le format du fichier de configuration. Par exemple, pour spécifier des options qui n'ont pas d'équivalent en ligne de commande. Pour obtenir des détails sur les options listées ci-après, ainsi que les valeurs autorisées, veuillez vous référer à ssh_config5.
Port à connecter sur la machine distante. On peut aussi le spécifier pour une machine donnée dans le fichier de configuration.
Mode silencieux. Supprime tous les messages d'avertissement et de diagnostic.
l'hôte et le port donné depuis la machine locale. Ceci fonctionne grâce à l'allocation d'une socket qui écoute sur le port port de la machine distante, et qui, dès qu'une connexion est établie sur ce port, la transfère à travers le canal sécurisé, et se connecte à host sur le port hostport depuis la machine locale. On peut aussi spécifier des transferts de port (port forwardings) dans le fichier de configuration. On ne peut transférer des ports privilégiés que si on se connecte en tant que root sur la machine distante. Il est possible de spécifier des adresses IPv6 à l'aide d'une autre syntaxe : N° port / N° host hostport
Indique l'emplacement de la socket de contrôle pour le partage de connexion. Voir les descriptions de ControlPath et ControlMaster dans ssh_config5 pour plus de détails.
Invoque un sous-système sur la machine distante. Les sous-systèmes sont une fonctionnalité de la version 2 du protocole, et simplifient l'utilisation de SSH pour la transmission sécurisée d'autres applications (par exemple sftp(1)). La commande distante spécifie le sous-système.
Désactive l'allocation de pseudo-terminal.
Force l'allocation d'un pseudo-terminal. Utilisé pour exécuter des programmes en mode écran sur la machine distante. En particulier, c'est fort utile pour les applications qui implémentent des services de menu. En ajoutant des options -t on force l'allocation de terminaux, même si ssh n'a pas de terminal local.
Affiche le numéro de version et quitte.
Mode bavard. ssh affiche des messages de diagnostic sur ce qu'il fait. Fort utile pour résoudre des problèmes de connexion, d'authentification ou de configuration. En ajoutant des options -v ssh devient de plus en plus bavard. Au maximum 3.
Active le transfert X11. On peut aussi le spécifier pour une machine donnée dans le fichier de configuration.
Le transfert X11 doit être activé avec précaution. En effet, les utilisateurs capables de contourner les permissions des fichiers sur la machines distante (pour accéder à la base de donnée d'accréditation de X) peuvent accéder au à l'écran X11 local via le transfert de connexion. Un attaquant pourrait alors effectuer des opérations telles qu'enregistrer la frappe.
Désactive le transfert X11.
Active un transfert X11 de confiance.
| FICHIERS DE CONFIGURATION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
ssh peut accessoirement obtenir des données de configuration depuis des fichiers utilisateur, ou depuis un fichier de configuration pour le système. Le format du fichier et les options de configuration sont décrits dans ssh_config5.
| ENVIRONNEMENT | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
ssh règle normalement les variables d'environnement suivantes :
La variable d'environnement DISPLAY indique l'emplacement du serveur X11. Elle est réglée automatiquement par ssh à une valeur comme « hostname:n » où hostname indique la machine sur laquelle s'exécute l'interpréteur de commandes, et n est un entier strictement positif (n 1). ssh utilise cette valeur spéciale pour transférer les connexions X11 à travers le canal sécurisé. Normalement, l'utilisateur ne doit pas modifier cette variable explicitement, ce qui aurait pour résultat de rendre la connexion non sécurisée (et obligerait l'utilisateur à copier manuellement les cookies d'accréditation).
Règle l'emplacement du répertoire personnel de l'utilisateur.
Synonyme pour USER Utilisé pour la compatibilité avec les systèmes qui utilisent cette variable.
Emplacement de la boîte à lettres de l'utilisateur.
Réglé à la valeur de la variable PATH spécifiée lors de la compilation de ssh
Si ssh nécessite une phrase de passe, il la lit depuis le terminal en cours s'il est exécuté depuis un terminal. Si ssh n'est pas associé à un terminal, mais peut lire les variables d'environnement DISPLAY et SSH_ASKPASS, il exécute le programme spécifié dans SSH_ASKPASS et ouvre une fenêtre X11 pour lire la phrase de passe. C'est particulièrement utile lors d'un appel de ssh depuis .Xsession ou un script équivalent. (Note : sur certaines machines, il peut être nécessaire de rediriger l'entrée depuis /dev/null pour que tout fonctionne.)
Identifie le chemin de la socket unix-domain utilisée pour communiquer avec l'agent.
Identifie les deux bouts de la connexion (le client et le serveur). La variable contient quatre valeurs séparées par des espaces : l'adresse IP du client, le numéro de port du client, l'adresse IP du serveur et le numéro de port du serveur.
Cette variable contient la ligne de commande originale si une commande a été fournie. On peut utiliser cette variable pour extraire les arguments originaux.
Contient le nom du terminal (emplacement du fichier spécial) associé à l'interpréteur de commandes ou à la commande en cours. Si la session n'a pas de terminal, la variable n'existe pas.
Cette variable indique le fuseau horaire si la variable était réglée lors du démarrage du démon. (c'est à dire que le démon la passe aux nouvelles connexions).
Contient le nom de l'utilisateur connecté.
En outre, ssh lit le fichier $HOME/.ssh/environment et ajoute les lignes qui possèdent le format « NOMDEVARIABLE=valeur » à l'environnement, si le fichier existe que les utilisateurs sont autorisés à modifier leur environnement. Pour plus d'information, veuillez vous rapporter à l'option PermitUserEnvironment dans sshd_config5.
| FICHIERS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Enregistre les clefs de tous les hôtes sur lesquelles l'utilisateur s'est connecté et qui n'apparaissent pas dans le fichier /etc/ssh/ssh_known_hosts Voir sshd(8).
Contiennent les identités d'authentification de l'utilisateur, respectivement pour
RSA du protocole 1, DSA du protocole 2 et RSA du protocole 2. Ces fichiers contiennent des données
sensibles et ne doivent être lisibles que par l'utilisateur et non accessibles
aux autres utilisateurs (en lecture, écriture et exécution).
Note :
ssh
ignore purement et simplement un fichier de clef, s'il est accessible aux autres
utilisateurs.
On peut spécifier une phrase de passe (passphrase) lors de la création de la clef. La phrase de passe (passphrase) est utilisée pour crypter la partie sensible de ce fichier à l'aide de 3DES.
Contiennent les clefs publiques utilisées pour l'authentification (partie publique du fichier d'identité lisible par un humain). Il faut ajouter le contenu du fichier $HOME/.ssh/identity.pub dans le fichier $HOME/.ssh/authorized_keys sur chacune des machines sur lesquelles l'utilisateur souhaite se connecter à l'aide de la méthode d'authentification RSA de la version 1 du protocole. Il faut ajouter le contenu des fichiers $HOME/.ssh/id_dsa.pub et $HOME/.ssh/id_rsa.pub dans le fichier $HOME/.ssh/authorized_keys sur chacune des machines sur lesquelles l'utilisateur souhaite se connecter à l'aide de la méthode d'authentification DSA et RSA de la version 2 du protocole. Le contenu de ces fichiers n'est pas sensible et peut rester accessible aux autres utilisateurs (mais ce n'est pas obligatoire). Ces fichiers ne sont pas nécessaires, et de toute façon jamais utilisés automatiquement. C'est juste une commodité pour l'utilisateur.
C'est le fichier de configuration utilisateur. Le format de ce fichier ainsi que les options de configuration sont décrits dans ssh_config5. Étant donné les abus potentiels, ce fichier doit avoir strictement comme permission : lecture/écriture pour l'utilisateur, et inaccessible aux autres utilisateurs.
Liste les clefs publiques (RSA/DSA) utilisables pour se connecter en tant que cet utilisateur. Le format de ce fichier est décrit dans la page de manuel sshd(8). Dans le cas le plus simple, le format est semblable à celui des fichiers d'identité « .pub ». Ce fichier n'est pas très sensible, mais il est recommandé qu'il soit accessible en lecture/écriture à l'utilisateur, et inaccessible aux autres utilisateurs.
La liste pour tout le système des clefs des machines. Ce fichier doit être préparé par l'administrateur système pour contenir les clefs publiques de toutes les machines accessibles. Ce fichier doit être lisible par tout le monde. Ce fichier contient les clefs publiques (une par ligne) au format suivant (les champs sont séparés par des espaces) : le nom de la machine, la clef publique, et un commentaire optionnel. Si des noms différents sont utilisés pour la même machine, tous les noms doivent être listés, séparés par des virgules. Le format est décrit dans la page de manuel sshd(8).
Le nom canonique de la machine (tel que celui qui est retourné par les serveurs de noms) est utilisé par sshd(8) pour vérifier la machine client lors de la connexion ; les autres noms sont nécessaires car ssh ne convertit pas les noms fournis par l'utilisateur en forme canonique avant de vérifier la clef, parce qu'un utilisateur malintentionné ayant accès au serveur de noms pourrait falsifier l'authentification par machine.
Le fichier de configuration pour toute la machine. Le format de ce fichier et les options de configuration sont décrits dans ssh_config5.
ces trois fichiers contiennent les parties privées des clefs de machines et sont utilisés par les options RhostsRSAAuthentication et HostbasedAuthentication Si on utilise la méthode d'authentification de la version 1 du protocole RhostsRSAAuthentication ssh doit être exécuté avec root comme UID effectif (setuid root), puisque la clef de la machine n'est lisible que par root. Pour la version 2 du protocole, ssh utilise ssh-keysign8 pour accéder à la clef de la machine avec HostbasedAuthentication Ceci supprime la contrainte d'exécuter en tant que root le programme ssh lorsque cette méthode d'authentification est utilisée. Par défaut, ssh n'a pas le bit setuid positionné.
Ce fichier est utilisé par l'authentification par rhosts pour lister les paires machine/utilisateur autorisées à se connecter. Note : rlogin et rsh utilisent également ce fichier, ce qui rend son utilisation avec ssh peu fiable. Chaque ligne du fichier contient un nom de machine (dans la forme canonique retournée par les serveurs de noms), puis un nom d'utilisateur de cette machine, séparés par un espace. Sur certaines machines, ce fichier doit être lisible par tous les utilisateurs, si le répertoire personnel de l'utilisateur est sur une partition NFS, parce que sshd(8) lit ce fichier en tant que root. En outre, ce fichier doit être la propriété de l'utilisateur, et ne doit autoriser l'écriture pour personne d'autre. Les permissions recommandées pour la plupart des machines sont : lecture/écriture pour l'utilisateur, et non accessible pour les autres utilisateurs.
Note : par défaut, sshd(8) est installé de telle manière qu'il nécessite une authentification RSA par machine avant d'autoriser une authentification par rhosts Si la machine serveur n'a pas la clef de la machine cliente dans son fichier /etc/ssh/ssh_known_hosts elle peut être enregistrée dans le fichier $HOME/.ssh/known_hosts La manière la plus simple pour l'enregistrer est de se connecter à la machine cliente depuis la machine serveur à l'aide de ssh : ceci ajoute automatiquement la clef de la machine au fichier $HOME/.ssh/known_hosts
Ce fichier est utilisé exactement de la même façon que le fichier .rhosts Le but de ce fichier est de pouvoir utiliser les authentifications par rhosts avec ssh sans autoriser de connexions avec rlogin(1) ou rsh(1).
Ce fichier est utilisé lors des authentifications rhosts Il contient les noms de machine canoniques, un par ligne (le format complet est décrit dans la page de manuel de sshd(8)). Si la machine cliente apparaît dans ce fichier, la connexion est autorisée automatiquement, si le nom de l'utilisateur est le même côté client et serveur. En outre, une authentification RSA par machine est normalement nécessaire. Seul root doit avoir la permission d'écrire dans ce fichier.
Ce fichier est traité exactement comme le fichier /etc/hosts.equiv Il peut servir à autoriser des connexions avec ssh mais sans utiliser rsh/rlogin.
Les commandes contenues dans ce fichier sont exécutées par ssh lors de la connexion de l'utilisateur, juste avant l'exécution de l'interpréteur de commande ou de la commande. Voir la page de manuel de sshd(8) pour plus d'information.
Les commandes contenues dans ce fichier sont exécutées par ssh lors de la connexion de l'utilisateur, juste avant l'exécution de l'interpréteur de commande ou de la commande. Voir la page de manuel de sshd(8) pour plus d'informations.
Contient des définitions de variables d'environnement supplémentaires. Voir la section Sx ENVIRONNEMENT ci-avant.
| DIAGNOSTICS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| VOIR AUSSI | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
gzip(1), rsh(1), scp(1), sftp(1), ssh-add1, ssh-agent1, ssh-keygen1, telnet(1), hosts.equiv5, ssh_config5, ssh-keysign8, sshd(8)
T. Ylonen T. Kivinen M. Saarinen T. Rinne S. Lehtinen "SSH Protocol Architecture" draft-ietf-secsh-architecture-12.txt January 2002 work in progress material
| AUTEURS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
OpenSSH est dérivé de la version originale et libre ssh 1.2.12 par Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt et Dug Song ont corrigé de nombreux bugs, ré-ajouté des nouvelles fonctionnalités et créé OpenSSH. Markus Friedl a contribué au support des versions 1.5 et 2.0 du protocole SSH.
| TRADUCTION FRANÇAISE | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Laurent Gautrot <l dot gautrot at free dot fr> 25/10/2002. Mise à jour par Éric Piel <eric dot piel at tremplin-utc dot net> 14/03/2005.
| 5 : ssh_config Fichier de configuration de ssh | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| ssh_config | Début | Suivant | Sommaire | Préc.page.lue | Accueil |
Section: File Formats (5)
Sommaire
BSD mandoc
| NOM | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| SYNOPSIS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| DESCRIPTION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
ssh obtient ses données de configuration depuis les sources suivantes, et dans l'ordre suivant : la ligne de commande, le fichier de configuration de l'utilisateur ($HOME/.ssh/config ) et enfin le fichier de configuration de la machine (/etc/ssh/ssh_config )
Pour chaque paramètre, on utilise la première valeur obtenue. Les fichiers de configuration peuvent contenir des sections de spécifications par machine (« Host »). Les paramètres contenus dans ces sections ne s'appliquent que pour les machines qui correspondent à un des motifs de la spécification. Le nom de machine est celui qui est passé sur la ligne de commande.
Comme c'est la première valeur de chaque qui est utilisée, on peut préciser des paramètres spécifiques aux machines vers le début du fichier, et les valeurs par défaut vers la fin.
Le fichier de configuration a le format suivant :
Les commentaires sont les lignes vides, et celles qui commencent par le caractère « # ».
Dans les autres cas, une ligne a le format « mot-clef arguments ». On peut séparer les options de configuration avec des espaces ou des espaces optionnels, et un seul caractère « = ». Ce dernier format est utile pour pouvoir se passer de l'espace lorsqu'on utilise l'option -o de ssh scp et sftp.
Les mots-clef possibles et leur signification sont détaillés ci-après.
Note : Les mots-clef ne sont pas sensibles à la casse, mais les valeurs le sont.
Restreint les déclarations suivantes (jusqu'au prochain mot-clef Host aux machines qui correspondent aux motifs passés après le mot-clef. On peut utiliser les caractères joker « * » et « ? » dans les motifs.
On peut utiliser un simple « * » pour définir des valeurs par défaut pour toutes les machines.
La machine est l'argument hostname passé sur la ligne de commande, c'est-à-dire que le nom n'est pas converti en nom canonique avant la mise en correspondance.
Précise si on envoie des jetons AFS (AFS tokens) à la machine distante. L'argument pour ce mot-clef est « yes » ou « no ». Cette option ne s'applique qu'à la version 1 du protocole.
Si l'argument est « yes », il n'y a pas de demande de mots de passe. Utile dans des scripts ou autres traitements par lot, quand il n'y a pas d'utilisateur dans les parages pour saisir les mots de passe. L'argument pour ce mot-clef est « yes » ou « no ». Par défaut « no ».
Spécifie une interface réseau pour l'émission, si on se trouve sur une machine avec plusieurs interfaces réseau, ou avec des adresses aliasées.
Note : Cette option ne fonctionne pas si le mot-clef UsePrivilegedPort a pour argument « yes ».
Spécifie si on utilise une méthode simulation/réponse (challenge response) pour l'authentification. L'argument pour ce mot-clef est « yes » ou « no ». Par défaut « yes ».
Si l'argument est « yes », ssh vérifie en plus l'adresse IP dans le fichier known_hosts Ceci permet de vérifier si une clef de machine a changé à cause d'une falsification de DNS. Si l'argument est « no », la vérification n'est pas effectuée. Par défaut « yes ».
Spécifie le cryptage à utiliser pour la session, dans la version 1 du protocole. Actuellement, « blowfish », « 3des » et « des » sont supportés.
des n'est supporté dans le client ssh que pour l'interopérabilité avec les anciennes implémentations de la version 1 du protocole qui ne supportent pas le cryptage 3des Son utilisation est fortement déconseillée à cause de ses faiblesses crytographiques.
Par défaut « 3des ».
Spécifie les cryptages à utiliser pour la version 2 du protocole par ordre de préférence. Les cryptages multiples sont séparés par des virgules.
Par défaut :
« aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
aes192-cbc,aes256-cbc ».
Spécifie que toutes les redirections de ports locaux, distants et dynamiques déclarés dans les fichiers de configuration ou sur la ligne de commande doivent être purgés.
Ce mot clef est utilisé principalement sur la ligne de commande de ssh pour purger les redirections de ports définis dans les fichiers de configuration, et est automatiquement défini par scp(1) et sftp(1). L'argument pour ce mot-clef est « yes » ou « no ». Par défaut « no ».
Spécifie si on utilise la compression. L'argument pour ce mot-clef est « yes » ou « no ». Par défaut « no ».
Spécifie un niveau de compression, si la compression est activée. L'argument est un entier de 1 (rapide) à 9 (meilleure compression, mais plus lent). Par défaut, le niveau est 6, ce qui est un bon compromis pour la plupart des applications. La signification de ces valeurs est identique à celle de gzip(1). Note : Cette option ne s'applique que pour la version 1 du protocole.
Spécifie le nombre de tentatives (une par seconde) avant d'abandonner. L'argument pour ce mot-clef doit être un entier. Utile pour des scripts si des connexions échouent parfois.
Par défaut 1.
Spécifie un port TCP/IP à rediriger sur la machine locale par le tunnel sécurisé. Le protocole de l'application est ensuite utilisé pour déterminer le port pour se connecter depuis la machine distante. L'argument pour ce mot-clef est un numéro de port. Actuellement, le protocole SOCKS4 est supporté, et ssh se comporte comme un serveur SOCKS4. On peut spécifier des multiples redirections de ports, et on peut en ajouter sur la ligne de commande. Seul root a le droit de rediriger des ports privilégiés.
Définit un caractère d'échappement. Par défaut « ~ ». On peut aussi définir le caractère d'échappement sur la ligne de commande. L'argument pour ce mot-clef doit être un caractère unique « ^ » suivi d'une lettre, ou « none » pour désactiver complètement le caractère d'échappement (rend la connexion transparente pour les données binaires).
Spécifie si la connexion à l'agent d'authentification (s'il existe) doit être redirigée vers la machine distante. L'argument pour ce mot-clef est « yes » ou « no ». Par défaut « no ».
Spécifie si les connexions X11 sont redirigées automatiquement dans le tunnel sécurisé, et la variable d'environnement DISPLAY définie. L'argument pour ce mot-clef est « yes » ou « no ». Par défaut « no ».
Spécifie si des machines distantes sont autorisées à se connecter aux ports locaux redirigés. Par défaut ssh branche les ports redirigés sur une adresse de bouclage (loopback). Ceci évite que des machines distantes ne se connectent à des ports locaux redirigés.
On peut utiliser le mot-clef GatewayPorts pour spécifier que ssh doit connecter les ports redirigés sur une adresse joker (wildcard), et par conséquent, autorise les machines distantes à se connecter aux ports redirigés.
L'argument pour ce mot-clef est « yes » ou « no ». Par défaut « no ».
Spécifie un fichier de base de données globale des clefs de machines à utiliser à la place de /etc/ssh/ssh_known_hosts
Spécifie si on tente d'utiliser l'authentification basées sur les rhosts avec l'authentification par clef publique. L'argument pour ce mot-clef est « yes » ou « no ». Par défaut « no ». Cette option ne s'applique que pour la version 2 du protocole et est similaire à RhostsRSAAuthentication
Spécifie l'algorithme de clef de machine pour la version 2 du protocole que le client souhaite utiliser par ordre de préférence. La valeur par défaut pour cette option est « ssh-rsa,ssh-dss ».
Spécifie un alias à utiliser au lieu du vrai nom de machine lors des recherches et des sauvegardes de clef de machine dans les fichiers de base de données des clefs de machine. Cette option est utile pour faire passer plusieurs connexions ssh par un tunnel sécurisé, ou si plusieurs serveurs tournent sur une seule machine.
Spécifie le vrai nom de la machine sur laquelle on se connecte. Utile pour spécifier des surnoms ou des diminutifs pour des machines.
Par défaut : le nom passé sur la ligne de commande. Les adresses adresses IP (forme numérique, donc) sont aussi autorisées, à la fois sur la ligne de commande et par l'intermédiaire du mot-clef HostName
Spécifie un fichier contenant la clef de l'utilisateur pour l'authentification RSA ou DSA. Par défaut $HOME/.ssh/identity pour la version 1 du protocole, et $HOME/.ssh/id_rsa et $HOME/.ssh/id_dsa pour la version 2 du protocole. En outre, toutes les identités déjà chargées dans l'agent d'authentification sont également utilisées pour l'authentification. Le nom de fichier peut débuter par le caractère « ~ » pour faire référence au répertoire de base (home directory) de l'utilisateur. On peut spécifier plusieurs fichiers d'identité dans les fichiers de configuration. Si c'est le cas, on essaie toutes les identités en séquence.
Spécifie si le système doit envoyer des messages TCP de maintien de la connexion à l'autre machine. Si on envoie ces messages, les ruptures de connexion ou les plantages d'une des machines sont correctement signalés.
Sinon, des connexions peuvent être coupées si la route entre les deux machines est temporairement interrompue, et ça peut être gênant.
Par défaut « yes » (pour envoyer les messages de maintien de la connexion), et le client signale si des coupures de réseau on lieu, ou si la machine distante se plante. Cette fonction est importante pour les scripts, et de nombreux utilisateurs la veulent aussi.
Pour désactiver les messages de maintien de la connexion, il faut régler la valeur à « no ».
Spécifie si on utilise une authentification Kerberos.
L'argument pour ce mot-clef est « yes » ou « no ».
Spécifie si on peut transférer un TGT Kerberos au serveur. Ceci ne fonctionne que si le serveur Kerberos est vraiment un kaserver AFS. L'argument pour ce mot-clef est « yes » ou « no ».
Spécifie qu'un port TCP/IP sur la machine locale est redirigé par le tunnel sécurisé vers un port particulier sur la machine distante. Le premier argument est un numéro de port, et le second est de la forme machine:port Pour les adresse IPv6, on utilise la syntaxe : machine/port On peut spécifier plusieurs redirections de port, et on peut en ajouter en les passant en paramètres sur la ligne de commande. Seul root peut rediriger des ports privilégiés.
Spécifie un niveau de verbosité pour enregistrer les messages de ssh Les valeurs possibles sont : QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2 et DEBUG3. Par défaut INFO. DEBUG et DEBUG1 sont équivalents. DEBUG2 et DEBUG3 spécifient les niveaux de verbosité les plus élevés pour la sortie.
L'algorithme MAC est utilisé dans la version 2 du protocole pour la protection de l'intégrité des données. On peut spécifier plusieurs algorithmes en les séparants par des virgules. Par défaut « hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 ».
On peut utiliser cette option si le répertoire de base (home directory) est partagé par plusieurs machines. Dans ce cas, la machine locale se réfère à une machine différente sur toutes les machines, et l'utilisateur peut recevoir plusieurs avertissements parce que des clefs de machines ont changé. Cette option désactive l'authentification par machine pour la machine locale. L'argument pour ce mot-clef est « yes » ou « no ». Par défaut, on vérifie la clef de machine pour la machine locale.
Spécifie le nombre de tentatives de saisie de mot de passe avant d'abandonner. L'argument pour ce mot-clef est un entier. Par défaut 3.
Spécifie si on utilise l'authentification par mot de passe. L'argument pour ce mot-clef est « yes » ou « no ». Par défaut « yes ».
Spécifie le port pour se connecter sur la machine distante. Par défaut 22.
Spécifie l'ordre dans lequel on essaie les méthodes d'authentification pour la version 2 du protocole. Cette option permet au client de choisir une méthode (par exemple keyboard-interactive plutôt qu'une autre (par exemple password ) Par défaut « hostbased,publickey,keyboard-interactive,password ».
Spécifie la version du protocole que ssh doit supporter, par ordre de préférence. Les valeurs possibles sont « 1 » et « 2 ». On peut spécifier plusieurs valeurs en les séparant par des virgules.
Par défaut « 2,1 ». Ce qui signifie que ssh essaie la version 2 du protocole, puis la version 1 du protocole si la version 2 n'est pas disponible.
Spécifie la commande à utiliser lors de la connexion au serveur. La chaîne de caractère contenant la commande est comprise jusqu'à la fin de la ligne, et est exécutée en utilisant l'interpréteur de commandes (shell) /bin/sh Dans la chaîne de commande, on peut substituer le nom de la machine sur laquelle on se connecte par « %h » et le port par « %p ». La commande peut être absolument n'importe quoi, et doit lire depuis son entrée standard et écrire sur sa sortie standard. Elle peut éventuellement se connecter sur un serveur sshd(8) tournant sur une machine, ou exécuter sshd -i ailleurs.
La gestion des clefs de machine est assurée en utilisant le nom de la machine (option « HostName ») sur laquelle on se connecte (par défaut, le nom fourni par l'utilisateur). Note : CheckHostIP n'est pas disponible pour les connexions qui utilisent une commande mandataire (proxy command).
Spécifie si on utilise l'authentification par clef publique. L'argument pour ce mot-clef est « yes » ou « no ». Par défaut « yes ». Cette option ne s'applique qu'à la version 2 du protocole.
Spécifie une redirection de port TCP/IP sur la machine distante à travers le tunnel sécurisé, vers la machine et le port spécifiés depuis la machine locale. Le premier argument est un numéro de port, et le second est de la forme machine:port Pour les adresse IPv6, on utilise la syntaxe : machine/port On peut spécifier plusieurs redirections de port, et on peut en ajouter en les passant en paramètres sur la ligne de commande. Seul root peut rediriger des ports privilégiés.
Spécifie si on utilise l'authentification basée sur les rhosts.
Note : Cette déclaration n'affecte que la partie cliente, et n'a aucun effet sur la sécurité. La plupart des serveurs n'autorisent pas ce type d'authentification (RhostsAuthentication), parce qu'elle n'est pas sécurisée. (Voir RhostsRSAAuthentication L'argument pour ce mot-clef est « yes » ou « no ». Par défaut « no ». Cette option ne s'applique que pour la version 1 du protocole.
Spécifie si on utilise l'authentification basée sur les rhosts en conjonction avec une authentification de machine basée sur RSA. L'argument pour ce mot-clef est « yes » ou « no ». Par défaut « no ». Cette option ne s'applique que pour la version 1 du protocole, et nécessite que ssh soit exécutable en tant que root (setuid root).
Spécifie si on utilise l'authentification RSA. L'argument pour ce mot-clef est « yes » ou « no ». On essaie cette authentification seulement si le fichier d'identité existe, ou qu'un agent d'authentification est en cours d'exécution. Par défaut « yes ». Cette option ne s'applique que pour la version 1 du protocole.
Spécifie un lecteur de cartes à puce à utiliser. L'argument de ce mot-clef est le fichier spécial que ssh doit utiliser pour communiquer avec le lecteur de cartes à puces pour stocker la clef privée RSA. Par défaut, aucun fichier spécial n'est spécifié, et le support des lecteurs de cartes à puces est désactivé.
Si cette option a pour argument « yes », ssh ne demande pas d'ajouter les clefs de machine au fichier $HOME/.ssh/known_hosts et refuse la connexion aux machines dont la clef de machine a changé. Ceci fournit une protection maximale contre les attaques de type « Cheval de Troie », néanmoins peut être gênant si le fichier /etc/ssh/ssh_known_hosts n'est pas très bien maintenu, ou si on se connecte fréquemment à de nouvelles machines.
Cette option impose à l'utilisateur d'ajouter manuellement toutes les nouvelles machines.
Si cette option a pour argument « no », ssh ajoute automatiquement les nouvelles clefs de machine aux fichiers des machines connues.
Si cette option a pour argument « ask », ssh ajoute les nouvelles clefs de machine aux fichiers des machines connues si l'utilisateur confirme que c'est ce qu'il veut faire, et refuse de se connecter aux machines dont la clef a changé. Les clefs des machines connues sont vérifiées dans tous les cas.
L'argument pour ce mot-clef est « yes », « no » ou « ask ». Par défaut « ask ».
Spécifie si on utilise un port privilégié pour les connexions sortantes.
L'argument pour ce mot-clef est « yes » ou « no ». Par défaut « no ». L'argument de ce mot-clef doit être « yes » si on se connecte sur de vieux serveurs qui ont besoin des authentifications « RhostsAuthentication » et « RhostsRSAAuthentication ».
Spécifie un nom d'utilisateur à utiliser pour se connecter. Ceci peut être utile si on se connecte avec des noms d'utilisateurs différents sur des machines différentes, et évite le souci de devoir se rappeler tous les noms d'utilisateurs à passer sur la ligne de commande.
Spécifie un fichier de base de données pour l'utilisateur de clefs de machines à utiliser au lieu de $HOME/.ssh/known_hosts
Spécifie l'emplacement du programme xauth(1). Par défaut /usr/X11R6/bin/xauth
| FICHIERS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
C'est le fichier de configuration utilisateur. Le format de ce fichier est décrit ci-avant. Le client ssh utilise ce fichier. Ce fichier ne contient normalement pas d'informations sensibles, néanmoins, il est recommandé de n'autoriser la lecture/écriture que pour l'utilisateur (son propriétaire), et aucun accès pour les autres.
C'est le fichier de configuration pour toute la machine. Ce fichier définit des valeurs par défaut pour les paramètres qui ne sont pas définis dans les fichiers de configuration des utilisateurs, et pour les utilisateurs qui n'ont pas de fichier de configuration. Ce fichier doit être lisible par tout le monde.
| AUTEURS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
OpenSSH est dérivé de la version originale et libre ssh 1.2.12 par Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt et Dug Song ont corrigé de nombreux bugs, ré-ajouté des nouvelles fonctionnalité et créé OpenSSH. Markus Friedl a contribué au support des versions 1.5 et 2.0 du protocole SSH.
| TRADUCTION FRANÇAISE | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| VOIR AUSSI | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
ssh(1)
| 6 : SFTP CLIENT SFTP | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| sftp | Début | Suivant | Sommaire | Préc.page.lue | Accueil |
| NOM | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| SYNOPSIS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| DESCRIPTION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
La seconde méthode permet de récupérer automatiquement des fichiers si on utilise une méthode d'authentification non interactive ; sinon on procède normalement, après s'être authentifié de manière interactive avec succès.
La dernière méthode permet de démarrer le client sftp dans un répertoire distant.
Les options sont les suivantes :
| COMMANDES INTERACTIVES | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| AUTEURS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| VOIR AUSSI | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| 7 : RSYNC SYNCHRONISATION | Début | Précédent | Sommaire | Préc.page.lue | Accueil |
| rsync | Début | Suivant | Sommaire | Préc.page.lue | Accueil |
Section: Manuel de l'utilisateur Linux (1)
Updated: 28 Juillet 2005
Sommaire
| NOM | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| SYNOPSIS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
rsync [OPTION]... SRC [SRC]... [UTIL@]HOTE:DEST
rsync [OPTION]... [UTIL@]HOTE:SRC [DEST]
rsync [OPTION]... SRC [SRC]... DEST
rsync [OPTION]... [UTIL@]HOTE::SRC [DEST]
rsync [OPTION]... SRC [SRC]... [UTIL@]HOTE::DEST
rsync [OPTION]... rsync://[UTIL@]HOTE[:PORT]/SRC [DEST]
rsync [OPTION]... SRC [SRC]... rsync://[UTIL@]HOTE[:PORT]/DEST
| DESCRIPTION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
rsync est un programme très similaire à rcp, mais possède bien plus d'options et utilise le protocole de mise à jour à distance rsync afin d'accélérer significativement le transfert de fichiers lorsque le fichier de destination existe déjà.
Le protocole de mise à jour à distance rsync permet à rsync de ne transférer que la différence entre deux jeux de fichiers à travers le lien de réseau, en utilisant un algorithme efficace de recherche de somme de contrôle qui est décrit dans le document technique fourni avec ce paquetage.
Quelques possibilités supplémentaires offertes par rsync :
possibilité de copier des liens, périphériques, propriétaires, groupes et permissions
des options exclut et exclut-depuis similaires à GNU tar
un mode d'exclusion CVS pour ignorer les mêmes fichiers que CVS
peut utiliser n'importe quel shell (interpréteur de commandes), y compris rsh et ssh
ne nécessite pas de privilèges root
pipelining des transferts de fichiers pour minimiser les coûts de latence
possibilité d'utilisation de démons rsync anonymes ou avec authentification (idéal pour le miroitage)
| GÉNÉRAL | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Rsync copie des fichiers depuis ou vers un hôte distant, ou localement sur l'hôte actuel (la copie de fichiers entre deux hôtes distants n'est pas prise en charge).
Il y a deux manières pour rsync de contacter le système distant : en utilisant un programme de shell distant comme transport (tel que ssh ou rsh), ou en contactant un démon rsync directement par TCP. Le transport par shell distant est utilisé à chaque fois que le chemin source ou destination contient un séparateur «:» après la spécification de l'hôte. Le contact direct avec un démon rsync est utilisé lorsque le chemin source ou destination contient un séparateur «::» après la spécification de l'hôte, OU lorsqu'une URL rsync:// est spécifiée (voir aussi la section «UTILISER LES FONCTIONNALITÉS D'UN DÉMON RSYNC VIA UNE CONNEXION SHELL DISTANT» pour une exception à cette dernière règle).
Un cas spécial : si la source distante est spécifiée, mais pas la destination, les fichiers distants sont listés avec un affichage similaire à «ls -l».
Intuitivement, si ni la source ni la destination ne spécifient d'hôte distant, la copie est faite en local (voir aussi l'option --list-only).
| MISE EN PLACE | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Consultez le ficher README pour les instructions d'installation.
Une fois installé vous pouvez utiliser rsync vers toute machine à laquelle vous pouvez accéder via un shell distant (ainsi que celles auxquelles vous pouvez accéder via le protocole rsync). Pour les transferts, le rsync moderne utilise ssh, cependant il peut avoir était configuré pour utiliser par défaut un shell distant différent, tel que rsh ou remsh.
Vous pouvez aussi spécifier un autre shell quelconque, soit en utilisant l'option de la ligne de commande -e, ou en utilisant la variable d'environnement RSYNC_RSH.
Une alternative couramment utilisée et offrant un degré de sécurité élevé est ssh.
Notez que rsync doit être installé sur la machine locale ainsi que sur la machine de destination.
| UTILISATION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
rsync s'utilise de la même façon que rcp. Vous devez spécifier une source et une destination, l'une des deux pouvant être distante.
Le meilleur moyen d'expliquer la syntaxe est peut être avec quelques exemples :
rsync -t *.c foo:src/
Ceci transfère tous les fichiers correspondant au motif *.c du répertoire courant vers le répertoire src sur la machine foo. Si un fichier existe déjà sur le système distant, alors le protocole de mise à jour à distance rsync est utilisé pour mettre à jour le fichier en envoyant uniquement les différences. Consultez la documentation technique pour plus de détails.
rsync -avz foo:src/bar /data/tmp
Ceci transfère récursivement tous les fichiers du répertoire src/bar de la machine foo dans le répertoire /data/tmp/bar de la machine locale. Les fichiers sont transférés en mode «archive», ce qui assure la préservation des liens symboliques, périphériques, attributs, permissions, propriétés, etc lors du transfert. De plus les donnés transférées seront compressées.
rsync -avz foo:src/bar/ /data/tmp
Une barre oblique à la fin du chemin source modifie ce comportement pour transférer tous les fichiers du répertoire src/bar de la machine foo dans /data/tmp/. Une barre oblique à la fin d'un chemin source signifie «copie le contenu de ce répertoire». Sans la barre oblique à la fin cela signifie «copie le répertoire». Néanmoins, dans les deux cas, les attributs du répertoire sont transférés au répertoire sur la machine destination. Autrement dit, chacune de ces deux commandes copie les fichiers de la même manière, y compris les attributs de /dest/foo :
rsync -av /src/foo /dest
rsync -av /src/foo/ /dest/foo
Notez également qu'une barre oblique n'est pas nécessaire si vous spécifiez le répertoire par défaut d'un hôte ou d'un module. Par exemple, ces deux lignes copient le contenu du répertoire distant vers «/dest» :
rsync -av hote: /dest
rsync -av hote::module /dest
Vous pouvez aussi utiliser rsync en mode local uniquement, lorsque ni la source ni la destination n'ont de «:» dans leur nom. Dans ce cas rsync fonctionne comme une commande performante de copie.
rsync unhote.mondomaine.com::
Ceci liste tous les modules rsync anonymes, disponibles sur l'hôte unhote.mondomaine.com. (Consultez la section suivante pour plus de détails.)
| UTILISATION AVANCÉE | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
La syntaxe pour récupérer plusieurs fichiers depuis un hôte distant requiert l'utilisation d'espaces protégées dans SRC. Quelques exemples :
rsync hote::'nommod/rep1/fichier1 nommod/rep2/fichier2' /dest
Ceci copie fichier1 et fichier2 vers /dest depuis un démon rsync. Chacun des arguments additionnels doit inclure le même préfixe « nommod» que le premier et doit être précédé d'un espace. Toutes les autres espaces sont considérées comme faisant partie d'un nom de fichier.
rsync -av hote:'rep1/fichier1 rep2/fichier2' /dest
Ceci copie fichier1 et fichier2 vers /dest à l'aide d'un shell distant. La coupure des mots est faite par le shell distant, par conséquent si cela ne fonctionne pas c'est que le shell n'est pas configuré pour couper les arguments sur les caractères blancs (configuration très rare, mais pas impossible). Si vous avez besoin de transférer un fichier dont le nom contient des caractères blancs, il est nécessaire ou bien de protéger ces caractères de manière à ce que le shell distant les interprète correctement, ou bien d'utiliser des méta-caractères à la place des blancs. Voici deux exemples :
rsync -av hote:'nom\ de\ fichier\ avec\ espaces' /dest
rsync -av hote:nom?de?fichier?avec?espaces /dest
Ce second exemple suppose que votre shell passe les méta-caractères non développés. S'il affiche une erreur du type «no match» ou «pas de correspondance», mettez le nom entre guillemets.
| CONNEXION À UN DÉMON RSYNC | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Il est possible également d'utiliser rsync sans utiliser rsh ou ssh comme agents de transport. Dans ce cas, vous vous connecterez directement à un démon rsync distant, en général, en utilisant le port TCP 873. (Bien sûr, cela suppose qu'un démon soit en cours d'exécution sur le système distant ; pour plus d'information à ce sujet, référez-vous à la section DÉMARRER UN DÉMON RSYNC QUI ACCEPTE LES CONNEXIONS ci-dessus.)
Utiliser rsync comme cela est identique à une utilisation via un shell distant excepté que :
vous utilisez soit un double deux-points «::» au lieu de l'unique deux-points pour séparer le nom d'hôte du chemin, soit une URL rsync://.
le premier mot après les «::» est le nom d'un module.
le démon distant peut afficher un message du jour lorsque vous vous connectez.
si vous ne spécifiez pas de chemin sur le démon distant, alors la liste des chemins accessibles sur le démon sera affichée.
si vous ne spécifiez pas de destination locale, alors une liste des fichiers spécifiés sur le démon distant est affichée.
Un exemple qui copie tous les fichiers vers un module distant nommé «src» :
rsync -av hote::src /dest
Certains modules sur le démon distant peuvent nécessiter une authentification. Si c'est le cas, un mot de passe vous sera demandé lors de votre connexion. Vous pouvez éviter la demande de mot de passe en fixant la variable d'environnement RSYNC_PASSWORD à la valeur du mot de passe que vous voulez utiliser ou en utilisant l'option --password-file. Ceci peut être utile en cas d'utilisation de rsync dans des scripts.
AVERTISSEMENT : sur certains systèmes, les variables d'environnement sont visibles par tous les utilisateurs. Sur ces systèmes, l'utilisation de --password-file est recommandée.
Vous pouvez établir la connexion via un proxy web en donnant à la variable d'environnement RSYNC_PROXY une valeur nomdhote:port qui pointe vers votre proxy web. Notez que votre proxy web doit permettre l'utilisation du port 873.
| UTILISER LES FONCTIONNALITÉS D'UN DÉMON RSYNC VIA UNE CONNEXION SHELL DISTANTE | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Il peut parfois être utile d'utiliser différentes fonctionnalités d'un démon rsync (telles que les modules nommés) sans pour autant autoriser de nouvelle socket de connexion à un système (autre que ce qui est déjà requis pour permettre un accès shell distant). Rsync supporte les connexions à un hôte en utilisant un shell distant puis en lançant un serveur «démon» à usage unique qui lit son fichier de configuration dans le répertoire personnel de l'utilisateur distant. Cela peut être utile si vous souhaitez crypter les données de transfert de style démon ; cependant, comme le démon vient d'être démarré par l'utilisateur distant, il se peut que vous ne puissiez pas utiliser les fonctionnalités telles que le chroot ou le changement d'uid par le démon. (Une autre manière de crypter le transfert avec un démon : utiliser ssh pour faire un tunnel vers un port local de la machine distante et ensuite configurer un démon rsync normal sur l'hôte distant qui n'accepte que les connexions depuis «localhost».)
Du point de vue de l'utilisateur, un transfert démon via une connexion shell distant utilise pratiquement la même syntaxe de ligne de commande qu'un transfert avec un démon rsync, excepté que vous devez explicitement spécifier le programme de shell distant sur la ligne de commande via l'option --rsh=COMMANDE. (Spécifier la variable d'environnement RSYNC_RSH n'activera pas cette fonctionnalité.) Par exemple :
rsync -av --rsh=ssh hôte::module /dest
Si vous devez spécifier un utilisateur shell distant différent, n'oubliez pas que le préfixe util@ avant l'hôte spécifie la valeur de l'utilisateur rsync (pour un module qui requière une authentification basée sur l'utilisateur). Cela signifie que vous devez passer l'option «-l util» à ssh lorsque vous spécifiez le shell distant :
rsync -av -e "ssh -l util-ssh" util-rsync@hôte::module /dest
Le nom «util-ssh» sera utilisé au niveau de ssh, tandis que le nom «util-rsync» sera utilisé pour l'accès au module.
| DÉMARRER UN DÉMON RSYNC QUI ACCEPTE LES CONNEXIONS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Afin de se connecter à un démon rsync, le système distant doit avoir un démon déjà en cours d'exécution (ou il faut avoir configuré un service comme inetd pour lancer un démon rsync pour les connexions entrantes sur un port particulier). Pour les informations complètes sur la manière de démarrer un démon qui prend en charge les sockets de connexions entrantes, voir la page de man rsyncd.conf(5) -- ceci est le fichier de configuration du démon, elle contient tout les détails sur la manière de lancer le démon (y compris les configurations autonome et inetd).
Si vous utilisez un transport par shell distant pour le transfert, il n'est pas nécessaire de démarrer manuellement un démon rsync.
| EXEMPLES | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Voici quelques exemples de l'utilisation que je fais de rsync.
Pour sauvegarder le répertoire personnel de mon épouse, qui est constitué de gros fichiers MS Word et de répertoires de courrier électronique, j'utilise un job cron qui exécute
rsync -Cavz . arvidsjaur:backup
chaque nuit à travers un lien PPP vers un répertoire de duplication sur ma machine «arvidsjaur».
Pour synchroniser mon arborescence du code source de samba, j'utilise les cibles de Makefile suivantes :
get:
rsync -avuzb --exclude '*~' samba:samba/ .
put:
rsync -Cavuzb . samba:samba/
sync: get put
ceci me permet de synchroniser avec un répertoire CVS à l'autre bout du lien. J'effectue ensuite des opérations CVS sur la machine distante, ce qui sauve beaucoup de temps car le protocole CVS distant n'est pas très efficace.
Je miroite un répertoire entre mon «ancien» et «nouveau» site ftp avec la command e :
rsync -az -e ssh --delete ~ftp/pub/samba nimbus:"~ftp/pub/tridge"
Ceci est lancé depuis cron plusieurs fois par jour.
| RÉSUMÉ DES OPTIONS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Voici un court résumé des options disponibles dans rsync. Veuillez vous référer à la description détaillée ci dessous pour une description complète.
-v, --verbose plus loquace
-q, --quiet moins loquace
-c, --checksum utilise la somme de contrôle, pas la date ni la taille
-a, --archive mode archivage; identique à -rlptgoD (pas -H)
-r, --recursive visite récursive des répertoires
-R, --relative utilise des noms de chemins relatifs
--no-relative désactive --relative
--no-implied-dirs ne transmet pas les répertoires implicites de -R
-b, --backup effectue des sauvegardes (cf. --suffix et --backup-dir)
--backup-dir=RÉP effectue des sauvegardes dans le répertoire RÉP
--suffix=SUFFIXE suffixe de sauvegarde («~» par défaut sauf si --backup-dir)
-u, --update saute les fichiers plus récents chez le destinataire
--inplace mise à jour de fichiers sur place
-d, --dirs ne transfert pas les répertoires récursivement
-l, --links copie les liens symboliques comme liens symboliques
-L, --copy-links transforme les liens symboliques par les fichiers référencés
--copy-unsafe-links ne transforme que les liens «non-sûrs»
--safe-links ignore les liens extérieurs à l'arborescence
-H, --hard-links préserve les liens matériels
-K, --keep-dirlinks traite les liens de répertoire comme des répertoires
-p, --perms préserve les permissions
-o, --owner préserve le propriétaire (root uniquement)
-g, --group préserve le groupe
-D, --devices préserve les périphériques (root uniquement)
-t, --times préserve les dates
-O, --omit-dir-times omet les répertoires lors de la préservation de date
-S, --sparse traite les fichiers à trous efficacement
-n, --dry-run montre ce qui aurait été transféré
-W, --whole-file copie les fichiers entiers (jamais l'algorithme rsync)
--no-whole-file toujours utiliser l'algorithme rsync incrémental
-x, --one-file-system ne traverse pas les limites du système de fichiers
-B, --block-size=TAILLE force la taille de bloc de la somme de contrôle
-e, --rsh=COMMANDE spécifie un shell distant
--rsync-path=PROGRAMME spécifie le nom de l'exécutable rsync chez le récepteur
--existing met à jour uniquement les fichiers qui existent déjà
--ignore-existing ignore les fichiers qui existent déjà
--remove-sent-files les fichiers envoyés sont supprimés de chez l'émetteur
--del synonyme pour --delete-during
--delete efface les fichiers qui n'existent pas chez l'émetteur
--delete-before efface avant le transfert (par défaut)
--delete-during efface au cours du transfert, pas avant
--delete-after efface après transfert, pas avant
--delete-excluded efface également les fichiers exclus côté réception
--ignore-errors efface même s'il y a eu des erreurs E/S
--force force la suppression de répertoires même non-vides
--max-delete=NUM n'efface pas plus de NUM fichiers
--max-size=TAILLE ne transfert le fichiers plus gros que TAILLE
--partial conserve les fichiers partiellement transférés
--partial-dir=RÉP place les fichiers partiellement transférés dans RÉP
--delay-updates ne remplace les fichiers mis à jour qu'à la fin
--numeric-ids ne remplace pas les uid/gid par des noms d'utilisateur/groupe
--timeout=DURÉE fixe la durée d'attente E/S en secondes
-I, --ignore-times ne saute pas les fichiers similaires par la taille et la date
--size-only saute les fichiers qui sont similaires par la date
--modify-window=NUM compare les dates avec une précision moins fine
-T --temp-dir=RÉP crée des fichiers temporaires dans le répertoire RÉP
-y, --fuzzy se base sur des fichiers similaires si le fichier manque
--compare-dest=RÉP compare les fichiers transmis également à RÉP
--copy-dest=RÉP ...et inclut les fichiers non modifiés
--link-dest=RÉP crée un lien matériel vers les fichiers de RÉP si non modifiés
-z, --compress transfert en compressant les données
-C, --cvs-exclude ignore automatiquement des fichiers, comme le ferait CVS
-f, --filter=RÈGLE ajoute une règle de filtrage de fichier
-F identique à --filter='dir-merge /.rsync-filter'
deuxième fois : --filter='- .rsync-filter'
--exclude=MOTIF exclut les fichiers correspondant au MOTIF
--exclude-from=FICHIER lit des motifs d'exclusion depuis FICHIER
--include=MOTIF n'exclut pas les fichiers correspondant au MOTIF
--include-from=FICHIER lit des motifs d'inclusion depuis FICHIER
--files-from=FICHIER lit des fichiers à transférer depuis FICHIER
-0, --from0 tous les fichiers des *-from/filtres sont séparés par 0
--address=ADRESSE se lie à l'adresse pour la connexion sortante vers le démon
--port=PORT spécifie un autre numéro de port rsyncd
--blocking-io utilise des E/S bloquantes pour le shell distant
--no-blocking-io désactive les E/S bloquantes
--stats affiche quelques statistiques de transfert de fichiers
--progress montre l'avancement pendant le transfert
-P équivalent à --partial --progress
-i, --itemize-changes affiche un résumé des changements pour chaque mise à jour
--log-format=FORMAT affiche les noms fichiers selon le format spécifié
--password-file=FICHIER lit le mot de passe depuis FICHIER
--list-only liste les fichiers au lieu de les copier
--bwlimit=KBPS limite la bande passante E/S, En ko par seconde
--write-batch=FICHIER enregistre les modifications dans FICHIER
--only-write-batch=FICHIER comme --write-batch sans mettre à jour la destination
--read-batch=FICHIER exécute le fichier de modification FICHIER
--protocol=NUM force l'utilisation d'un protocole rsync version NUM
--checksum-seed=NUM spécifie la graine pour la somme de contrôle
-4, --ipv4 préfère IPv4
-6, --ipv6 préfère IPv6
--version affiche le numéro de version
-h, --help affiche cet écran d'aide
Rsync peut également être exécuté comme démon, auquel cas il accepte les options suivantes :
--daemon exécute rsync en tant que démon
--no-detach ne se détache pas du parent
--address=ADRESSE se lie à l'adresse spécifiée
--config=FICHIER spécifie un autre fichier rsyncd.conf
--bwlimit=KBPS limite la bande passante I/O, ko par seconde
--port=PORT spécifie un autre numéro de port rsyncd
-v, --verbose plus loquace
-4, --ipv4 préfère IPv4
-6, --ipv6 préfère IPv6
-h, --help affiche cet écran d'aide
| OPTIONS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
rsync utilise le paquetage «longopt» de GNU. De nombreuses options de la ligne de commande ont deux variantes, une courte et une longue. Celles ci sont exposées ci dessous, séparées par une virgule. Certaines options n'existent que dans la variante longue. Le «=» pour les options qui prennent un paramètre est optionnel ; des blancs peuvent être utilisés à la place.
Affiche une page d'aide décrivant succinctement les options disponibles dans rsync.
Affiche le numéro de version de rsync et quitte.
Cette option augmente la quantité d'information que vous obtenez lors du transfert. Par défaut, rsync travaille silencieusement. Avec un -v, rsync vous indique quels sont les fichiers actuellement transmis et affiche un bref résumé à la fin. Avec deux drapeaux -v, rsync vous informe des fichiers ignorés et affiche un résumé avec légèrement plus d'information à la fin. Plus de deux drapeaux -v ne devraient être utilisés que pour déboguer rsync.
Remarquez que les noms des fichiers transmis qui sont affichés le sont selon la valeur par défaut de --log-format qui est «%n%L», ce qui ne présente que le nom du fichier et, si c'est un lien, vers où il pointe. Avec un seul -v, il ne sera pas fait mention si un fichier a eu ses attributs modifiés. Si vous demandez une liste des attributs modifiés (soit avec --itemize-changes ou bien en ajoutant «%i» à --log-format), alors l'affichage fera mention de tous les attributs modifiés pour une quelconque raison. Référez-vous à l'option --log-format pour plus d'information.
Cette option diminue la quantité d'information affichée lors du transfert, les messages du serveur distant notamment sont supprimés. Cette option est utile lorsque vous appelez rsync à partir de cron.
Normalement rsync ignore tous les fichiers qui ont la même taille et ont une horodate identique. Cette option arrête ce comportement.
Normalement rsync ignore tous les fichiers qui ont la même taille et une horodate identique. Avec l'option --size-only, les fichiers seront ignorés s'ils ont la même taille, indépendamment de l'horodate. Ceci est utile lorsque l'on commence à se servir de rsync après avoir utilisé un autre outil de miroitage qui peut ne pas préserver les horodates exactement.
Lors de la comparaison de deux horodates, rsync les considère égales si elles ne diffèrent pas plus que la fenêtre temporelle. Celle-ci est normalement nulle (c'est-à-dire une comparaison exacte), mais cela peut être utile de la fixer à une valeur plus grande dans certaines situations. En particulier, lors de transferts impliquant un système de fichiers FAT (qui représente les dates avec une résolution de deux secondes), --modify-window=1 est alors utile (permettant aux horodates d'avoir jusqu'à une seconde de différence).
Ceci force l'expéditeur à faire une somme de contrôle 128-bit MD4 de tous les fichiers avant le transfert. La somme de contrôle est ensuite explicitement vérifiée à la réception et tous les fichiers du même nom qui existent déjà et ont la même somme de contrôle et la même taille sur le système de réception sont ignorés. Cette option peut être assez lente.
Ceci est équivalent à -rlptgoD. C'est un moyen rapide de dire que vous voulez la récursion et tout préserver pratiquement tout. La seule exception est que si --files-from a été spécifié alors -r n'est pas utilisée.
Notez toutefois que -a ne préserve pas les liens matériels, parce que trouver les fichiers multiplement liés est coûteux en ressources. Vous devez spécifier séparément -H.
Ceci dit à rsync de copier les répertoires récursivement. Référez-vous également à --dirs (-d).
Utilise des chemins relatifs. Ceci signifie que les chemins complets spécifiés sur la ligne de commande sont envoyés au serveur plutôt que juste la dernière partie des noms de fichiers. Ceci est particulièrement utile lorsque vous voulez envoyer plusieurs répertoires différents en même temps. Par exemple, si vous avez utilisé la commande
rsync /foo/bar/foo.c remote:/tmp/
alors ceci aurait créé un fichier appelé foo.c dans /tmp/ sur la machine distante. Si vous aviez utilisé plutôt
rsync -R /foo/bar/foo.c remote:/tmp/
alors un fichier appelé /tmp/foo/bar/foo.c aurait été créé sur la machine distante. Le nom de chemin complet est préservé. Pour limiter la taille du chemin transmis, vous pouvez faire
cd /foo
rsync -R bar/foo.c remote:/tmp/
Cela va créer /tmp/bar/foo.c sur la machine distante.
Désactive l'option --relative. Cela n'est nécessaire que si vous souhaitez utiliser --files-from sans --relative qui est automatiquement activée.
Lorsque cette option est combinée à --relative, les répertoires implicites des chemins ne sont pas dupliqués lors du transfert. Outre le fait que le transfert est plus optimal, cela permet aussi d'avoir des liens symboliques d'un côté sans que ce ne soit le cas de l'autre coté. Par exemple, si vous transférez le fichier "/path/foo/file" avec -R, par défaut rsync s'assurera que "/path" et "/path/foo" chez le destinataire correspondent exactement aux répertoires ou au liens sur la source. En utilisant --no-implied-dirs ces deux répertoires implicites seront omis, c'est-à-dire que si "/path" est un répertoire réel sur une machine et un lien symbolique sur l'autre, rsync ne le modifiera pas.
Avec cette option les fichiers de destination préexistants sont renommés lors du transfert de chaque fichier. Vous pouvez contrôler le répertoire de sauvegarde et le suffixe de sauvegarde en utilisant respectivement les options --backup-dir et --suffix. Remarquez que si vous ne spécifiez pas l'option --backup-dir alors l'option --omit-dir-times sera activée.
En combinaison avec l'option --backup, ceci dit à rsync de garder toutes les sauvegardes dans le répertoire spécifié. Ceci est très utile pour des sauvegardes incrémentales. Vous pouvez spécifier en plus un suffixe de sauvegarde en utilisant l'option --suffix (autrement, les fichiers sont sauvegardés dans le répertoire spécifié avec leur noms d'origine).
Cette option permet de modifier le suffixe de sauvegarde utilisé par l'option -b. Par défaut c'est un «~» à moins que --backup-dir n'ait été spécifiée, dans quel cas le suffixe par défaut est vide.
Ceci force rsync à ignorer tous les fichiers pour lesquels le fichier de destination existe déjà et avec une date postérieure à celle du fichier de source. (Si un fichier destination existant a une date égale à celle du fichier source, il ne sera mis à jour que si les tailles diffèrent.)
Dans l'implémentation courante de --update, une différence de format du fichier entre le récepteur et l'émetteur est toujours considérée comme suffisamment importante pour le mettre à jour, quelque soient les dates des fichiers. Autrement dit, si la source est un répertoire ou un lien symbolique tandis que la destination possède un fichier, alors un transfert sera lancé, peu importe les dates. Ce comportement est susceptible d'être modifié dans le futur (si vous avez un point de vue, vous pouvez en faire part, en anglais, à la liste de diffusion).
Cela change le comportement par défaut de rsync qui crée une nouvelle copie du fichier puis le déplace vers son véritable nom. Avec cette option rsync écrira directement par dessus le fichier, ce qui implique que l'algorithme de rsync ne pourra pas réduire la transmission réseau autant qu'il n'en est capable (étant donné qu'il ne tente pas encore de trier la correspondance de données). Une exception à cela est lorsque cette option est combinée à --backup, dans quel cas rsync sera suffisamment rusé pour utiliser le fichier de sauvegarde comme base pour le transfert.
Cette option est utile pour le transfert de fichier volumineux avec des changements regroupés ou des données ajoutées, ou alors sur les systèmes qui ont des performances limitées par les accès disques plutôt que réseaux.
Cette option implique --partial (puisque qu'un transfert interrompu n'efface pas le fichier), mais elle est incompatible avec --partial-dir et --delay-updates. Avant la version 2.6.4 de rsync --inplace était également incompatible avec --compare-dest et --link-dest.
AVERTISSEMENT : Les données du fichier seront dans un état inconsistant le temps du transfert (et éventuellement après si le transfert a été interrompu), par conséquent cette option n'est pas recommandée pour la mise à jour de fichier en cours d'utilisation. Notez également que rsync sera incapable de mettre à jour un fichier sur place s'il n'a pas d'accès en écriture pour l'utilisateur destinataire.
Indique à l'émetteur d'inclure tous les répertoires rencontrés.
Contrairement à --recursive, le contenu des répertoires n'est pas copié à moins que le répertoire ait été explicitement spécifié sur la ligne de commande par «.» ou par un nom suivi de «/» (par exemple «foo/»). Sans cette option ou --recursive, rsync omettra tous les répertoires rencontrés (en affichant un message indiquant l'omission).
Lorsque des liens symboliques sont rencontrés, ils sont recréés à la destination.
Lorsque des liens symboliques sont rencontrés, le fichier vers lequel ils pointent est copié plutôt que le lien symbolique. Dans les anciennes versions de rsync, cette option avait pour effet de bord de forcer le coté récepteur à suivre les liens symboliques, tels que les liens symboliques vers des répertoires. Dans les versions récentes de rsync, il est nécessaire de spécifier --keep-dirlinks (-K) pour obtenir cette fonctionnalité supplémentaire. Il y a une exception lorsque le rsync du coté récepteur est trop vieux pour comprendre -K -- dans ce cas, l'option -L entraînera l'effet de bord comme dans les anciennes versions.
Ceci dit à rsync de copier le fichier référencé par les liens symboliques qui pointent en dehors de l'arborescence source. Les liens symboliques absolus sont également traités comme des fichiers ordinaires, ainsi que les liens symboliques dans l'arborescence source elle même lorsque --relative est utilisée.
Ceci indique à rsync d'ignorer tous les liens symboliques qui pointent vers l'extérieur de l'arborescence copiée. Tous les liens symboliques absolus sont ignorés également. Utiliser cette option en même temps que --relative peut donner des résultats inattendus.
Ceci indique à rsync de recréer les liens matériels sur le système distant à l'identique du système local. Sans cette option, les liens matériels sont traités comme des fichiers réguliers.
Notez que rsync ne peut détecter les liens matériels que si les deux parties du lien sont dans la liste de fichiers envoyés.
Cette option peut être assez lente, ne l'utilisez que si vous en avez vraiment besoin.
Coté réception, si un lien symbolique pointe vers un répertoire, il sera traité comme correspondant à un répertoire chez l'émetteur.
Avec cette option, l'algorithme rsync incrémental n'est pas utilisé ; au lieu de cela, le fichier entier est envoyé tel quel. Le transfert peut être plus rapide grâce à cette option lorsque la bande passante entre les machines source et cible est plus grande que la bande passante vers le disque (en particulier lorsque le «disque» est en fait un système de fichiers sur réseau NFS). Cette option est utilisée par défaut lorsque la source et la cible sont sur la même machine.
Désactive --whole-file, utile lorsqu'elle est activée par défaut.
Cette option entraîne la mise à jour des permissions distantes pour qu'elles soient identiques aux permissions locales.
Sans cette option, tous les fichiers existants (y compris les fichiers mis à jour) gardent leur permissions actuelles, tandis que les nouveaux fichiers reçoivent des permissions basées sur les permissions du fichier source mais masquées par le masque utilisateur du récepteur (ce comportement est identique aux autres utilitaires de copie de fichier, tel que cp).
Cette option dit à rsync de mettre le propriétaire du fichier de destination identique à celui du fichier source. Sur la plupart des systèmes, uniquement le super-utilisateur peut fixer le propriétaire des fichiers. Par défaut, la conservation est effectuée selon le nom mais lorsque cela ne fonctionne pas, rsync utilise comme alternative le numéro ID. Référez-vous à l'option --numeric-ids pour plus de détail.
Cette option dit à rsync de mettre le groupe du fichier de destination identique à celui du fichier source. Si le programme récepteur n'est pas exécuté en tant que super-utilisateur, uniquement les groupes dont le récepteur est un membre seront préservés. Par défaut, la conservation est effectuée selon le nom mais lorsque cela ne fonctionne pas, rsync utilise comme alternative le numéro ID. Référez-vous à l'option --numeric-ids pour plus de détail.
Cette option entraîne le transfert d'informations sur les périphériques caractères et blocs vers le système distant pour recréer ces périphériques. Cette option n'est disponible que pour le super-utilisateur.
Ceci dit à rsync de transférer les dates de modifications avec les fichiers et de les mettre à jour sur le système distant. Notez que si cette option n'est pas utilisée, l'optimisation qui consiste à exclure les fichiers qui n'ont pas été modifiés ne peut pas être efficace ; en d'autres termes, un -t ou -a absent va faire que le prochain transfert se ferra comme s'il utilisait -I, ce qui implique que tous les fichiers seront mis à jour (même si l'algorithme rsync rendra l'opération relativement efficace si les fichiers n'ont pas été modifiés, vous avez tout intérêt à utiliser -t).
Ceci indique à rsync d'omettre les répertoires lorsque les dates de modification sont préservées (cf. --times). Si les répertoires du destinataire sont partagés via NFS, il est recommandé d'utiliser -O. Cette option est automatiquement sélectionnée si vous utilisez --backup sans --backup-dir.
Ceci dit à rsync de ne faire aucun transfert, mais de juste rapporter les actions qu'il aurait faites.
Essaie de traiter les fichiers à trous efficacement, de sorte qu'ils prennent moins de place sur la destination. [NDT : sparse file = fichier à trous]
NOTE : N'utilisez pas cette option lorsque la destination est un système de fichiers «tmpfs» Solaris. Il semble qu'il ne traite pas les déplacements au-dessus de zones vides et cela entraîne des corruptions de fichiers.
Ceci dit à rsync de ne pas traverser les limites du système de fichiers lors d'un parcours récursif. Ceci est utile pour transférer le contenu d'un système de fichiers exclusivement.
Ceci dit à rsync de ne créer aucun nouveau fichier -- uniquement mettre à jour les fichiers qui existent déjà sur la destination.
Ceci dit à rsync de ne pas mettre à jour les fichiers déjà existants chez le destinataire.
Ceci dit à rsync d'effacer de l'émetteur les fichiers ou les liens symboliques transmis créés ou mis à jour chez le destinataire. Les répertoires ainsi que les périphériques ne sont jamais effacés, ni les fichiers et les liens symboliques dont les attributs sont changés.
Ceci dit à rsync d'effacer tous les fichiers superflus côté réception (ceux qui ne sont pas du côté envoi); uniquement pour les répertoires synchronisés. Vous devez explicitement demander à rsync de transmettre le contenu du répertoire (par ex : «dir» ou «dir/»), sans utiliser de méta-caractères pour indiquer le contenu du répertoire (par ex : «dir/*»). En effet, les méta-caractères sont interprétés par le shell, ce qui implique que rsync reçoit une requête pour transmettre une liste de fichiers et non pas un répertoire entier. Les fichiers qui sont exclus du transfert ne seront pas effacés sauf si vous utilisez --delete-excluded ou que vous indiquez dans les règles de ne faire de correspondance que sur le côté émetteur (cf. les modificateurs d'inclusion/exclusion de la section RÈGLES DE FILTRE).
Cette option n'a pas d'effet si le parcours récursif des répertoires n'est pas sélectionné.
Cette option peut être dangereuse si elle n'est pas utilisée correctement ! C'est une très bonne idée d'exécuter rsync avec l'option --dry-run (-n) pour voir quels seraient les fichiers effacés et s'assurer qu'aucun fichier important n'est listé.
Si le côté envoi détecte des erreurs d'entrée/sortie (E/S), alors l'effacement des fichiers côté destination est automatiquement désactivé. Ceci prévient des échecs temporaires de système de fichiers (comme les erreurs NFS) du côté envoi causant une destruction massive de fichiers côté destination. Vous pouvez passer outre ceci avec l'option --ignore-errors.
L'option --delete peut être combinée avec l'une des options --delete-QUAND ainsi qu'avec --delete-excluded. Si aucune des options --delete-QUAND n'est spécifiée, actuellement, rsync choisira l'algorithme --delete-before. Cependant, il se peut que les versions futures choisissent par défaut l'algorithme --delete-during. Voir aussi --delete-after.
Avec cette option la suppression des fichiers du côté récepteur est effectuée lorsque le transfert commence. Ceci est l'option par défaut avec --delete ou --delete-excluded si aucune des options --delete-QUAND n'est spécifiée.
La suppression avant le transfert est utile si l'espace libre sur le système de fichiers est faible et que les fichiers superflus auraient empêché le transfert de se terminer correctement. Cependant, cela introduit un délai avant le démarrage du transfert, ce qui peut causer une erreur de temporisation sur le transfert (si --timeout a été spécifiée).
Avec cette option, la suppression des fichiers du côté récepteur est effectuée incrémentalement au cours du transfert. Ceci est une méthode plus rapide que celles avant ou après le transfert, mais elle n'est supportée que depuis la version 2.6.4 de rsync. Référez-vous à --delete (qui est sélectionnée implicitement) pour plus d'information.
Avec cette option, la suppression des fichiers du côté récepteur est effectuée une fois le transfert terminé. Ceci est utile si au cours du transfert vous envoyez de nouveaux fichiers de règle à fusionner par répertoire et que vous souhaitez que les exclusions qu'ils contiennent prennent effet avant la phase de suppression. Référez-vous à --delete (qui est sélectionnée implicitement) pour plus d'information.
En plus d'effacer les fichiers côté récepteur qui ne sont pas côté émetteur, ceci dit à rsync d'effacer également tous les fichiers côté réception qui sont exclus (voir --exclude). Référez-vous à la section RÈGLES DE FILTRE pour un moyen d'obtenir ce comportement individuellement à chaque exclusion du côté récepteur, et pour un moyen de protéger les fichiers de --delete-excluded. Référez-vous à --delete (qui est sélectionnée implicitement) pour plus d'information.
Dit à --delete de continuer et d'effacer les fichiers même lorsqu'il y a des erreurs E/S.
Cette option dit à rsync d'effacer les répertoires même s'ils ne sont pas vides lorsqu'ils sont remplacés par autre chose qu'un répertoire. Ceci ne s'applique pas à l'option --delete car les suppressions sont faites en profondeur d'abord. Requiert l'option --recursive (implicitement sélectionnée par -a) pour avoir un effet.
Ceci dit à rsync de ne pas effacer plus de NUM fichiers ou répertoires (NUM doit être supérieur ou égal à un). Ceci est utile lorsque l'on miroite de très grandes arborescences pour prévenir des désastres.
Ceci dit à rsync de ne pas transférer de fichier dont la taille est supérieure à TAILLE. La valeur TAILLE peut être suivie d'une lettre pour indiquer une unité (K, M ou G) et peut être une valeur fractionnelle (par ex : "--max-size=1.5m").
Ceci contrôle la taille de bloc utilisée dans l'algorithme rsync. Elle est normalement calculée à partir de la taille de chaque fichier à mettre à jour. Reportez-vous à la documentation technique pour plus de détails.
Cette option vous permet de choisir un shell distant alternatif pour la communication entre les copies locales et distantes de rsync. Par défaut, rsync va utiliser ssh, mais vous pouvez apprécier l'utilisation de rsh dans un réseau local.
Si cette option est utilisée en conjonction de [util@]hote::module/chemin, alors le shell distant COMMANDE sera utilisé pour lancer un démon rsync sur la machine hôte, et toutes les données seront transmises via la connexion à ce shell distant plutôt que directement via une connexion socket avec le démon rsync de l'hôte distant. Reportez-vous à la section «UTILISER LES FONCTIONNALITÉS D'UN DÉMON RSYNC VIA UNE CONNEXION SHELL DISTANT» ci-dessus pour plus d'information.
Il est possible d'ajouter des arguments à COMMANDE, il suffit de faire en sorte que COMMANDE soit présentée comme un seul argument à rsync. Par exemple :
-e "ssh -p 2234"
(Notez que les utilisateurs de ssh peuvent aussi personnaliser en fonction du site les options de connexion à l'aide du fichier .ssh/config.)
Vous pouvez aussi choisir le shell distant en utilisant la variable d'environnement RSYNC_RSH, qui accepte les mêmes valeurs que -e.
Voir aussi l'option --blocking-io qui est affectée par cette option.
Utilisez ceci pour spécifier le programme à lancer sur la machine distante pour démarrer rsync. Utile si ce chemin n'est pas dans le $PATH de votre shell distant (par ex : --rsync-path=/usr/local/bin/rsync). Notez que PROGRAMME est exécuté à l'aide du shell, par conséquent ce peut être n'importe quel programme, script ou suite de commande que vous souhaitez tant que l'entrée et la sortie standard que rsync utilise pour communiquer ne sont pas corrompus.
Un exemple quelque peu pernicieux est de modifier le répertoire par défaut de la machine distante pour l'utiliser avec l'option --relative. Par exemple :
rsync -avR --rsync-path="cd /a/b && rsync" hote:c/d /e/
Ceci est un raccourci utile pour exclure une grande quantité de fichiers que vous n'avez souvent pas envie de transférer entre deux systèmes. Il utilise l'algorithme que CVS utilise pour déterminer si un fichier doit être ignoré.
La liste d'exclusion est initialisée à :
RCS SCCS CVS CVS.adm RCSLOG cvslog.* tags TAGS .make.state .nse_depinfo *~ #* .#* ,* _$* *$ *.old *.bak *.BAK *.orig *.rej .del-* *.a *.olb *.o *.obj *.so *.exe *.Z *.elc *.ln core .svn/
ensuite les fichiers listés dans $HOME/.cvsignore sont ajoutés à la liste ainsi que tous les fichiers listés (séparés par des blancs) dans la variable d'environnement CVSIGNORE.
Finalement, tous les fichiers qui sont dans le même répertoire qu'un .cvsignore et qui correspondent à l'un des motifs listé dans celui-ci sont ignorés. Contrairement aux filtres et aux fichiers d'exclusion de rsync, les motifs sont séparés par des blancs. Consultez le manuel cvs(1) pour plus d'information.
Si vous combinez -C à vos propres règles --filter, vous devriez garder à l'esprit que ces exclusions CVS sont ajoutées à la fin de vos propres règles, quelle que soit la position de -C dans la liste d'arguments.
Cela leur donne une plus faible priorité que les règles que vous spécifiez explicitement. Pour contrôler quand exactement ces exclusions CVS sont insérées dans vos règles de filtre, vous devez omettre -C de la ligne d'arguments et utiliser à la place la combinaison de --filter=:C et --filter=-C (soit sur la ligne de commande, soit en plaçant ":C" et "-C" dans l'un de vos fichiers de règles). La première des options active l'utilisation du fichier .cvsignore. La seconde importe en une fois toutes les exclusions CVS mentionnées précédemment.
Cette option vous permet d'ajouter des règles pour exclure de manière fine certains fichiers depuis une liste de fichier à transmettre. Cette option est particulièrement utile en combinaison à un transfert récursif.
Il est possible des spécifier plusieurs fois l'option --filter sur la ligne de commande, vous permettant ainsi de construire à vos souhaits une liste de fichiers à exclure.
Voir la section RÈGLES DE FILTRE pour plus d'information sur cette option.
L'option t-F est un raccourci pour ajouter deux règles --filter à votre commande. La première occurrence est un raccourci pour cette règle :
--filter=': /.rsync-filter'
Ceci indique à rsync de rechercher récursivement les fichiers .rsync-filter éparpillés dans la hiérarchie et d'utiliser leurs règles pour filtrer les fichiers lors du transfert. Si -F est répété, c'est alors un raccourci pour la règle suivante :
--filter='- .rsync-filter'
Ceci filtre les fichiers .rsync-filter eux-mêmes lors du transfert.
Voir la section RÈGLES DE FILTRE pour plus d'information sur le fonctionnement de cette option.
Cette option est une forme simplifiée de l'option --filter avec une règle d'exclusion et qui n'accepte pas la syntaxe complète des règles de filtre.
Voir la section RÈGLES DE FILTRE pour plus d'information sur cette option.
Cette option est similaire à l'option --exclude, mais ajoute les motifs d'exclusion listés dans le fichier FICHIER à la liste d'exclusion. Les lignes vides dans FICHIER ou les lignes commençant par «;» ou par «#» sont ignorées.
Si FICHIER est - alors la liste sera lue depuis l'entrée standard.
Cette option est une forme simplifiée de l'option --filter avec une règle d'inclusion et qui n'accepte pas la syntaxe complète des règles de filtre.
Voir la section RÈGLES DE FILTRE pour plus d'information sur cette option.
Ceci spécifie une liste de motifs d'inclusion à lire depuis un fichier. Si FICHIER est - alors la liste sera lue depuis l'entrée standard.
Cette option vous permet de spécifier la liste exacte des fichiers à transférer (obtenue depuis le FICHIER spécifié ou depuis l'entrée standard si le nom est «-»). Elle modifie également le comportement par défaut de rsync pour rendre le transfert de seulement les fichiers et le répertoires spécifiés plus simple :
L'option --relative (-R) est activée, ce qui préserve l'information de chemin spécifié pour chaque entrée du fichier (utilisez --no-relative si vous souhaitez la désactiver).
L'option --dirs (-d) est activée, ce qui créera les répertoires spécifiés dans la liste chez le récepteur au lieu d'afficher un avertissement et de les sauter.
Le comportement de l'option --archive (-a) ne contient pas --recursive (-r), vous devez donc la spécifier explicitement si vous la souhaitez.
Les noms de fichiers qui sont lus depuis FICHIER sont tous relatifs au répertoire source -- les «\|» en début de nom sont supprimés et les «..» ne sont pas autorisés à remonter plus haut que le répertoire source. Par exemple, la commande suivante :
rsync -a --files-from=/tmp/foo /usr hotedst:/backup
Si /tmp/foo contient la chaîne «bin» (ou même «/bin»), le répertoire /usr/bin sera créé en tant que /backup/bin sur la machine hotedst. S'il contient «bin/» (remarquez la barre oblique), le contenu immédiat du répertoire sera aussi transmis (sans qu'il y ait besoin de le mentionner explicitement dans le fichier, depuis la version 2.6.4). Dans les deux cas, si l'option -r est activée, alors toute la hiérarchie du répertoire sera transférée (n'oubliez pas que -r doit être explicitement spécifiée car, avec --files-from, elle n'est pas impliquée par -a). Gardez également en tête que l'effet de l'option --relative (activée par défaut) est de dupliquer uniquement l'information de chemin présente dans le fichier ; elle ne force pas la duplication du chemin source (/usr dans le cas présenté).
De plus, le fichier de --files-from peut être lu depuis l'hôte distant au lieu de l'hôte local, il faut pour cela spécifier «nom-de-l-hôte:» avant le nom du fichier (le nom de l'hôte doit correspondre à l'une des deux bouts de la transmission). Un préfixe «:» est un raccourci pour indiquer d'utiliser l'hôte distant. Par exemple :
rsync -a --files-from=:/chemin/file-list src:/ /tmp/copy
Ceci copiera tous les fichiers spécifiés dans le fichier /chemin/file-list situé sur l'hôte distant «src».
Ceci indique à rsync que les noms de règles/fichiers lus depuis un fichier sont séparés par un caractère nul («\0»), pas un NL, CR ni CR+LF. Ceci affecte --exclude-from, --include-from, --files-from, ainsi que tous les fichiers inclus depuis une règle --filter. Par contre, ceci n'affecte pas --cvs-exclude (puisque tous les noms lus depuis un .cvsignore sont séparés par un blanc).
Cette option dit à rsync d'utiliser RÉP comme répertoire de dépôt pour la création de copies temporaires des fichiers transférés sur le côté réception. Le comportement par défaut est de créer les fichiers temporaires dans le répertoire de réception.
Cette option indique à rsync de rechercher un fichier de base pour tout fichier destination manquant. L'algorithme actuel recherche dans le même répertoire que le fichier destination un fichier qui ait soit la même taille et la même horodate, ou un fichier au nom similaire. Si un tel fichier est trouvé alors rsync utilisera ce fichier de base flou pour tenter d'accélérer le transfert.
Notez que l'utilisation de --delete peut supprimer les fichiers flous potentiels, par conséquent il vaut mieux utiliser --delete-after ou bien spécifier des exclusions de fichier qui évitent ces suppressions.
Cette option ordonne à rsync d'utiliser REP sur la machine de destination comme un répertoire supplémentaire avec lequel il faut comparer les fichiers de destination (pour les fichiers qui ne sont pas présents dans le répertoire de destination). Si un fichier est trouvé dans RÉP et qu'il est identique au fichier émis, alors le fichier ne sera PAS transmis vers le répertoire de destination. Cela est utile pour créer une sauvegarde incrémentale, qui ne contient que les fichiers modifiés par rapport à la sauvegarde précédente.
Depuis la version 2.6.4, il est possible de spécifier plusieurs répertoires --compare-dest, rsync recherchera alors un fichier identique dans l'ordre de la liste spécifiée. Si un fichier identique est trouvé mais que ses attributs diffèrent, alors une copie locale est faite et les attributs sont mis à jour. Lorsqu'aucun fichier identique n'est trouvé, un des fichiers des différents RÉP est utilisé comme base pour accélérer le transfert.
Si REP est un chemin relatif, il est relatif au répertoire de destination. Voir aussi --copy-dest et --link-dest.
Cette option a le même comportement que --compare-dest, mais rsync copiera également les fichiers inchangés trouvés dans REP vers le répertoire de destination en utilisant la copie locale. Ceci est utile pour des transferts vers un nouveau répertoire en laissant l'ancien intact, procédant à un remplacement-éclair de l'ancien par le nouveau une fois le transfert terminé.
Il est possible de spécifier plusieurs répertoires --compare-dest, rsync recherchera alors un fichier identique dans l'ordre de la liste spécifiée. Si aucun fichier identique n'est trouvé, un des fichiers des différents RÉP est utilisé comme base pour accélérer le transfert.
Si RÉP est un chemin relatif, il est relatif au répertoire de destination. Voir aussi --compare-dest et --link-dest.
Cette option a le même comportement que --copy-dest, mais, à la place d'une copie, un lien matériel est effectué entre les fichiers inchangés.
Les fichiers doivent être identiques même au niveau des attributs (par ex. permissions, droits...) afin que les fichiers puissent être liés. Un exemple :
rsync -av --link-dest=$PWD/rép_précédent hôte:rép_src/ nouv_rép/
Depuis la version 2.6.4, il est possible de spécifier plusieurs répertoires --compare-dest, rsync recherchera alors un fichier identique dans l'ordre de la liste spécifiée. Si un fichier identique est trouvé mais que ses attributs diffèrent alors une copie locale est faite et les attributs sont mis à jour. Lorsqu'aucun fichier identique n'est trouvé, un des fichiers des différents RÉP est utilisé comme base pour accélérer le transfert.
Si RÉP est un chemin relatif, il est relatif au répertoire de destination. Voir aussi --compare-dest et --copy-dest.
Notez qu'un bogue était présent dans les versions de rsync antérieures à 2.6.1, ce qui pouvait empêcher --link-dest de fonctionner correctement pour les utilisateurs non-root lorsque -o était spécifiée (ou implicitement activée par -a). Vous pouvez contourner le problème en évitant d'utiliser -o lors d'envois vers un vieux rsync.
Avec cette option, rsync compresse toutes les données des fichiers qu'il envoie à la machine de destination. Cette option est utile avec des connexions réseau lentes.
Notez que cette option permet d'obtenir des taux de compression meilleurs que ce qui peut être obtenu avec des shells distants qui compressent, ou un transport qui compresse, car cela prend en compte l'information implicite envoyée pour les blocs de données qui correspondent entre eux.
Avec cette option, rsync va transférer le numéro identificateur de groupe et d'utilisateur plutôt que d'utiliser les noms de groupe et d'utilisateur en les faisant correspondre des deux cotés.
Par défaut rsync va utiliser le nom d'utilisateur et de groupe pour déterminer quel propriété donner aux fichiers. Le numéro d'utilisateur spécial 0 et le numéro de groupe spécial 0 ne sont jamais en correspondance avec les noms d'utilisateurs/groupes même si l'option --numeric-ids n'est pas spécifiée.
Si un utilisateur ou un groupe n'a pas de nom sur l'émetteur ou n'est pas présent sur le récepteur, alors le numéro identificateur est utilisé à la place. Voir aussi les remarques sur les paramètres d'«utilisation de chroot» dans la page man de rsyncd.conf pour plus d'information à propos de l'influence des paramètres de chroot sur la capacité de rsync à rechercher les noms d'utilisateur et de groupe, et sur les possibilités d'éviter les problèmes.
Cette option vous permet de fixer le temps d'attente avant échec d'entrée/sortie en secondes. Si aucune donnée n'est transférée pendant la durée spécifiée alors rsync se termine. Vaut 0 par défaut, ce qui signifie une attente infinie.
Par défaut rsync va s'attacher à l'adresse joker lors d'une connexion vers un démon rsync. L'option --address vous permet de spécifier une adresse IP (ou un nom d'hôte) particulière vers laquelle se connecter. Voir aussi cette option dans la section du mode --daemon.
Ceci spécifie un numéro de port TCP alternatif à utiliser au lieu du port par défaut 873. Cela n'est vraiment utile que lorsque vous utilisez une syntaxe avec un double deux-points «::» pour vous connecter à un démon rsync (puisque la syntaxe à l'aide d'une URL peut spécifier le port directement dans l'URL). Voir aussi cette option dans la section du mode --daemon.
Ceci dit à rsync d'utiliser des entrées/sorties (E/S) bloquantes lorsqu'il démarre un transport via shell distant. Si le shell est rsh ou remsh, cette option est utilisée par défaut, sinon des E/S non-bloquantes sont utilisées. (Notez que ssh préfère les E/S non-bloquantes.)
Désactive --blocking-io, à utiliser lorsqu'elle est activée par défaut.
Demande une liste simple des changements effectués sur chacun des fichiers, y comprit les modifications d'attribut. C'est équivalent à l'option --log-format='%i %n%L'.
Le «%i» génère une sortie obscure de 9 caractères. Le format général de cette chaîne est UXcstpoga, où U est remplacé par le type de mise à jour effectuée, X remplacé par le type de fichier, et les autres lettres représentant des attributs qui seront affichés s'ils ont été modifiés.
Les différents types de mises à jour qui remplacent U sont :
Un < signifie que le fichier est transféré vers la machine distante (envoi).
Un > signifie que le fichier est transféré vers la machine locale (réception).
Un c signifie que l'entité a été créée ou modifiée (tel que la création d'un répertoire ou la modification d'un lien symbolique, etc.).
Un h signifie que l'entité est un lien matériel vers un fichier (requiert --hard-links).
Un . signifie que l'entité n'a pas été mise à jour (bien que certains de ces attributs aient pu être modifiés).
Les types de fichiers qui remplacent le X sont : f pour un fichier, d pour un répertoire, L pour un lien symbolique, et D pour un périphérique.
Les autres lettres de la chaîne de caractères sont les lettres qui seront affichées si l'attribut qui leur est associé est mis à jour, s'il n'y a pas de changement ce sera un «.». Il y a trois exceptions à cela : (1) une entité qui vient d'être créée a toutes les lettres remplacées par «+», (2) une entité identique remplace les points par des espaces, et (3) un attribut inconnu remplace la lettre par un «?» (cela peut arriver lors de la connexion à un vieux rsync).
Les attributs associés à chaque lettre sont :
Un c indique que la somme de contrôle du fichier est différente et qu'il sera mis à jour lors du transfert (requiert --checksum).
Un s indique que la taille du fichier est différente et qu'il sera mis à jour lors du transfert.
Un t indique que la date de modification est différente et qu'elle sera changée à la valeur de celle de l'émetteur (requiert --times). Un T indique que la date sera celle du transfert, ce qui est toujours le cas lorsqu'un lien symbolique est transféré, et cela arrive aussi lorsqu'un fichier ou un périphérique est transféré sans --times.
Un p indique que les permissions sont différentes et qu'elles seront changées à la valeur de celles de l'émetteur (requiert --perms).
Un o indique que le propriétaire est différent et qu'il sera changé à la valeur de celle de l'émetteur (requiert --owner et les privilèges root).
Un g indique que le groupe est différent et qu'il sera changé à la valeur de celle de l'émetteur (requiert --group et les permissions de changer de groupe).
Le a est réservé pour une version future qui supporte les attributs étendus, tels que les ACLs.
Un autre affichage est possible : quand des fichiers sont supprimés, le «%i» affichera «*deleting» pour chaque entité supprimée (si la connexion est faite avec un rsync suffisamment récent qui journalise les suppressions plutôt que de les indiquer par un message texte).
Ceci vous permet de spécifier exactement ce que le client rsync affiche sur la sortie standard pour chaque fichier [NDT : to log = journaliser]. Le format de journalisation est une chaîne de caractère contenant des séquences d'échappement d'un caractère préfixées par un caractère pourcent «%». La liste des différents caractères d'échappement possibles est disponible dans la partie sur le format de journalisation de la page de manuel de rsyncd.conf. (Notez que cette option ne modifie pas l'aspect du journal du démon rsync.)
Spécifier cette option forcera rsync à mentionner chaque fichier, répertoire, etc. modifié de manière significative (fichier transféré, lien symbolique/périphérique recréé, ou répertoire modifié). Si une séquence d'échappement des modifications d'attribut (%i) est inclue dans la chaîne de caractères, alors la journalisation des noms mentionnera toute entité qui a été modifiée d'une quelconque façon (tant que le côté récepteur est un rsync version 2.6.4 ou supérieure). Voir l'option --itemize-changes pour une description de l'affichage de «%i».
L'option --verbose implique le format «%n%L», mais vous pouvez utiliser --log-format sans --verbose, ou redéfinir le format de l'affichage par fichier à l'aide de cette option.
Rsync affiche la chaîne de journalisation avant le transfert du fichier à moins qu'une des statistiques de transfert ne soit demandée. Dans ce cas, la journalisation est faite après la fin du transfert. Lorsque la journalisation se fait après et que --progress a été spécifié, rsync affichera aussi le nom du fichier transféré avant l'information d'avancement (qui, bien sûr, sera ensuite suivie de l'affichage de journalisation).
Demande à rsync d'afficher un jeu de statistiques verbeux sur le transfert de fichiers, ce qui vous permet de quantifier l'efficacité de l'algorithme rsync pour vos données.
Par défaut, rsync va effacer tous les fichiers transférés partiellement si le transfert est interrompu. Dans certaines circonstances il est préférable de conserver les fichiers partiellement transférés. L'option --partial demande à rsync de conserver le ficher incomplet ce qui devrait accélerer un transfert ultérieur de la fin du fichier.
Une meilleure manière que l'option --partial pour conserver les fichiers partiels est de spécifier un REP qui sera utilisé pour contenir les données partielles (au lieu de les écrire dans le fichier destination). Lors du transfert suivant, rsync utilisera le fichier de ce répertoire comme donnée pour accélérer la reprise du transfert et puis l'effacera une fois le transfert achevé. Notez que si --whole-file est spécifié (même implicitement), tout fichier présent dans le répertoire partiel correspondant à un fichier mis à jour sera purement et simplement supprimé (puisque dans ce cas rsync envoie les fichiers sans utiliser l'algorithme incrémental).
Rsync créera REP s'il est manquant (uniquement le répertoire feuille). Cela rend facile l'utilisation d'un chemin relatif (tel que «--partial-dir=.rsync-partial»), ce qui fait que rsync crée le répertoire partiel dans le répertoire du fichier de destination si nécessaire, et l'efface une fois que le fichier partiel est supprimé.
Si la valeur du répertoire partiel n'est pas un chemin absolu, rsync ajoutera aussi une option --exclude à la fin des exclusions existantes avec comme valeur ce répertoire. Ceci évite que les répertoires partiels ne soient transmis et évite les suppressions par inadvertance des répertoires partiels chez le destinataire. Par exemple, l'option --partial-dir précédemment mentionnée ajoutera une règle «--exclude=.rsync-partial/» à la fin des autres règles de filtre. Remarquez que si vous spécifiez vos propres règles de filtre, il se peut que vous deviez manuellement insérer cette règle d'exclusion quelque part plus tôt dans la liste afin qu'elle ait une priorité suffisante pour être efficace (par ex : si vous avez à la fin une règle --exclude='*', la règle automatique ne sera jamais considérée).
IMPORTANT : Le répertoire partiel ne doit jamais être autorisé en écriture aux autres utilisateurs, cela introduirait un risque de sécurité. Par exemple, ÉVITEZ «/tmp».
Vous pouvez également spécifier la valeur partial-dir dans la variable d'environnement RSYNC_PARTIAL_DIR. Le fait que cette variable soit définie ne force pas l'activation de --partial, mais ceci indique où seront placées les fichiers partiels si --partial est activée. Par exemple, au lieu d'utiliser --partial-dir=.rsync-tmp avec l'option --progress, vous pouvez définir RSYNC_PARTIAL_DIR=.rsync-tmp dans votre environnement et puis juste utiliser l'option -P pour activer l'utilisation du répertoire .rsync-tmp pour les transferts partiels. Les seuls cas où --partial n'utilise pas cette variable d'environnement sont (1) quand --inplace est spécifiée (car --inplace rentre en conflit avec --partial-dir), et (2) quand --delay-updates est spécifiée (voir ci-dessous).
Dans le contexte de configuration du démon, pour la spécification du «refus d'option», --partial-dir n'implique pas --partial. De cette manière, refuser l'option --partial peut être utile lors de transferts partiels pour empêcher d'écrire par dessus des fichiers de destination, tout en autorisant quand même la version plus sûre --partial-dir.
Cette option indique à rsync de placer les versions temporaires des fichiers mis à jour dans un répertoire séparé jusqu'à la fin du transfert, ces fichiers seront ensuite renommés avec leur véritable nom. L'objectif est de rendre la mise à jour un petit plus atomique. Par défaut, les fichiers sont placés dans le sous-répertoire «.~tmp~» de chaque répertoire de destination, mais vous pouvez le redéfinir avec l'option --partial-dir. (Notez que RSYNC_PARTIAL_DIR n'a aucun effet sur cette valeur, de même, lorsque --partial-dir est implicitement utilisée pour la spécification du «refus d'option», elle n'a pas d'effet sur ce répertoire.) Cette option rentre en conflit avec --inplace.
Cette option utilise plus de mémoire du côté récepteur (un bit par fichier transféré) et aussi requiert un espace disque suffisant chez le récepteur pour pouvoir contenir les copies supplémentaires de tous les fichiers mis à jour. Il faut aussi éviter d'utiliser un chemin absolu pour --partial-dir à moins d'être sûr de ne jamais avoir deux fichiers ayant le même nom (car, si le chemin est absolu, tous le fichiers mis à jour seront placé dans le même répertoire).
Voir aussi le script perl «atomic-rsync» dans le sous-répertoire «support» pour un algorithme de mis à jour encore plus atomique (il utilise --link-dest avec une hiérarchie de fichier parallèle).
Cette option demande à rsync d'afficher des informations montrant la progression des transferts. Ceci donne à un utilisateur qui s'ennuie quelque chose à regarder. Implique l'option --verbose lorsqu'elle n'a pas déjà été spécifiée.
Au cours du transfert d'un fichier, les données ressemblent à :
782448 63% 110.64kB/s 0:00:04
Ceci indique la taille courante du fichier, le pourcentage du transfert effectué, la vitesse de transmission actuelle (prenant en compte à la fois les données transmises et les données réutilisées localement), et une estimation du temps restant avant la fin du transfert.
Une fois qu'un fichier est entièrement transmit, les données ressemblent à :
1238099 100% 146.38kB/s 0:00:08 (5, 57.1% of 396)
Ceci indique la taille finale du fichier, qu'il a été complété (100%), la vitesse moyenne de transmission du fichier, la durée prise par le transfert du fichier, et entre parenthèses, un résumé du transfert global. Ces trois nombres vous indiquent combien de fichiers ont été mis à jour jusqu'à présent, et quel pourcentage du nombre total de fichiers a été parcouru.
L'option -P est équivalente à --partial --progress. Elle a pour but de rendre plus simple l'activation de ces deux options, couramment appelées pour de longs transferts qui peuvent subir des coupures.
Cette option vous permet de fournir un mot de passe dans un fichier pour accéder à un démon rsync distant. Notez que cette option est utile uniquement pour accéder à un démon rsync en utilisant le transport interne, pas lors de l'utilisation d'un shell distant comme transport. Le fichier ne doit pas être lisible par tout le monde. Il doit contenir juste le mot de passe sur une ligne seule.
Cette option liste les fichiers sources au lieu de les transférer. Cette option est implicite s'il n'y a pas de destination de spécifiée, par conséquent il n'est généralement pas nécessaire de l'utiliser explicitement. Cependant, elle peut être utile pour les utilisateurs qui souhaitent éviter les options «-r --exclude='/*/*'» que rsync utilise normalement lors de listages non-récursifs pour assurer la compatibilité, ou pour lister les fichiers qui sont impliqués lors d'une copie locale (puisque le répertoire destination n'est pas optionnel pour la copie locale, vous devez spécifier cette option explicitement et aussi indiquer la destination).
Cette option vous permet de spécifier un taux de transfert maximum en kilo-octets par secondes. Cette option est plus efficace lorsqu'utilisée avec de gros fichiers (plusieurs mega-octets et plus). Étant donnée la nature des transferts rsync, des blocs de données sont envoyés, puis si rsync détermine que le transfert a été trop rapide, il va attendre avant d'envoyer le bloc de données suivant. Le résultat est un taux de transfert moyen égal à la limite spécifiée. Une valeur de zéro signifie qu'il n'y a pas de limitation.
Génère un fichier qui pourra être appliqué à une autre destination identique à l'aide de --read-batch. Voir aussi la section MODE TRAITEMENT PAR LOTS pour plus de détails, ainsi que l'option --only-write-batch.
Fonctionne de la même manière que --write-batch, à l'exception qu'aucune mise à jour ne sera effectuée chez le récepteur lors de la création du fichier de traitement par lot. Cela vous permet d'envoyer les modifications sur le récepteur par d'autres moyens, et appliquer les changements via --read-batch.
Remarquez que vous êtes libre d'enregistrer ce fichier de traitement directement sur un média portable : si ce média est remplit avant le fin du transfert, vous pouvez juste appliquer ce transfert partiel sur la destination et répéter le processus jusqu'à ce que la totalité des changements a été appliquée (tant que ce n'est pas gênant qu'il y ait un fichier partiellement mis à jour pendant toute la durée du cycle).
Notez également que cela n'économise la bande passante que lorsque les changements sont envoyés vers un système distant car les données de mis à jour sont directement déviées vers le fichier de traitement par lot au lieu d'être transmises sur le réseau au récepteur (lors d'une réception, l'émetteur est distant et donc il ne peut pas écrire le fichier de traitement par lot).
Applique tout les changements enregistrés dans FICHIER, un fichier précédemment généré à l'aide de --write-batch. Si FICHIER est «-» alors le lot à traiter sera lu depuis l'entrée standard. Voir la section MODE TRAITEMENT PAR LOTS pour plus de détails.
Force l'utilisation d'un protocole de version antérieure. Cela est utile pour créer un fichier de traitement par lot qui soit compatible avec une version antérieure de rsync. Par exemple, si rsync 2.6.4 est utilisé avec l'option --write-batch mais que ce sera rsync 2.6.3 qui sera utilisé pour exécuter l'option --read-batch, alors vous devrez utiliser «--protocol=28» lors de la création du fichier de traitement par lot pour forcer l'utilisation d'un protocole antérieur dans le fichier de traitement par lot (si vous ne pouvez pas mettre à jour rsync sur la seconde machine).
Indique à rsync de préférer IPv4/IPv6 lors de la création de sockets. Ceci n'a d'influence uniquement sur les sockets directement contrôlée par rsync, telles que la socket sortante lors d'une connexion directe vers un démon rsync. Voir aussi ces options dans la section du mode --daemon.
Initialise la graine de la somme de contrôle MD4 à NUM. Cette graine de 4 octets est utilisée dans le calcul de la somme de contrôle MD4 pour chaque bloc et chaque fichier. Par défaut cette graine est générée par le démon et initialisée au time() courant. Cette option permet de choisir une graine spécifique, ce qui peut être utile pour les applications qui nécessitent une somme de contrôle de bloc ou de fichier reproductible, ou alors lorsque l'utilisateur souhaite une graine de somme de contrôle plus aléatoire. Notez que définir NUM à 0 forcera rsync à utiliser la graine par défaut, time().
| OPTIONS DU DÉMON | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Les options permises lorsque rsync est lancé comme démon sont les suivantes :
Ceci dit à rsync de fonctionner en tant que démon. On y accède en utilisant la syntaxe host::module ou rsync://host/module.
Si l'entrée standard est une socket, rsync va supposer qu'il est lancé par inetd, sinon il va se détacher du terminal courant et va devenir un démon tournant en arrière plan. Le démon lit le fichier de configuration (rsyncd.conf) à chaque connexion faite par un client et répondre aux requêtes en conséquence. Consultez la page de manuel rsyncd.conf(5) pour plus de détails.
Par défaut, rsync écoutera sur l'adresse joker (wildcard address) lorsqu'il est exécuté en tant que démon (avec l'option --daemon). L'option --address vous permet de spécifier une adresse IP particulière (ou un nom d'hôte) à laquelle se connecter. Ceci permet de définir des hôtes virtuels (virtual hosting) en conjonction avec l'option --config. Voir aussi l'option globale «address» de la page de manuel rsyncd.conf.
Cette option vous permet de spécifier un taux de transfert maximum en kilo-octets par secondes pour les données transmises par le démon. Le client peu spécifier une plus petite valeur --bwlimit, par contre sa valeur sera tronquée si elle dépasse la valeur du démon. Pour de plus amples détails, voir ci-dessus la définition de cette option pour le client.
Spécifie un fichier de configuration alternatif. Ceci n'a de sens que si l'option --daemon est spécifiée. Par défaut le fichier est /etc/rsyncd.conf, à moins que le démon ne soit exécuté via un shell distant et que l'utilisateur distant ne soit pas root, auquel cas le fichier par défaut sera rsyncd.conf du répertoire courant (en général $HOME).
Lorsque rsync fonctionne en tant que démon, cette option lui demande de ne pas se détacher pour devenir un processus fonctionnant en arrière-plan. Cette option est nécessaire lorsque rsync est exécuté en tant que service avec Cygwin, et peut également être nécessaire lorsque rsync est supervisé par un programme comme daemontools ou le Contrôleur de Ressources Système de AIX. --no-detach est également recommandé lorsque rsync est exécuté dans un débogueur. Cette option n'a pas d'effet si rsync est exécuté depuis inetd ou sshd.
Spécifie un numéro de port TCP alternatif à utiliser au lieu du port par défaut 873. Voir aussi l'option globale «port» de la page de manuel rsyncd.conf.
Cette option augmente le niveau d'information journalisé par le démon lors de la phase de démarrage. Un fois le client connecté, le niveau d'information rapporté par le client sera fonction des options passées par le client et l'option «max verbosity» dans la section de configuration des modules.
Indique à rsync de préférer IPv4/IPv6 lors de la création de sockets d'entrée utilisées par le démon pour attendre les connexions. Il se peut qu'une de ces options soit nécessaire pour contourner un bogue d'IPv6 dans d'ancienne version du noyau Linux (si vous obtenez une erreur «address already in use» alors que personne d'autre n'utilise le port, essayez de spécifier --ipv6 ou --ipv4 au démarrage du démon).
Lorsqu'elle est spécifiée après --daemon, cette option affiche une page d'aide décrivant les options disponibles au démarrage du démon rsync.
| RÈGLES DE FILTRE | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Les règles de filtre permettent une sélection flexible des fichiers à transférer (inclus) et des fichiers à ignorer (exclus). Les règles peuvent définir directement des motifs d'inclusion/exclusion; elles peuvent aussi définir un moyen d'acquérir plus de motifs d'inclusion/exclusion (c-à-d de les lire depuis un fichier).
Au fur et à mesure que la liste des fichiers/répertoires à transférer est construite, rsync compare chaque nom avec la liste des motifs à inclure/exclure. À la première occurrence d'un motif qui correspond, si c'est un motif d'exclusion alors le fichier est ignoré ; si c'est un motif d'inclusion ou si aucun motif ne correspond alors le fichier est transmit.
Rsync construit la liste de règles de filtre dans le même ordre que spécifié sur la ligne de commande. Les règles de filtre ont la syntaxe suivante :
RÈGLE [MOTIF_OU_FICHIER]
RÈGLE,MODIFICATEURS [MOTIF_OU_FICHIER]
Vous avez le choix d'utiliser des noms de RÈGLE longs ou courts, comme décrit ci-dessous. Si vous utilisez une règle avec un nom court, la «,» séparant la RÈGLE du MODIFICATEURS est optionnelle. Le MOTIF ou FICHIER qui suit (lorsqu'il est présent) doit être séparé par un espace ou un tiret bas (_). Les préfixes de règle disponibles sont :
exclude, - spécifie un motif d'exclusion.
include, + spécifie un motif d'inclusion.
merge, . spécifie un fichier à fusionner qui contient d'autres règles.
dir-merge, : spécifie un fichier à fusionner par-répertoire.
hide, H spécifie un motif pour cacher les fichiers lors du transfert.
show, S les fichiers correspondants à ce motif ne sont pas cachés.
protect, P spécifie un motif pour protégé les fichiers de la suppression.
risk, R les fichiers correspondants à ce motif ne sont pas protégés.
clear, ! efface la liste d'inclusion/exclusion courante (ne prend pas d'argument).
Quand les règles sont lues depuis un fichier, les lignes vides sont ignorées, ainsi que les lignes de commentaire (celles commençant pas un «#»).
Remarquez que les options --include/--exclude en ligne de commande ne comprennent pas l'ensemble complet de règle décrit ci-dessus. Elles ne permettent uniquement la spécification de motifs d'inclusion/exclusion plus un «!» pour effacer la liste (ainsi que les commentaires lorsque les règles sont lues depuis un fichier). Si un motif ne commence ni par «- » (moins, espace), ni par «+ » (plus, espace), alors la règle sera interprétée comme si un «+ » (pour une option d'inclusion) ou un «- » (pour une option d'exclusion) était préfixée à la chaîne de caractères. Par contre, pour l'option --filter, il doit toujours y avoir un nom de règle court ou long en début de règle.
Remarquez aussi que les options --filter, --include, et --exclude ne prennent chacune qu'une seule règle. Pour en spécifier plus d'une, répétez l'option sur la ligne de commande, utilisez la syntaxe de fusion de fichier de l'option --filter, ou utilisez les options --include-from/ --exclude-from.
| MOTIFS D'INCLUSION ET D'EXCLUSION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Vous pouvez inclure et exclure des fichiers en spécifiant des motifs à l'aide des règles de filtre «+», «-», etc. (tel que présenté dans la section RÈGLES DE FILTRE ci-dessus). Chacune des règles peut définir un motif qui sera comparé à chacun des fichiers transférables. Les motifs peuvent prendre plusieurs formes :
si le motif commence par un /, il est vérifié pour correspondance à une place donnée dans la arborescence de fichiers, sinon il est vérifié avec la fin du nom de fichier. Cela est équivalent à un ^ comme premier caractère dans une expression régulière. Ainsi, «/foo» correspond avec un fichier nommé «foo» à la base de l'arborescence de transfert (lors d'une règle globale) ou dans le répertoire du fichier fusionné (lors d'une règle par répertoire). Un simple «foo» correspond avec tous les fichiers appelés «foo» n'importe où dans l'arborescence parce que l'algorithme est appliqué récursivement de haut en bas ; il se comporte comme si chaque composante de chemin était à son tour la fin du nom de fichier. De même, un «sub/foo» non préfixé correspond à n'importe où dans l'arborescence où il y a un «foo» dans un répertoire «sub». Voir la section ANCRER DES MOTIFS D'INCLUSION/EXCLUSION pour les détails sur la manière de spécifier des motifs correspondant à la racine du transfert.
si le motif finit par un /, il va uniquement correspondre à un répertoire, pas à un fichier, ni un lien ni un périphérique.
si le motif contient un méta-caractère parmi les caractères *?[, la correspondance d'expression est appliquée en utilisant les règles de correspondance du shell. Sinon une simple correspondance de chaîne de caractères est utilisée.
le motif double astérisque «**» correspond à tous les caractères, y comprit les barres obliques, tandis que le motif astérisque «*» s'arrête aux barres obliques.
si le motif contient un / (à l'exclusion d'un / final) ou un «**» alors il est comparé au nom de fichier complet, y compris les répertoires précédant le nom. Si le motif ne contient pas de / ni de «**» alors il n'est comparé qu'à la dernière composante du nom de fichier. Encore une fois, souvenez-vous que l'algorithme est appliqué récursivement. Ainsi, «nom complet» peut être une portion quelconque d'un chemin.
Notez que, lors de l'utilisation de l'option --recursive (-r) (qui est implicite avec -a), chaque sous-composant de chaque chemin est visité récursivement, donc les motifs d'inclusion/exclusion sont appliqués récursivement au nom complet de chaque sous-composant (par exemple, pour inclure «/foo/bar/baz» les sous-composants «/foo» et «/foo/bar» ne doivent pas être exclus). En fait, les motifs d'exclusion court-circuitent l'étape de descente de répertoire lorsque rsync recherche les fichiers à transmettre. Si un motif exclut un répertoire parent en particulier, cela peut rendre l'inclusion d'un sous-répertoire inopérante car rsync ne descendra pas dans cette hiérarchie exclue par le motif. Ceci est particulièrement important lors de l'utilisation d'une règle «*». Par exemple, :
+ /un/chemin/ce-fichier-ne-sera-pas-trouvé
+ /fichier-inclut
- *
Cela ne fonctionne pas car le répertoire parent «un» est exclu par la règle «*», donc rsync ne découvrira jamais les fichiers présents dans les répertoires «un» ou «un/chemin». Une solution est de demander d'inclure tous les répertoires en utilisant la règle «+ */» (placez la quelque part avant la règle «- *»). Une autre solution est d'ajouter des règles d'inclusion spécifiques pour tous les répertoires parents qui nécessitent d'être visités. Par exemple, ce jeu de règles fonctionne correctement :
+ /un/
+ /un/chemin/
+ /un/chemin/ce-fichier-est-trouvé
+ /fichier-également-inclut
- *
Voici quelques exemples d'exclusion/inclusion :
«- *.o» exclut tous les fichiers correspondant à *.o
«- /foo» exclut un fichier du répertoire de base nommé foo
«- foo/» exclut tous les répertoires nommés foo
«- /foo/*/bar» exclut tous les fichiers nommés bar dans tous les répertoires situés deux niveaux au-dessous du répertoire nommé foo dans le répertoire de base.
«- /foo/**/bar» exclut tous les fichiers nommés bar dans tous les répertoires situés deux niveaux ou plus au-dessous du répertoire nommé foo dans le répertoire de base.
La combinaison de «+ */», «+ *.c», et «- *» inclut tous les répertoires et fichiers sources C et rien d'autre
La combinaison de «+ foo/», «+ foo/bar.c», et «- *» inclut uniquement le répertoire foo et foo/bar.c (le répertoire foo doit être inclus explicitement sinon il est exclu par le «*»)
| RÈGLES DE FILTRE DE FUSION DE FICHIER | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Il est possible de fusionner des fichiers entiers dans vos règles de filtre en spécifiant une règle de filtre de type merge (.) ou dir-merge (:) (comme présenté dans la section RÈGLES DE FILTRE ci-dessus).
Il y a deux sortes de fusion de fichier -- une seule fois («.») et par répertoire («:»). Lors de la fusion une seule fois, le fichier est lu une seule fois, et ses règles sont incorporées dans la liste de filtre à la place de la règle «.». Lors de la fusion par-répertoire, rsync recherchera dans chaque répertoire qu'il traverse un fichier avec le nom donné. Si le fichier existe, il fusionnera le contenu dans la liste de filtre héritée en cours.
Ces fichiers de règles par-répertoire doivent être créés du côté émetteur car c'est ce côté qui est parcouru pour trouver les fichiers à transmettre. Ces fichiers de règles peuvent également avoir besoin d'être transmis chez le récepteur si vous souhaitez qu'ils influent également sur les fichiers ne devant pas être effacés (voir RÈGLES PAR RÉPERTOIRE ET SUPPRESSION ci-dessous).
Quelques exemples :
merge /etc/rsync/default.rules
. /etc/rsync/default.rules
dir-merge .filtre-par-répertoire
dir-merge,n- .exclusions-non-hérités-par-répertoire
:n- .exclusions-non-hérités-par-répertoire
Les modificateurs suivants sont acceptés après une règle merge ou dir-merge :
Un - spécifie que le fichier ne doit consister qu'en des motifs d'exclusion, sans autres types de règles que les commentaires.
Un + spécifie que le fichier ne doit consister qu'en des motifs d'inclusion, sans autres types de règles que les commentaires.
Un C est une manière de spécifier que le fichier doit être lu d'une manière compatible avec CVS. Cela active «n», «w», et «-», et autorise aussi le caractère d'effacement de liste (!). Si aucun fichier n'est donné, «.cvsignore» est lu.
Un e exclura le nom du fichier fusionné du transfert ; par exemple «dir-merge,e .rules» est identique à «dir-merge .rules» et «- .rules».
Un n spécifie que les règles ne sont pas héritées par les sous-répertoires.
Un w spécifie que les règles sont séparés par des caractères blancs au lieu d'être séparés par des retours à la ligne. [NDT : w pour whitespace]. En plus, ceci désactive les commentaires. Note : l'espace qui sépare le préfixe de la règle est traité spécialement, donc «- foo + bar» est interprété comme deux règles (en considérant que l'interprétation de préfixe n'a pas été désactivée).
Vous pouvez aussi spécifier les modificateurs pour les règles «+» et «-» (ci-dessous) afin que les règles qui sont lues depuis le fichier aient par défaut ce modificateur déjà positionné. Par exemple, «merge,-/ .excl» traitera le contenu de .excl comme des exclusions en chemin absolu, tandis que «dir-merge,s .filt» et «:sC» ne verrons chacun leurs règles par-répertoire appliquées que du côté émetteur.
Les modificateurs suivants sont acceptés après un «+» ou un «-» :
Un «/» spécifie que les inclusions/exclusions doivent être traitées comme des chemins absolus, relatifs à la racine du système de fichiers. Par exemple, «-/ /etc/passwd» exclura le fichier passwd à chaque transfert du répertoire «/etc».
Un «!» spécifie que l'inclusion/exclusion prend effet si le motif ne correspond pas. Par exemple, «-! */ » exclura tout ce qui n'est pas un répertoire.
Un C spécifie que toutes les règles d'exclusion CVS doivent être insérées comme exclusion là où se trouve le «-C». Aucun argument ne doit suivre.
Un s spécifie que la règle ne s'applique qu'au côté émetteur (s comme sender). Lorsqu'une règle affecte le côté émetteur, elle empêche certains fichiers d'être transférés. Par défaut, une règle affecte les deux côtés à moins que --delete-excluded ne soit spécifiée, auquel cas par défaut les règles n'affectent que l'émetteur. Voir aussi les règles hide (H) et show (S), qui sont une autre manière de spécifier des inclusions/exclusions uniquement pour l'émetteur.
Un r spécifie que la règle ne s'applique qu'au côté récepteur (r comme receiver). Lorsqu'une règle affecte le côté récepteur, elle empêche les fichiers d'être supprimés. Voir le modificateur s pour plus d'information. Voir aussi les règles protect (P) et risk (R), qui sont une autre manière de spécifier des inclusions/exclusions uniquement pour le récepteur.
Les règles par-répertoire sont héritées dans tous les sous-répertoires du répertoire ou le fichier fusionné a été trouvé à moins que le modificateur «n» n'est été utilisé. Chacune des règles des sous-répertoires sont préfixées aux règles par-répertoires héritées de leurs parents, ce qui donne une priorité plus élevée aux nouvelles règles par rapport aux règles héritées. Tout l'ensemble des règles de fusion de répertoire est groupé à l'emplacement où le fichier fusionné était spécifié, donc il est possible de remplacer une règle de fusion de répertoire par une règle spécifiée avant dans la liste des règles globales. Lorsque la règle d'effacement de liste (!) est lue depuis un fichier par-répertoire, elle n'efface que les règles héritées du fichier actuellement fusionné.
Un autre moyen d'éviter une simple règle d'un fichier de fusion de répertoire d'être héritée est de l'ancrer à l'aide d'une barre oblique au début. Les règles ancrées dans un fichier fusionné par-répertoire sont relatives au répertoire du fichier fusionné, donc un motif «/foo» ne correspondra qu'avec le fichier «foo» dans le répertoire où le fichier du filtre de fusion de répertoire a été trouvé.
Voici un exemple de fichier filtre que vous pouvez spécifier via --filter=". fichier":
merge /home/util/.filtre-global
- *.gz
dir-merge .règles
+ *.[ch]
- *.o
Cela fusionnera le contenu du fichier /home/util/.filtre-global au début de la liste et indique que le nom de fichier «.règles» correspond à des fichiers filtres par-répertoire. Toutes les règles lues avant le début du balayage du répertoire suivent les règles globales ancrées (c-à-d qu'une barre oblique correspond à la racine du transfert).
Si un fichier fusionné par-répertoire est spécifié avec un chemin qui est un répertoire parent du premier répertoire transféré, rsync balayera tous les répertoires parents depuis ce point de départ jusqu'au répertoire de transfert pour trouver le fichier par-répertoire indiqué. Par exemples, voici un filtre habituel (voir -F) :
--filter=': /.rsync-filter'
Cette règle indique à rsync de balayer tous les répertoires depuis la racine jusqu'au répertoire parent du transfert pour trouver .rsync-filter avant de débuter le balayage normal des fichiers contenus dans les répertoires. (Note : pour un démon rsync, la racine est toujours identique au «chemin» du module).)
Quelques exemples de ce pré-balayage pour trouver des fichiers par-répertoire :
rsync -avF /src/chemin/ /dest/rép
rsync -av --filter=': ../../.rsync-filter' /src/chemin/ /dest/rép
rsync -av --filter=': .rsync-filter' /src/chemin/ /dest/rép
Les deux premières commandes ci-dessus rechercherons «.rsync-filter» dans «/ » et «/src » avant que le balayage normal ne commence à chercher des fichiers dans «/src/chemin/» et ses sous-répertoires. La dernière commande évite le balayage des répertoires parents et ne cherchera les fichiers «.rsync-filter» que dans les répertoires qui font partie du transfert.
Si vous souhaitez inclure le contenu d'un «.cvsignore» dans vos motifs, il est avantageux d'utiliser la règle «:C», elle crée une fusion par répertoire du fichier .cvsignore mais parsé de manière compatible avec CVS. Vous pouvez l'utiliser pour indiquer où l'option d'inclusion par répertoire du fichier .cvsignore --cvs-exclude (-C) sera placée parmi les règles en indiquant «:C» là où vous le souhaitez. Sans cela, rsync ajoutera la fusion par-répertoire du fichier .cvsignore après toutes les autres règles (en lui donnant une priorité inférieure aux règles sur la ligne de commande). Par exemple :
cat <<EOT | rsync -avC --filter='. -' a/ b
+ foo.o
:C
- *.old
EOT
rsync -avC --include=foo.o -f :C --exclude='*.old' a/ b
Les deux commandes ci-dessus sont identiques. Chacune fusionnera toutes les règles .cvsignore (et qui sont par répertoire) au milieu de la liste plutôt qu'à la fin. Cela permet aux règles spécifiques au répertoire d'être prioritaires sur les règles déclarées après le :C, au lieu d'être soumises l'ensemble des règles. Pour affecter les autres règles d'exclusion CVS (c'est-à-dire la liste par défaut d'exclusion, le contenu de $HOME/.cvsignore, et la valeur de $CVSIGNORE) vous devez omettre l'option de ligne de commande -C et à la place insérer une règle «-C» dans les règles de filtres ; par exemple «--filter=-C».
| RÈGLE DE FILTRE D'EFFACEMENT DE LA LISTE | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Il est possible d'effacer la liste courante d'inclusion/exclusion en ajoutant la règles de filtre «!» (comme introduit dans la section RÈGLES DE FILTRE ci-dessus). La liste «courante» est soit la liste globale de règles (si la règle est lue lorsque les options de filtre sont parsées), soit un ensemble de règles par-répertoire qui sont héritées dans leurs sous-listes respectives (cela permet à un sous-répertoire d'effacer les règles de son parent).
| MOTIFS D'ANCRAGE D'INCLUSION/EXCLSUION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Comme décrit précédemment, les motifs globaux d'inclusion/exclusion sont ancrés «à la racine du transfert» (en opposition aux motifs par-répertoire qui sont ancrés au répertoire du fichier fusionné). En imaginant le transfert comme un sous-arbre de noms qui sont envoyés de l'émetteur au récepteur, la racine du transfert est là où l'arbre commence a être dupliqué dans le répertoire de destination. Cette racine fixe à partir d'où les motifs commençant par un / correspondent.
Étant donné que les correspondances sont relatives à la racine du transfert, la modification de la barre oblique en début de chemin de source ou l'usage de l'option --relative affecte le chemin utilisé pour les correspondances (en plus des modifications concernant l'arbre de fichier à dupliquer sur l'hôte destination). Les exemples suivants démontrent cela.
Supposons que l'on souhaite faire correspondre deux fichiers sources, l'un avec comme chemin absolu «/home/me/foo/bar», l'autre avec comme chemin «/home/you/bar/baz». Voici les différentes commandes possibles pour un transfert avec deux sources :
Commande : rsync -a /home/me /home/you /dest
Motif +/- : /me/foo/bar
Motif +/- : /you/bar/baz
Fichier cible : /dest/me/foo/bar
Fichier cible : /dest/you/bar/baz
Commande : rsync -a /home/me/ /home/you/ /dest
Motif +/- : /foo/bar (noter le «me» manquant)
Motif +/- : /bar/baz (noter le «you» manquant)
Fichier cible : /dest/foo/bar
Fichier cible : /dest/bar/baz
Commande : rsync -a --relative /home/me/ /home/you /dest
Motif +/- : /home/me/foo/bar (noter le chemin absolu)
Motif +/- : /home/you/bar/baz (idem)
Fichier cible : /dest/home/me/foo/bar
Fichier cible : /dest/home/you/bar/baz
Commande : cd /home; rsync -a --relative me/foo you/ /dest
Motif +/- : /me/foo/bar (commence depuis un chemin donné)
Motif +/- : /you/bar/baz (idem)
Fichier cible : /dest/me/foo/bar
Fichier cible : /dest/you/bar/baz
La manière la plus simple de voir quel nom vous devriez filtrer est de simplement regarder la sortie en utilisant --verbose et de rajouter un / au début de chaque nom (utilisez l'option --dry-run si vous n'êtes pas prêt à copier des fichiers).
| RÈGLES PAR RÉPERTOIRE ET SUPPRESSION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Sans option de suppression, les règles par-répertoire ne sont significatives que du côté émetteur, vous pouvez donc exclure les fichiers fusionnés sans affecter le transfert. Pour simplifier, le modificateur «e» ajoute cette exclusion pour vous, comme l'illustrent ces deux commandes équivalentes :
rsync -av --filter=': .excl' --exclude=.excl hote:src/dir /dest
rsync -av --filter=':e .excl' hote:src/dir /dest
Cependant, si vous souhaitez effectuer des suppressions du côté récepteur ET que vous voulez aussi que certains fichiers soient exclus des suppressions, vous devrez vous assurer que le côté récepteur sache quels fichiers supprimer. Le moyen le plus simple est d'inclure les fichiers fusionnés par-répertoire dans le transfert et d'utiliser --delete-after, car cela assurera que le côté récepteur a bien les mêmes règles d'exclusion que le côté émetteur avant qu'il ne tente de supprimer quoi que ce soit :
rsync -avF --delete-after hote:src/dir /dest
Cependant si les fichiers fusionnés ne font pas partie du transfert, vous devrez soit spécifier des règles globales d'exclusion (c'est-à-dire spécifiées en ligne de commande), soit maintenir vos propres fichiers fusionnés par-répertoire du côté récepteur. Voici un exemple de la première méthode (en supposant que les fichiers distants .règles s'excluent eux-mêmes) :
rsync -av --filter=': .rules' --filter='. /mes/extra.rules' --delete hote:src/dir /dest
Dans l'exemple ci-dessus le fichier extra.rules peut affecter les deux côtés du transfert, mais (du côté émetteur) les règles sont moins prioritaires que les règles fusionnées depuis les fichiers .rules puisqu'elles sont spécifiées après la règle de fusion par-répertoire.
Dans un dernier exemple, le côté émetteur exclue les fichiers .rsync-filter du transfert, mais nous souhaitons utiliser nos propres fichiers .rsync-filter pour contrôler ce qui sera supprimé chez le récepteur. Pour ce faire, nous devons spécifiquement exclure les fichiers fusionnés par répertoire (afin qu'ils ne soient pas supprimés) et mettre les règles dans les fichiers locaux pour contrôler ce qui ne devra pas être supprimer. Cela pourra ressembler à cette commande :
rsync -av --filter=':e /.rsync-filter' --delete \
hote:src/dir /dest
rsync -avFF --delete hote:src/dir /dest
| MODE TRAITEMENT PAR LOTS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Le mode de traitement par lots est utilisé pour appliquer le même ensemble de modification à plusieurs systèmes identiques. Imaginons que l'on ait un arbre qui soit répliqué sur un certain nombre d'hôtes. Supposons maintenant que des modifications aient été apportées à cet arbre source et que les changements doivent être propagés aux autres hôtes. Afin d'utiliser le mode de traitement par lots, rsync est exécuté avec l'option write-batch pour appliquer les modifications faites à l'arbre source à l'un des arbres destinations. L'option write-batch indique au client rsync de sauvegarder dans un fichier de traitement par lot toutes les informations nécessaires pour reproduire l'opération avec les autres arbres, identiques, de destinations.
Pour appliquer les modifications sauvegardées à un autre arbre de destination, exécutez rsync avec l'option read-batch, en indiquant le nom du fichier de traitement par lot et l'arbre de destination. Rsync met à jour l'arbre de destination en utilisant les informations stockées dans le fichier de traitement par lot.
Par commodité, un second fichier est créé lorsque l'option write-batch est utilisée. Le nom de ce fichier est créé en ajoutant «.sh» au nom du fichier de traitement par lot. Ce fichier .sh contient une ligne de commande qui permet de mettre à jour l'arbre de destination en utilisant le fichier de traitement par lot. Il peut être exécuté en utilisant un shell Bourne (ou équivalent). Il est possible de passer en argument un chemin alternatif vers l'arbre de destination, qui sera alors utilisé à la place du chemin original. C'est utile lorsque le chemin de l'arbre de destination diffère du chemin de l'arbre de destination original.
Générer le fichier de traitement par lot permet d'éviter d'effectuer la sélection de fichier, la somme de contrôle et la génération des blocs de donnée plus d'une fois lors de la mise à jour de plusieurs arbres de destination. Un protocole de transport multicast peut permettre de transférer le fichier de traitement par lot en parallèle vers plusieurs hôtes en une seule fois, au lieu de transférer les mêmes données à chaque hôte individuellement.
Exemples :
$ rsync --write-batch=foo -a hôte:/source/rep/ /dest-a/rep/
$ scp foo* distant:
$ ssh distant ./foo.sh /dest-b/rep/
$ rsync --write-batch=foo -a /source/rep/ /dest-a/rep/
$ ssh distant rsync --read-batch=- -a /dest-b/rep/ <foo
Dans ces exemples, rsync est utilisé pour mettre à jour /dest-a/rep/ depuis /source/rep/ et les informations pour répéter cette opération sont stockées dans «foo» et «foo.sh». L'hôte «distant» est ensuite mis à jour à l'aide des données dans le répertoire /dest-b/rep/. Les différences entre les deux exemples révèlent certaines des flexibilités qui vous sont offertes pour gérer le traitement par lot :
Le premier exemple montre que la copie initiale n'a pas à être locale -- vous pouvez recevoir ou envoyer les données depuis/vers l'hôte distant en utilisant soit la syntaxe du shell distant soit celle du démon rsync, à votre convenance.
Le premier exemple utilise le fichier créé « foo.sh» pour spécifier les bonnes options rsync lors de l'exécution de la commande read-batch sur l'hôte distant.
Le deuxième exemple lit les données via l'entrée standard, permettant ainsi d'éviter de copier le fichier de traitement par lot sur la machine distante. Cet exemple interdit l'utilisation du script foo.sh car on a besoin d'utiliser l'option --read-batch de manière différente, mais rien n'empêche bien sûr de modifier le script foo.sh pour l'utiliser (faites juste attention qu'aucune autre option ne tente d'utiliser l'entrée standard, telle que l'option «--exclude-from=-».
Avertissements :
L'option read-batch s'attend à ce que l'arbre de destination qui est mis à jour soit identique à l'arbre de destination qui a été utilisé pour créer le fichier de traitement par lot. Lorsqu'une différence entre les arbres de destination est détectée, la mise à jour sera soit abandonnée avec un avertissement (si le fichier semble déjà à jour) soit elle sera tentée et alors, si cela ne fonctionne pas, la mise à jour sera annulée, accompagnée d'une erreur. Par conséquent, relancer une opération read-batch si la commande a été interrompue devrait être sûr. Si vous souhaitez forcer la mise à jour quelque soient la date ou la taille du fichier, utilisez l'option -I (lors de la lecture du fichier de traitement par lot). Si une erreur arrive, l'arbre de destination se retrouvera probablement dans un état de mise à jour partielle. Dans ce cas, rsync peut être utilisé de manière régulière (sans le mode de traitement par lot) pour corriger l'arbre destination.
Les versions de rsync utilisées sur toutes les destinations doivent être au moins aussi récentes que celle utilisée pour générer le fichier de traitement par lot. Rsync se terminera avec une erreur si la version du protocole dans le fichier de traitement par lot est trop récente lors de l'application. Voir aussi l'option --protocol pour un moyen de générer un fichier de traitement par lot pour une version de rsync plus ancienne. (Notez que le format de fichier de traitement par lot a changé dans la version 2.6.3, par conséquent mélanger des versions antérieures et postérieures ne fonctionnera pas.)
Lors de la lecture d'un fichier de traitement par lot, rsync force la valeur de certaines options afin de les ajuster vis à vis des options sélectionnées lors création de ce fichier. Certaines options peuvent (et doivent) être différentes. Par exemple --write-batch est changée en --read-batch, --files-from est supprimée et les options --filter/--include/--exclude ne sont plus nécessaires à moins qu'une des options --delete n'ait été aussi spécifiée.
Le code qui crée le fichier BATCH.sh transforme toutes les options de filtres/inclusions/exclusions en une simple liste qui est ajoutée comme un document en ligne à la fin du fichier script. Un utilisateur avancé peut utiliser cette caractéristique pour modifier la liste d'exclusion si un changement de ce qui doit être supprimé par --delete est souhaité. Un utilisateur normal peut ignorer ces subtilités et concidéré le script shell simplement comme un moyen facile de lancer la commande --read-batch appropriée pour les données de traitement par lot.
À l'origine, le mode de traitement par lot était basé sur «rsync+», les nouvelles versions utilisent une implémentation différente.
| LIENS SYMBOLIQUES | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Trois comportements de base sont possibles lorsque rsync rencontre un lien symbolique dans le répertoire source.
Par défaut, les liens symboliques ne sont pas transférés. Un message «skipping non-regular file» (fichier non-régulier ignoré) est émis pour tous les liens symboliques existants.
Si --links est spécifié, alors les liens symboliques sont recrées avec la même cible. Notez que --archive implique --links.
Si --copy-links est spécifié, alors les liens symboliques sont «suivis» en les remplacant par le fichier vers lequel ils pointent.
De plus, rsync distingue les liens symboliques «sûrs» de ceux «non sûrs». Un exemple où ceci peut être utilisé est un miroir de site web qui veut s'assurer que le module rsync copié ne contient pas de liens symboliques vers /etc/passwd dans la section publique du site. L'utilisation de --copy-unsafe-links va copier tous les fichiers pointés par des liens sur la destination. L'utilisation de --safe-links empêche les liens non sûrs d'être copiés. (Notez que vous devez spécifier --links pour que --safe-links prenne effet.)
Les liens symboliques sont considérés non sûrs si ce sont des liens symboliques absolus (qui commencent par /), vides, ou s'ils contiennent suffisamment de «..» pour remonter au-dessus du répertoire copié.
Voici un résumé de l'interprétation des options de liens symboliques. Cette liste est classée par ordre de priorité, si votre combinaison d'options n'est pas mentionnée, utilisez la première ligne qui soient un sous-ensemble complet de vos options :
Transforme tous les liens symboliques en fichiers réguliers (ne laissant aucun lien symbolique aux autres options).
Transforme tous les liens symboliques non sûrs en fichiers et duplique tous les liens symboliques sûrs.
Transforme tous les liens symboliques non sûrs en fichiers, et ignore les liens symboliques sûrs en affichant un message.
Duplique les liens symboliques sûrs et ignore ceux non sûrs.
Duplique tous les liens symboliques.
| DIAGNOSTICS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
rsync produit occasionnellement des messages d'erreur qui peuvent paraître un peu cryptiques. Celui qui semble causer le plus de confusion est «protocol version mismatch - is your shell clean?».
Ce message est en général causé par vos scripts de démarrage ou un utilitaire pour le shell distant produisant des données parasites sur le flux utilisé par rsync pour son transport. Le moyen de diagnostiquer ce problème est d'exécuter votre shell distant comme ceci :
ssh hote-distant /bin/true > out.dat
ensuite examinez out.dat. Si tout fonctionne correctement, alors out.dat devrait être un fichier de taille zéro. Si vous obtenez de rsync l'erreur ci-dessus, alors vous allez probablement vous rendre compte que out.dat contient un peu de texte ou de données. Vérifiez le contenu et essayez de trouver ce qui le produit. La cause la plus courante est un script de démarrage du shell (comme .cshrc ou .profile) mal configuré contenant des instructions de sortie pour des logins non-interactifs.
Si vous avez des difficultés pour déboguer les motifs d'inclusion et d'exclusion, alors essayez de spécifier l'option -vv. À ce niveau de verbosité, rsync affichera la raison d'inclusion ou d'exclusion individuellement pour chaque fichier.
| VALEURS DE RETOUR | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Succès
Erreur de syntaxe ou d'utilisation
Incompatibilité de protocole
Erreurs lors de la sélection des fichiers et des répertoires d'entrée/sortie
Action non supportée : une tentative de manipulation de fichiers 64-bits sur une plate-forme qui ne les supporte pas ; ou une option qui est supportée par le client mais pas par le serveur.
Erreur lors du démarrage du protocole client-serveur
Démon incapable d'écrire dans le fichier de log
Erreur dans la socket E/S
Erreur d'E/S fichier
Erreur dans le flux de donnée du protocole rsync
Erreur avec les diagnostics du programme
Erreur dans le code IPC
SIGUSR1 ou SIGINT reçu
Une erreur retournée par waitpid()
Erreur lors de l'allocation des tampons de mémoire principaux
Transfert partiel dût à une erreur
Transfert partiel dût à la disparition d'un fichier source
La limite --max-delete a été atteinte
Dépassement du temps d'attente maximal lors d'envoi/réception de données
| VARIABLES D'ENVIRONNEMENT | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
La variable d'environnement CVSIGNORE permet d'ajouter des motifs d'exclusion à ceux trouvés dans les fichiers .cvsignore. Voir l'option --cvs-exclude pour plus de détails.
La variable d'environnement RSYNC_RSH vous permet de passer outre la commande utilisée par défaut comme transport pour rsync. Des options de ligne de commande sont permises après le nom de la commande, identiquement à l'option -e.
La variable d'environnement RSYNC_PROXY vous permet de rediriger votre client rsync pour utiliser un proxy web lors de la connexion à un démon rsync. RSYNC_PROXY doit être de la forme nom-hôte:port.
Fixer RSYNC_PASSWORD au mot de passe nécessaire vous permet d'exécuter des connexions rsync authentifiées à un démon rsync sans intervention de l'utilisateur. Notez que cela ne fournit pas de mot de passe à un shell de transport comme ssh.
Les variables d'environnements USER et LOGNAME sont utilisées pour déterminer le nom d'utilisateur par défaut envoyé à un démon rsync. Si aucune n'est positionnée, le nom d'utilisateur par défaut est «nobody».
La variable d'environnement HOME est utilisée pour trouver le fichier .cvsignore par défaut de l'utilisateur.
| FICHIERS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| VOIR AUSSI | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
rsyncd.conf(5)
| BOGUES | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Les dates sont transférées par des valeurs unix time_t.
Lors du transfert vers un système de fichier FAT, il se peut que rsync mette à jour des fichiers non modifiés. Reportez vous aux commentaires de l'option --modify-window.
Les permissions de fichiers, périphériques etc. sont transférés par valeurs numériques natives.
Voir aussi les commentaires de l'option --delete
Reportez les bogues s'il vous plaît ! Voir le site web à http://rsync.samba.org/
| VERSION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
| CRÉDITS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
rsync est distribué sous la licence publique GNU. Consultez le fichier COPYING pour plus de détails.
Un site WEB est disponible à http://rsync.samba.org/. Le site contient une FAQ-O-Matique qui peut répondre à certaines questions restées sans réponses à la lecture de ce manuel.
Le site ftp primaire pour rsync est ftp://rsync.samba.org/pub/rsync.
Nous serions ravis d'avoir de vos nouvelles si vous appréciez ce programme.
Ce programme utilise l'excellente bibliothèque de compression zlib écrite par Jean-loup Gailly et Mark Adler.
| REMERCIEMENTS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Merci à Richard Brent, Brendan Mackay, Bill Waite, Stephen Rothwell et David Bell pour leurs suggestions très utiles, patchs, et tests de rsync. J'ai probablement oublié certaines personnes, mes excuses.
Merci également à : David Dykstra, Jos Backus, Sebastian Krahmer, Martin Pool, Wayne Davison, J.W. Schultz.
| AUTEUR | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
rsync a été écrit par Andrew Tridgell <tridge@samba.org> et Paul Mackerras. De nombreuses autres personnes y ont contribué.
Des listes de diffusion pour le support et le développement sont disponibles à http://lists.samba.org
| TRADUCTION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Denis Mertz, 2002. Mise à jour par Éric Piel <eric POINT piel AT tremplin-utc POINT net>, 2005. Relecture par Frédéric Delanoy et Julien Soula.
LISTE DES MOTS-CLES | ||
|---|---|---|
| SFTP | 6 | SFTP CLIENT SFTP |
| SFTP | 5 | ssh_config Fichier de configuration de œsshœ |
| SSH | 4 | SSH CLIENT SSH |
| SSH | 3 | sshd_config Fichier de configuration de œsshdœ |
| SSHD | 2 | SSHD DEMON SERVEURSSH |
| SSHD | 1.3.5 | MISE EN PLACE ¡clé publique¡ SUR SERVEUR SSHD |
| sshd_config | 3 | sshd_config Fichier de configuration de œsshdœ |
| sshd_config | 2 | SSHD DEMON SERVEURSSH |
| ssh_config | 5 | ssh_config Fichier de configuration de œsshœ |
| ssh_config | 4 | SSH CLIENT SSH |
Ce document est distribué selon les termes de la licence G.P.L. Documentation. Vous êtes autorisés à le diffuser sur tout support de votre choix, à le publier sur un site internet ou intranet, à la condition que l'auteur original soit mentionné, ce afin d'assurer un meilleur suivi des mises à jour de ce document.
Auteur: Patrick MARION <pmarion19@free.fr>