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

Section: Maintenance Commands (8)
Sommaire
BSD mandoc
 



NOM   Début   Précédent   Suivant   Sommaire   Préc.page.lue   Accueil
sshd - démon SSH d'OpenSSH  



SYNOPSIS   Début   Précédent   Suivant   Sommaire   Préc.page.lue   Accueil
sshd [-deiqtD46 ] [-b bits ] [-f config_file ] [-g login_grace_time ] [-h host_key_file ] [-k key_gen_time ] [-o option ] [-p port ] [-u len ]  



DESCRIPTION   Début   Précédent   Suivant   Sommaire   Préc.page.lue   Accueil
sshd (démon SSH) est un démon pour ssh(1). Ces programmes remplacent rlogin et rsh, et fournissent des communications sécurisées et cryptées entre deux machines qui ne sont pas sûres, et ce, sur un réseau non sécurisé. Ces programmes ont pour but d'être les plus simples possibles à installer et à utiliser.

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 :

-b bits
Spécifie le nombre de bits de la clef éphémère du serveur pour la version 1 du protocole (par défaut 768).
-d
Mode de débogage. Le serveur envoie une sortie de débogage verbeuse dans le journal système, et ne passe pas à l'arrière-plan. Le serveur ne crée pas de processus fils et ne sert que pour une connexion. Cette option n'est utilisée que pour du débogage du serveur. En ajoutant des options -d, on augmente le niveau de débogage. Au maximum 3.
-e
Avec cette option, sshd envoie la sortie sur l'erreur standard au lieu du journal système.
-f configuration_file
Spécifie un nom de fichier de configuration. Par défaut /etc/ssh/sshd_config sshd ne démarre pas s'il n'y a pas de fichier de configuration.
-g login_grace_time
Donne un délai aux clients pour s'authentifier (par défaut 600 secondes). Si le client ne peut s'authentifier dans cet intervalle, se serveur se déconnecte et termine son exécution. Une valeur de 0 indique qu'il n'y a pas de limite.
-h host_key_file
Spécifie un fichier duquel on lit une clef de machine. On doit donner cette option si sshd n'est pas lancé avec le compte de root (comme les fichiers des clefs de machines ne sont normalement lisibles que par root). 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. Il est possible d'avoir plusieurs fichiers de clef de machine pour les différentes versions du protocole et des algorithmes de clefs de machine.
-i
Spécifie que sshd est démarré par inetd. sshd n'est normalement pas démarré par inetd, parce qu'il doit générer la clef du serveur avant de pouvoir répondre au client, et ceci peut prendre des dizaines de secondes. Les clients attendraient trop longtemps si la clef était regénérée à chaque fois. Toutefois, avec des clefs de petite taille (par exemple 512), l'utilisation de sshd depuis inetd est envisageable.
-k key_gen_time
Spécifie la période de régénération, en secondes, de la clef de serveur éphémère pour la version 1 du protocole (par défaut 3 600 secondes, ou une heure). La motivation pour régénérer la clef est que cette clef n'est pas stockée, et qu'après une heure, il devient impossible de retrouver la clef pour décrypter des communications interceptées, même si la machine est piratée, ou arrêtée physiquement. Une valeur de zéro indique que la clef n'est jamais regénérée.
-o option
Sert à spécifier des options dans le format du fichier de configuration. Utile pour spécifier des options qui n'ont pas d'équivalence en ligne de commandes.
-p port
Spécifie le port sur lequel le serveur écoute les connexions entrantes (par défaut 22). On peut spécifier plusieurs options de port. Les ports spécifiés dans le fichier de configuration sont ignorés quand un port est passé en option sur la ligne de commande.
-q
Mode silencieux. On n'envoie rien au journal système. Normalement, on enregistre le début, l'authentification et la fin de chaque connexion.
-t
Mode de test. Vérifie uniquement la validité du fichier de configuration et des clefs. Utile pour mettre à jour sshd de manière fiable, car des options de configuration peuvent changer.
-u len
Sert à spécifier la taille du champ de la structure utmp qui contient le nom de la machine distante. Si le nom de la machine après résolution est plus long que len on utilise la notation décimale pointée à la place. Ceci permet de continuer à identifier de manière unique les machines avec des noms très longs, qui dépassent la capacité de ce champ. En spécifiant -u0 on impose de toujours utiliser la notation décimale pointée dans le fichier utmp On utilise aussi -u0 pour éviter à sshd de faire des requêtes DNS si le mécanisme d'authentification ne le nécessite pas. Les mécanismes d'authentification qui peuvent nécessiter un DNS comprennent RhostsAuthentication RhostsRSAAuthentication HostbasedAuthentication et l'utilisation d'une option from=pattern-list dans un fichier de clef. Les options de configuration qui nécessitent une DNS comprennent l'utilisation d'un motif USER@HOST dans les options AllowUsers ou DenyUsers
-D
En spécifiant cette option, sshd ne se détache pas du terminal et ne devient pas un démon. Ceci permet une surveillance facile de sshd
-4
Force sshd à n'utiliser que des adresses IPv4.
-6
Force sshd à n'utiliser que des adresses IPv6.

 




FICHIER DE CONFIGURATION   Début   Précédent   Suivant   Sommaire   Préc.page.lue   Accueil
sshd lit les données de configuration depuis /etc/ssh/sshd_config (ou le fichier spécifié par l'option -f sur la ligne de commandes). Le format de ce fichier et les options de configuration sont décrits dans sshd_config5.  



PROCESSUS DE CONNEXION   Début   Précédent   Suivant   Sommaire   Préc.page.lue   Accueil
Lorsqu'un utilisateur se connecte avec succès, sshd procède comme suit :

  1. Si la connexion est sur un terminal et qu'aucune commande n'a été spécifiée, affiche la date de dernière connexion et le contenu du fichier /etc/motd (si accepté dans le fichier de configuration ou en l'absence de $HOME/.hushlogin Voir la section Sx FICHIERS ) .
  2. Si la connexion est sur un terminal, enregistre la date et l'heure de connexion.
  3. Vérifie le fichier /etc/nologin ; s'il existe, en affiche le contenu et sort (sauf pour root).
  4. Bascule pour s'exécuter avec les privilèges d'un utilisateur normal.
  5. Paramètre un environnement de base.
  6. Lit le contenu du fichier $HOME/.ssh/environment s'il existe.
  7. Va dans le répertoire de base (home directory) de l'utilisateur.
  8. Si le fichier $HOME/.ssh/rc existe, l'exécute ; sinon, si le fichier /etc/ssh/sshrc existe, l'exécute ; sinon, exécute xauth. Les fichiers « rc » reçoivent le protocole d'authentification et le cookie X11 en entrée standard.
  9. Exécute l'interpréteur de commandes (shell) ou la commande.

 




FORMAT DU FICHIER AUTHORIZED_KEYS   Début   Précédent   Suivant   Sommaire   Préc.page.lue   Accueil
$HOME/.ssh/authorized_keys est le fichier par défaut qui liste les clefs publiques autorisées pour l'authentification RSA pour la version 1 du protocole, et pour l'authentification par clef publique (PubkeyAuthentication) pour la version 2 du protocole. On peut utiliser l'option AuthorizedKeysFile pour spécifier un autre fichier de configuration.

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.

from=pattern-list
Spécifie qu'en plus de l'authentification RSA, le nom canonique de la machine distante doit figurer dans la liste des motifs séparés par des virgules (« * » et «? » sont des jokers). La liste peut aussi contenir des motifs précédés par l'opérateur de négation « ! » ; si le nom canonique de la machine correspond au motif nié, on n'accepte pas la clef. Le but de cette option est éventuellement d'améliorer la sécurité : l'authentification RSA en elle-même ne permet pas d'avoir confiance dans le réseau ou les serveurs de noms ou quoi que ce soit (à part la clef) ; par contre, si quelqu'un vole la clef, cette clef lui permet de se connecter depuis n'importe où dans le monde. Cette option supplémentaire rend encore plus difficile l'utilisation d'une clef volée (les serveurs de noms et/ou les routeurs peuvent avoir été compromis en plus de la clef elle-même).
command=commande
Spécifie que cette commande doit être exécutée si on utilise cette clef pour s'authentifier. La commande fournie par l'utilisateur (s'il y en a une) est ignorée. La commande est exécutée sur un pseudo-terminal (pty) si le client a demandé un pseudo-terminal ; sinon elle est exécutée sans terminal. Si on a besoin d'un canal 8-bits propre, on ne doit pas demander de pseudo-terminal, ou alors on spécifie no-pty On peut inclure une apostrophe (« ' ») dans la commande en la faisant précéder d'une anti-barre (« \ »). Cette option peut être utile pour restreindre à des actions spécifiques. Par exemple, une clef peut n'autoriser qu'à effectuer des sauvegardes distantes, mais rien d'autre. Note : le client doit spécifier des redirections TCP/IP ou X11 sauf s'ils sont explicitement interdits. Cette option s'applique à l'exécution d'un interpréteur de commandes (shell), d'une commande ou d'un sous-système.
environment=NAME=value
Spécifie que la chaîne de caractère doit être ajoutée à l'environnement lors de la connexion en utilisant cette clef. Les variables d'environnement définies de cette manière outrepassent les autres variables d'environnement par défaut. On peut spécifier plusieurs de ces options. Cette option est désactivée automatiquement si l'option UseLogin est activée.
no-port-forwarding
Interdit les redirections TCP/IP si on utilise cette clef pour l'authentification. Toute demande de redirection de port de la part de l'utilisateur retournera une erreur. Ceci peut être utilisé par exemple pour une connexion avec l'option command
no-X11-forwarding
Interdit les redirections X11 si on utilise cette clef pour l'authentification. Toute demande de redirection X11 de la part de l'utilisateur retournera une erreur.
no-agent-forwarding
Interdit les redirections de l'agent d'authentification si on utilise cette clef pour l'authentification.
no-pty
Empêche l'allocation de terminal (toute demande d'allocation d'un terminal virtuel échouera).
permitopen=host:port
Limite les redirections de port « ssh -L » locales de telle manière qu'il n'est possible de se connecter qu'à la machine et au port spécifiés. On peut spécifier des adresse IPv6 avec une autre syntaxe : host/port On peut spécifier plusieurs options permitopen en les séparant par des virgules. Aucune correspondance n'est effectuée sur les noms de machines, ils doivent être des adresses ou des domaines littéraux.

 




Exemples   Début   Précédent   Suivant   Sommaire   Préc.page.lue   Accueil
1024 33 12121...312314325 ylo@foo.bar

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
Les fichiers /etc/ssh/ssh_known_hosts et $HOME/.ssh/known_hosts contiennent les clefs publiques de toutes les machines connues. Le fichier global doit être préparé par l'administrateur (éventuellement), mais le fichier de l'utilisateur est mis à jour automatiquement : dès que l'utilisateur se connecte depuis une machine inconnue, elle est ajoutée au fichier de l'utilisateur.

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

/etc/ssh/sshd_config
Contient les données de configuration pour sshd Le format du fichier et les options de configuration sont décrites dans sshd_config5.
/etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key,
/etc/ssh/ssh_host_rsa_key Ces trois fichiers contiennent les parties privées des clefs de la machine. Ces fichiers sont la propriété de root, sont lisibles par root, et non accessibles aux autres. Note : sshd ne démarre pas si ce fichier est accessible au groupe et/ou aux autres.
/etc/ssh/ssh_host_key.pub, /etc/ssh/ssh_host_dsa_key.pub,
/etc/ssh/ssh_host_rsa_key.pub Ces trois fichiers contiennent les parties publiques des clefs de la machine. Ces fichiers doivent être lisibles par tous, mais accessibles en écriture à root uniquement. Leur contenu doit correspondre à leur partie privée respective. Ces fichiers ne sont pas vraiment utilisés ; ils sont fournis par commodité pour l'utilisateur qui peut les copier dans ses fichiers des machines connues. Ces fichiers sont créés par ssh-keygen1.
/etc/moduli
Contient les groupes Diffie-Hellman utilisés pour le "Diffie-Hellman Group Exchange".
/var/empty
répertoire chroot(2) utilisé par sshd lors de la séparation de privilèges dans la phase de pré-authentification. Le répertoire ne doit contenir aucun fichier, est la propriété de root et n'est pas accessible en écriture au groupe ou aux autres.
/var/run/sshd.pid
Contient d'identifiant du processus (PID) du démon sshd en attente de connexions (si plusieurs démons sont en cours d'exécution en même temps sur plusieurs ports, ce fichier contient l'identifiant du dernier processus démarré). Le contenu de ce fichier n'est pas sensible ; il peut être lisible par tout le monde.
$HOME/.ssh/authorized_keys
Liste les clefs publiques (RSA ou DSA) utilisables pour se connecter avec le compte de l'utilisateur. Ce fichier doit être lisible par root (ce qui peut signifier lisible par tout le monde sur quelques machines si le répertoire de base de l'utilisateur est sur un montage NFS). Il est recommandé qu'il ne soit pas accessible aux autres. Le format de ce fichier est décrit ci-avant. Les utilisateurs y mettent le contenu de leurs fichiers identity.pub id_dsa.pub et/ou id_rsa.pub comme décrit dans ssh-keygen1.
/etc/ssh/ssh_known_hosts et $HOME/.ssh/known_hosts
Ces fichiers sont consultés si on utilise les rhosts avec une authentification par machine ou une authentification par machine pour la version 2 du protocole pour vérifier la clef publique de la machine. La clef doit être listée dans un de ces fichiers pour être acceptée. Le client utilise les mêmes fichiers pour vérifier qu'il se connecte à la bonne machine distante. Ces fichiers ne doivent être accessibles en écriture que par root et leur propriétaire. /etc/ssh/ssh_known_hosts doit être lisible par tout le monde, et $HOME/.ssh/known_hosts peut être accessible en lecture à tout le monde, mais ce n'est pas nécessaire.
/etc/nologin
Si ce fichier existe, sshd empêche quiconque de se connecter, à l'exception de root. Le contenu de ce fichier est affiché à quiconque essaie de se connecter, et les connexions non-root sont refusées. Le fichier doit être lisible par tout le monde.
/etc/hosts.allow, /etc/hosts.deny
Les contrôles d'accès qui peuvent être appliqués par tcp-wrappers sont définis dans ces fichiers. Pour plus d'informations, voir hosts_access5.
$HOME/.rhosts
Ce fichier contient les paires machine/nom d'utilisateur, séparées par un espace, une par ligne. L'utilisateur spécifié sur la machine correspondante est autorisé à se connecter sans mot de passe. le même fichier est utilisé par rlogind et rshd. le fichier doit être accessible en écriture seulement à l'utilisateur ; il est recommandé qu'il ne soit pas accessible aux autres.

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.

$HOME/.shosts
Pour ssh, ce fichier est exactement le même que .rhosts Cependant ce fichier n'est pas utilisé par rlogin et rshd, donc son utilisation ne permet que des accès par SSH.
/etc/hosts.equiv
Ce fichier est utilisé pendant l'authentification .rhosts Dans la forme la plus simple, ce fichier contient des noms de machine, un par ligne. Les utilisateurs sur ces machines sont autorisés à se connecter sans mot de passe, pour peu qu'ils aient le même nom d'utilisateur sur les deux machines. Le nom de machine peut aussi être suivi d'un nom d'utilisateur ; ces utilisateurs sont autorisés à se connecter sous n'importe quel nom d'utilisateur sur cette machine (à l'exception de root). En outre, la syntaxe « +@group » peut être utilisée pour spécifier des groupes réseau. Les entrées niées commencent avec « - ».

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.

/etc/ssh/shosts.equiv
Ce fichier est traité exactement de la même manière que /etc/hosts.equiv Néanmoins, ce fichier peut être utile dans des environnements dans lesquels on souhaite utiliser rsh/rlogin et ssh.
$HOME/.ssh/environment
Ce fichier (s'il existe) est lu dans l'environnement lors de la connexion. Il peut ne contenir que des lignes vides, des lignes de commentaires (qui commencent par le caractère « # »), et des lignes d'affectations de la forme nom=valeur. Le fichier ne doit être accessible en écriture qu'à l'utilisateur ; il n'a pas besoin d'être accessible en lecture au groupe ou aux autres.
$HOME/.ssh/rc
Si ce fichier existe, il est exécuté avec /bin/sh après lecture des fichiers d'environnement, mais avant de démarrer l'interpréteur de commandes (shell) ou la commande de l'utilisateur. Il ne doit pas produire de sortie sur la sortie standard (stdout) ; on doit plutôt utiliser l'erreur standard (stderr). Si des redirections X11 sont en cours, il recevra la paire « proto cookie » en entrée standard (et DISPLAY dans son environnement). Le script doit appeler xauth(1) parce que sshd n'exécutera pas automatiquement xauth pour ajouter des cookies X11.

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.

/etc/ssh/sshrc
Identique à $HOME/.ssh/rc Ce fichier peut être utilisé pour spécifier globalement des initialisations pour la connexion spécifiques à une machine. Ce fichier ne doit être accesible en écriture qu'à root et lisible par 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.regénéré  



TRADUCTION FRANÇAISE   Début   Précédent   Suivant   Sommaire   Préc.page.lue   Accueil
Laurent GAUTROT <l dot gautrot at free dot fr> 05/12/2002  



AVERTISSEMENT SUR LA TRADUCTION   Début   Précédent   Suivant   Sommaire   Préc.page.lue   Accueil
Il est possible que cette traduction soit imparfaite ou périmée. En cas de doute, veuillez vous reporter au document original en langue anglaise fourni avec le programme.  



VOIR AUSSI   Début   Précédent   Suivant   Sommaire   Préc.page.lue   Accueil
scp(1), sftp(1), ssh(1), ssh-add1, ssh-agent1, ssh-keygen1, login.conf5, moduli(5), sshd_config5, sftp-server8
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
M. Friedl N. Provos W. A. Simpson "Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol" draft-ietf-secsh-dh-group-exchange-02.txt January 2002 work in progress material





 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

sshd_config - Fichier de configuration du démon SSH OpenSSH  




SYNOPSIS   Début   Précédent   Suivant   Sommaire   Préc.page.lue   Accueil

/etc/ssh/sshd_config

 




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) :

AFSTokenPassing

Spécifie si on peut rediriger un jeton AFS (AFS token) vers le serveur. Par défaut « no ».

AllowGroups

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.

AllowTcpForwarding

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.

AllowUsers

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.

AuthorizedKeysFile

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 ».

Banner

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.

ChallengeResponseAuthentication

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 ».

Ciphers

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 »
ClientAliveInterval

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.

ClientAliveCountMax

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.

Compression

Spécifie si on autorise la compression. L'argument doit être « yes » ou « no ». Par défaut « yes ».

DenyGroups

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.

DenyUsers

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.

GatewayPorts

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 ».

HostbasedAuthentication

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 ».

HostKey

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.

IgnoreRhosts

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 ».

IgnoreUserKnownHosts

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 ».

KeepAlive

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 ».

KerberosAuthentication

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 ».

KerberosOrLocalPasswd

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 ».

KerberosTgtPassing

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.

KerberosTicketCleanup

Spécifie si on détruit automatiquement le fichier cache du ticket de l'utilisateur à la déconnexion. Par défaut « yes ».

KeyRegenerationInterval

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).

ListenAddress

Spécifie l'adresse locale d'écoute sur laquelle le démon sshd doit attendre les connexions.

On peut utiliser les formes suivantes :

ListenAddress

host | IPv4_addr | IPv6_addr

ListenAddress

host | IPv4_addr : port

ListenAddress

[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é.

LoginGraceTime

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).

LogLevel

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é.

MACs Spécifie les algorithmes MAC (code d'authentification de message) disponibles.

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 ».

MaxStartups

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).

PAMAuthenticationViaKbdInt

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

PasswordAuthentication

Spécifie si l'authentification par mot de passe est autorisée. Par défaut « yes ».

PermitEmptyPasswords

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 ».

PermitRootLogin

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.

PidFile

Spécifie l'emplacement du fichier contenant l'identifiant du processus du démon sshd Par défaut /var/run/sshd.pid

Port

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

PrintLastLog

Spécifie si sshd doit afficher la date et l'heure de la dernière connexion de l'utilisateur. Par défaut « yes ».

PrintMotd

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 ».

Protocol

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 ».

PubkeyAuthentication

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.

RhostsAuthentication

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.

RhostsRSAAuthentication

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.

RSAAuthentication

Spécifie si on autorise la pure authentification RSA. Par défaut « yes ». Cette option ne s'applique qu'à la version 1 du protocole.

ServerKeyBits

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.

StrictModes

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 ».

Subsystem

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.

SyslogFacility

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.

UseLogin

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.

UsePrivilegeSeparation

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 ».

VerifyReverseMapping

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 ».

X11DisplayOffset

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.

X11Forwarding

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.

X11UseLocalhost

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 ».

XAuthLocation

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 :

<rien>

secondes

s | S

secondes

m | M

minutes

h | H

heures

d | D

jours

w | W

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

600 secondes (10 minutes)

10m

10 minutes

1h30m

1 heure 30 minutes (90 minutes)

 




FICHIERS   Début   Précédent   Suivant   Sommaire   Préc.page.lue   Accueil

/etc/ssh/sshd_config

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

Laurent GAUTROT <l dot gautrot at free dot fr> 17/12/2002  




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

ssh - Client SSH OpenSSH (programme de connexion à distance)  




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.

~^Z

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.

~B

Émet un BREAK au système distant (uniquement pour la version 2 du protocole SSH, et si la machine d'en face le supporte).

~C

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

~R

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 :

-1

Force ssh à n'essayer que la version 1 du protocole.

-2

Force ssh à n'essayer que la version 2 du protocole.

-4

Force ssh à n'utiliser que des adresses IPv4.

-6

Force ssh à n'utiliser que des adresses IPv6.

-A

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.

-a

Désactive le transfert de connexion de l'agent d'authentification.

-b adr_assoc

Précise une interface réseau émettrice sur une machine qui en possède plusieurs, ou qui a des alias d'adresses réseau.

-C

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

-c crypt_spec

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 »
-D port

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.

-e ch | ^ch | none

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.

-F fich_config

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

-f

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

-g

Permet à des machines distantes de se connecter à des ports transférés locaux.

-I periph_carte_puce

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.

-i fich_identite

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).

-k

Désactive les transferts (délégation) d'identifiants GSSAPI vers le serveur.

-L port : host : hostport

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

-l nom_login

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.

-M

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.

-m mac_spec

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

N'exécute aucune commande distante. Utilisé pour les transferts de ports (seulement dans la version 2 du protocole).

-n

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

-o option

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.

AddressFamily

BatchMode

BindAddress

ChallengeResponseAuthentication

CheckHostIP

Cipher

Ciphers

ClearAllForwardings

Compression

CompressionLevel

ConnectionAttempts

ConnectTimeout

ControlMaster

ControlPath

DynamicForward

EscapeChar

ForwardAgent

ForwardX11

ForwardX11Trusted

GatewayPorts

GlobalKnownHostsFile

GSSAPIAuthentication

GSSAPIDelegateCredentials

Host

HostbasedAuthentication

HostKeyAlgorithms

HostKeyAlias

HostName

IdentityFile

IdentitiesOnly

LocalForward

LogLevel

MACs
NoHostAuthenticationForLocalhost

NumberOfPasswordPrompts

PasswordAuthentication

Port

PreferredAuthentications

Protocol

ProxyCommand

PubkeyAuthentication

RemoteForward

RhostsRSAAuthentication

RSAAuthentication

SendEnv

ServerAliveInterval

ServerAliveCountMax

SmartcardDevice

StrictHostKeyChecking

TCPKeepAlive

UsePrivilegedPort

User

UserKnownHostsFile

VerifyHostKeyDNS

XAuthLocation

-p port

Port à connecter sur la machine distante. On peut aussi le spécifier pour une machine donnée dans le fichier de configuration.

-q

Mode silencieux. Supprime tous les messages d'avertissement et de diagnostic.

-R port : host : hostport

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

-S ctl

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.

-s

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.

-T

Désactive l'allocation de pseudo-terminal.

-t

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.

-V

Affiche le numéro de version et quitte.

-v

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.

-X

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.

-x

Désactive le transfert X11.

-Y

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 :

DISPLAY

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).

HOME

Règle l'emplacement du répertoire personnel de l'utilisateur.

LOGNAME

Synonyme pour USER Utilisé pour la compatibilité avec les systèmes qui utilisent cette variable.

MAIL

Emplacement de la boîte à lettres de l'utilisateur.

PATH

Réglé à la valeur de la variable PATH spécifiée lors de la compilation de ssh

SSH_ASKPASS

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.)

SSH_AUTH_SOCK

Identifie le chemin de la socket unix-domain utilisée pour communiquer avec l'agent.

SSH_CONNECTION

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.

SSH_ORIGINAL_COMMAND

Cette variable contient la ligne de commande originale si une commande a été fournie. On peut utiliser cette variable pour extraire les arguments originaux.

SSH_TTY

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.

TZ

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).

USER

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

$HOME/.ssh/known_hosts

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).

$HOME/.ssh/identity, $HOME/.ssh/id_dsa, $HOME/.ssh/id_rsa

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.

$HOME/.ssh/identity.pub, $HOME/.ssh/id_dsa.pub, $HOME/.ssh/id_rsa.pub

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.

$HOME/.ssh/config

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.

$HOME/.ssh/authorized_keys

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.

/etc/ssh/ssh_known_hosts

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.

/etc/ssh/ssh_config

Le fichier de configuration pour toute la machine. Le format de ce fichier et les options de configuration sont décrits dans ssh_config5.

/etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_rsa_key

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é.

$HOME/.rhosts

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

$HOME/.shosts

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).

/etc/hosts.equiv

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.

/etc/ssh/shosts.equiv

Ce fichier est traité exactement comme le fichier /etc/hosts.equiv Il peut servir à autoriser des connexions avec ssh mais sans utiliser rsh/rlogin.

/etc/ssh/sshrc

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.

$HOME/.ssh/rc

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.

$HOME/.ssh/environment

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

ssh se termine avec le code de retour de la commande distante, ou 255 en cas d'erreur.  




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

ssh_config - fichiers de configuration du client SSH d'OpenSSH  




SYNOPSIS   Début   Précédent   Suivant   Sommaire   Préc.page.lue   Accueil

$HOME/.ssh/config

/etc/ssh/ssh_config

 




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.

Host

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.

AFSTokenPassing

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.

BatchMode

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 ».

BindAddress

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 ».

ChallengeResponseAuthentication

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 ».

CheckHostIP

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 ».

Cipher

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 ».

Ciphers

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 ».
ClearAllForwardings

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 ».

Compression

Spécifie si on utilise la compression. L'argument pour ce mot-clef est « yes » ou « no ». Par défaut « no ».

CompressionLevel

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.

ConnectionAttempts

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.

DynamicForward

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.

EscapeChar

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).

ForwardAgent

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 ».

ForwardX11

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 ».

GatewayPorts

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 ».

GlobalKnownHostsFile

Spécifie un fichier de base de données globale des clefs de machines à utiliser à la place de /etc/ssh/ssh_known_hosts

HostbasedAuthentication

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

HostKeyAlgorithms

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 ».

HostKeyAlias

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.

HostName

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

IdentityFile

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.

KeepAlive

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 ».

KerberosAuthentication

Spécifie si on utilise une authentification Kerberos.

L'argument pour ce mot-clef est « yes » ou « no ».

KerberosTgtPassing

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 ».

LocalForward

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.

LogLevel

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.

MACs Spécifie l'algorithme MAC (message authentication code) par ordre de préférence.

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 ».

NoHostAuthenticationForLocalhost

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.

NumberOfPasswordPrompts

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.

PasswordAuthentication

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 ».

Port

Spécifie le port pour se connecter sur la machine distante. Par défaut 22.

PreferredAuthentications

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 ».

Protocol

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.

ProxyCommand

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).

PubkeyAuthentication

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.

RemoteForward

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.

RhostsAuthentication

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.

RhostsRSAAuthentication

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).

RSAAuthentication

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.

SmartcardDevice

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é.

StrictHostKeyChecking

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 ».

UsePrivilegedPort

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 ».

User

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.

UserKnownHostsFile

Spécifie un fichier de base de données pour l'utilisateur de clefs de machines à utiliser au lieu de $HOME/.ssh/known_hosts

XAuthLocation

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

$HOME/.ssh/config

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.

/etc/ssh/ssh_config

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

Laurent GAUTROT <l dot gautrot at free dot fr> 08/11/2002  




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

Section: User Commands (1)
Sommaire
BSD mandoc
 



NOM   Début   Précédent   Suivant   Sommaire   Préc.page.lue   Accueil
sftp - Secure file transfer program - Programme de transfert de fichiers sécurisé  



SYNOPSIS   Début   Précédent   Suivant   Sommaire   Préc.page.lue   Accueil
sftp [-vC1 ] [-b batchfile ] [-o ssh_option ] [-s subsystem | sftp_server ] [-B buffer_size ] [-F ssh_config ] [-P sftp_server path ] [-R num_requests ] [-S program ] host
sftp [[user@]host[:file [file]]]
sftp [[user@]host[:dir[/]]]  



DESCRIPTION   Début   Précédent   Suivant   Sommaire   Préc.page.lue   Accueil
sftp est un programme interactif de transfert de fichiers, semblable à ftp(1), mais qui réalise toutes ses opérations dans une transmission ssh(1) cryptée. Il peut également utiliser de nombreuses fonctionnalités de ssh, comme l'authentification par clef publique et la compression. sftp se connecte à une machine host puis bascule dans un mode interactif.

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 :

-b batchfile
Lit une suite de commande depuis un fichier batchfile en entrée au lieu de l'entrée standard stdin en mode traitement par lot (batch). Comme il n'y a pas d'interaction avec un utilisateur, il est souhaitable de l'utiliser avec une authentification non interactive. sftp s'arrête si l'une des commandes suivantes échoue : get , put , rename , ln rm , mkdir , chdir , lchdir ou lmkdir
-o ssh_option
Permet de passer des options dans le format utilisé par ssh_config5 à ssh C'est particulièrement utile pour spécifier des options pour lesquelles il n'y a pas d'équivalent en ligne de commande . Par exemple, pour préciser un port différent du port par défaut : sftp -oPort=24
-s subsystem | sftp_server
Spécifie un sous-système (subsystem) SSH2, ou le chemin vers un serveur sftp sur la machine distante. L'utilisation d'un chemin pour un serveur sftp est bien utile pour utiliser sftp en version 1 (Note du traducteur : C'est une nouvelle fonctionnalité de OpenSSH 2), ou si le sshd distant n'a pas configuré de sous-système sftp.
-v
Augmente la verbosité. On peut aussi passer cette option à ssh.
-B buffer_size
Spécifie à sftp la taille du tampon à utiliser lors des transferts de fichiers. De grand tampons nécessitent moins d'allers-retours, mais consomment davantage de mémoire. Par défaut 32768 octets.
-C
Active la compression (à travers l'option -C de ssh).
-F ssh_config
Spécifie un fichier de configuration utilisateur différent pour ssh Cette option est transmise directement à ssh(1).
-P sftp_server path
Se connecte directement à un serveur sftp sftp-server (plutôt qu'à travers ssh). Utile pour le débogage du client et du serveur.
-R num_requests
Spécifie un nombre de demandes en suspens à tout instant. Ceci peut améliorer la vitesse de transfert, mais consomme davantage de mémoire. Par défaut 16 demandes en attente.
-S program
Nom du programme de substitution pour la connexion cryptée. Ce programme doit comprendre les options de ssh(1).
-1
Force l'utilisation de la version 1 du protocole.

 




COMMANDES INTERACTIVES   Début   Précédent   Suivant   Sommaire   Préc.page.lue   Accueil
En mode interactif, sftp utilise un jeu de commandes proches de celles de ftp(1). Les commandes ne sont pas sensibles à la casse, et les chemins de fichiers ou de répertoires doivent être protégés par des guillements s'ils contiennent des espaces.

bye
Quitte sftp.
cd path
Change le répertoire distant vers le chemin path
lcd path
Change le répertoire local vers le chemin path
chgrp grp path
Change le groupe du fichier path vers grp grp doit être un identifiant de groupe (GID) numérique.
chmod mode path
Change les permissions du fichier path à mode
chown own path
Change le propriétaire du fichier path vers own own doit être un identifiant d'utilisateur (UID) numérique.
exit
Quitte sftp.
get [flags ] remote-path [local-path ]
Récupère le chemin distant remote-path et le stocke sur la machine locale. Si le chemin local n'est pas précisé, il aura le même nom que sur la machine distante. Si l'option -P est spécifiée, on copie intégralement les permissions et la date d'accès.
help
Affiche un texte d'aide.
lls [ls-options [path ] ]
Affiche un listage de répertoire local, soit du chemin path , soit du répertoire courant, si le chemin path n'est pas précisé.
lmkdir path
Crée un répertoire local dont le chemin path est spécifié.
ln oldpath newpath
Crée un lien symbolique de oldpath vers newpath .
lpwd
Affiche le répertoire local en cours.
ls [path ]
Affiche un listage du répertoire distant, soit du chemin path soit du répertoire courant si path n'est pas précisé.
lumask umask
Règle le masque local de création de fichier à umask
mkdir path
Crée le répertoire distant spécifié par son chemin path
put [flags ] local-path [local-path ]
envoie local-path et le stocke sur la machine distante. Si le chemin sur la machine distante n'est pas précisé, il aura le même nom que sur la machine locale. Si l'option -P est spécifiée, on copie intégralement les permissions et la date d'accès.
pwd
Affiche le répertoire distant en cours.
quit
Quitte sftp.
rename oldpath newpath
Renomme le fichier distant de oldpath vers newpath
rmdir path
Supprime le répertoire distant spécifié par son chemin path
rm path
Supprime le fichier distant spécifié par son chemin path
symlink oldpath newpath
Crée un lien symbolique de oldpath vers newpath
! command
Execute la commande command dans le shell local.
!
Bascule dans un shell local.
?
Synonyme pour help.

 




AUTEURS   Début   Précédent   Suivant   Sommaire   Préc.page.lue   Accueil
Damien Miller <djm@mindrot.org>  



VOIR AUSSI   Début   Précédent   Suivant   Sommaire   Préc.page.lue   Accueil
scp(1), ssh(1), ssh-add1, ssh-keygen1, ssh_config5, sftp-server8, sshd(8)
T. Ylonen S. Lehtinen "SSH File Transfer Protocol" draft-ietf-secsh-filexfer-00.txt January 2001 work in progress material





 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

rsync - Une alternative rapide et flexible à rcp  




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 :

o

possibilité de copier des liens, périphériques, propriétaires, groupes et permissions

o

des options exclut et exclut-depuis similaires à GNU tar

o

un mode d'exclusion CVS pour ignorer les mêmes fichiers que CVS

o

peut utiliser n'importe quel shell (interpréteur de commandes), y compris rsh et ssh

o

ne nécessite pas de privilèges root

o

pipelining des transferts de fichiers pour minimiser les coûts de latence

o

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 :

o

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://.

o

le premier mot après les «::» est le nom d'un module.

o

le démon distant peut afficher un message du jour lorsque vous vous connectez.

o

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.

o

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.

-h, --help

Affiche une page d'aide décrivant succinctement les options disponibles dans rsync.

--version

Affiche le numéro de version de rsync et quitte.

-v, --verbose

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.

-q, --quiet

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.

-I, --ignore-times

Normalement rsync ignore tous les fichiers qui ont la même taille et ont une horodate identique. Cette option arrête ce comportement.

--size-only

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.

--modify-window

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).

-c, --checksum

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.

-a, --archive

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.

-r, --recursive

Ceci dit à rsync de copier les répertoires récursivement. Référez-vous également à --dirs (-d).

-R, --relative

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.

--no-relative

Désactive l'option --relative. Cela n'est nécessaire que si vous souhaitez utiliser --files-from sans --relative qui est automatiquement activée.

--no-implied-dirs

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.

-b, --backup

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.

--backup-dir=REP

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).

--suffix=SUFFIXE

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.

-u, --update

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).

--inplace

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.

-d, --dirs

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).

-l, --links

Lorsque des liens symboliques sont rencontrés, ils sont recréés à la destination.

-L, --copy-links

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.

--copy-unsafe-links

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.

--safe-links

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.

-H, --hard-links

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.

-K, --keep-dirlinks

Coté réception, si un lien symbolique pointe vers un répertoire, il sera traité comme correspondant à un répertoire chez l'émetteur.

-W, --whole-file

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.

--no-whole-file

Désactive --whole-file, utile lorsqu'elle est activée par défaut.

-p, --perms

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).

-o, --owner

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.

-g, --group

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.

-D, --devices

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.

-t, --times

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).

-O, --omit-dir-times

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.

-n, --dry-run

Ceci dit à rsync de ne faire aucun transfert, mais de juste rapporter les actions qu'il aurait faites.

-S, --sparse

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.

-x, --one-file-system

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.

--existing

Ceci dit à rsync de ne créer aucun nouveau fichier -- uniquement mettre à jour les fichiers qui existent déjà sur la destination.

--ignore-existing

Ceci dit à rsync de ne pas mettre à jour les fichiers déjà existants chez le destinataire.

--remove-sent-files

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.

--delete

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.

--delete-before

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).

--delete-during, --del

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.

--delete-after

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.

--delete-excluded

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.

--ignore-errors

Dit à --delete de continuer et d'effacer les fichiers même lorsqu'il y a des erreurs E/S.

--force

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.

--max-delete=NUM

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.

--max-size=TAILLE

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").

-B , --block-size=TAILLE

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.

-e, --rsh=COMMANDE

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.

--rsync-path=PROGRAMME

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/

-C, --cvs-exclude

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.

-f, --filter=RÈGLE

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.

-F

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.

--exclude=MOTIF

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.

--exclude-from=FICHIER

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.

--include=MOTIF

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.

--include-from=FICHIER

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.

--files-from=FICHIER

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 :

o

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).

o

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.

o

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».

-0, --from0

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).

-T, --temp-dir=RÉP

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.

-y, --fuzzy

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.

--compare-dest=RÉP

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.

--copy-dest=REP

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.

--link-dest=RÉP

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.

-z, --compress

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.

--numeric-ids

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.

--timeout=DURÉE

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.

--address=ADRESSE

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.

--port=PORT

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.

--blocking-io

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.)

--no-blocking-io

Désactive --blocking-io, à utiliser lorsqu'elle est activée par défaut.

-i, --itemize-changes

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 :

o

Un < signifie que le fichier est transféré vers la machine distante (envoi).

o

Un > signifie que le fichier est transféré vers la machine locale (réception).

o

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.).

o

Un h signifie que l'entité est un lien matériel vers un fichier (requiert --hard-links).

o

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 :

o

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).

o

Un s indique que la taille du fichier est différente et qu'il sera mis à jour lors du transfert.

o

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.

o

Un p indique que les permissions sont différentes et qu'elles seront changées à la valeur de celles de l'émetteur (requiert --perms).

o

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).

o

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).

o

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).

--log-format=FORMAT

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).

--stats

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.

--partial

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.

--partial-dir=REP

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.

--delay-updates

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).

--progress

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.

-P

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.

--password-file

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.

--list-only

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).

--bwlimit=KBPS

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.

--write-batch=FICHIER

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.

--only-write-batch=FICHIER

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).

--read-batch=FICHIER

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.

--protocol=NUM

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).

-4, --ipv4 ou -6, --ipv6

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.

--checksum-seed=NUM

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 :

--daemon

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.

--address

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.

--bwlimit=KBPS

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.

--config=FICHIER

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).

--no-detach

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.

--port=PORT

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.

-v, --verbose

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.

-4, --ipv4 or -6, --ipv6

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).

-h, --help

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 :

o

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.

o

si le motif finit par un /, il va uniquement correspondre à un répertoire, pas à un fichier, ni un lien ni un périphérique.

o

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.

o

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.

o

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

«- *.o» exclut tous les fichiers correspondant à *.o

o

«- /foo» exclut un fichier du répertoire de base nommé foo

o

«- foo/» exclut tous les répertoires nommés foo

o

«- /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.

o

«- /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.

o

La combinaison de «+ */», «+ *.c», et «- *» inclut tous les répertoires et fichiers sources C et rien d'autre

o

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 :

o

Un - spécifie que le fichier ne doit consister qu'en des motifs d'exclusion, sans autres types de règles que les commentaires.

o

Un + spécifie que le fichier ne doit consister qu'en des motifs d'inclusion, sans autres types de règles que les commentaires.

o

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.

o

Un e exclura le nom du fichier fusionné du transfert ; par exemple «dir-merge,e .rules» est identique à «dir-merge .rules» et «- .rules».

o

Un n spécifie que les règles ne sont pas héritées par les sous-répertoires.

o

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).

o

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 «-» :

o

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».

o

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.

o

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.

o

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.

o

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 :

o

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.

o

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.

o

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 :

--copy-links

Transforme tous les liens symboliques en fichiers réguliers (ne laissant aucun lien symbolique aux autres options).

--links --copy-unsafe-links

Transforme tous les liens symboliques non sûrs en fichiers et duplique tous les liens symboliques sûrs.

--copy-unsafe-links

Transforme tous les liens symboliques non sûrs en fichiers, et ignore les liens symboliques sûrs en affichant un message.

--links --safe-links

Duplique les liens symboliques sûrs et ignore ceux non sûrs.

--links

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

0

Succès

1

Erreur de syntaxe ou d'utilisation

2

Incompatibilité de protocole

3

Erreurs lors de la sélection des fichiers et des répertoires d'entrée/sortie

4

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.

5

Erreur lors du démarrage du protocole client-serveur

6

Démon incapable d'écrire dans le fichier de log

10

Erreur dans la socket E/S

11

Erreur d'E/S fichier

12

Erreur dans le flux de donnée du protocole rsync

13

Erreur avec les diagnostics du programme

14

Erreur dans le code IPC

20

SIGUSR1 ou SIGINT reçu

21

Une erreur retournée par waitpid()

22

Erreur lors de l'allocation des tampons de mémoire principaux

23

Transfert partiel dût à une erreur

24

Transfert partiel dût à la disparition d'un fichier source

25

La limite --max-delete a été atteinte

30

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

CVSIGNORE

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.

RSYNC_RSH

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.

RSYNC_PROXY

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.

RSYNC_PASSWORD

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.

USER ou LOGNAME

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».

HOME

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

/etc/rsyncd.conf ou rsyncd.conf

 




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

Cette page de manuel est à jour pour la version 2.6.6 de rsync.

 




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

SFTP6 SFTP CLIENT SFTP
SFTP5 ssh_config Fichier de configuration de œsshœ
SSH4 SSH CLIENT SSH
SSH3 sshd_config Fichier de configuration de œsshdœ
SSHD2 SSHD DEMON SERVEURSSH
SSHD1.3.5 MISE EN PLACE ¡clé publique¡ SUR SERVEUR SSHD
sshd_config3 sshd_config Fichier de configuration de œsshdœ
sshd_config2 SSHD DEMON SERVEURSSH
ssh_config5 ssh_config Fichier de configuration de œsshœ
ssh_config4 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>


Valid HTML 4.01 Transitional