Secure FTP et Secure Copy

copy (cp) de fichier Unix et il est conçu pour s’exécuter d’une seule traite, avec une opération de copie par invocation de commande.

Vous invoquerez sftp exactement comme ftp, mais avec une syntaxe de nom d’hôte légèrement modifiée :

sftp jdoe@iseries.acme.com sftp> get timecards.xcl timecards.xcl 100% 517KB 225.2KB/s 00:02 sftp> quit

Cela ouvre une session FTP interactive dans laquelle vous pouvez exécuter toutes les commandes FTP normales : dir, put, get, binary. La différence est que sftp crée d’abord un tunnel SSH qui est associé aux ports FTP sur le serveur de destination. En réalité, vous parlez au serveur FTP de destination, avec un « wrapper » SSH. L’option -b permet de spécifier dans un fichier, une série de commandes destinées à exécuter un transfert batch préstocké. Vous pouvez utiliser l’option -o pour passer les options dans le client SSH sous-jacent. Par exemple,

sftp –oCipher=blowfish
-oCompression
jdoe@iseries.acme.com

Cela ouvre un tunnel SSH avec cryptage Blowfish (avec une compression de données avant le cryptage), par lequel les échanges FTP se dérouleront. Le tunnel SSH compressera et décompressera automatiquement toutes les données.

Lorsque l’option -b de sftp vous permet d’effectuer des transferts de fichiers batch, vous pouvez accomplir la même chose avec une suite de commandes scp, dont chacune construira son propre tunnel SSH avant de copier le fichier ou les groupes de fichiers spécifiés. Comme scp code la totalité de la spécification du transfert de fichier sur la ligne de commande, vous pouvez utiliser n’importe quel caractère joker ligne de commande reconnu par votre OS. La liste des noms de fichiers à copier doit avoir comme préfixe username@iseries-host-name: Ainsi, la commande

scp pdfs/*.pdf
jdoe@iseries.acme.com
QOpenSys/jdoe

copie tous les fichiers présents dans le répertoire pdfs/ se terminant en .pdf, dans le répertoire /QOpenSys/ QIBM/ UserData/jdoe sur iseries.acme. com. La seule différence visible entre ceci et une commande cp normale est que vous serez invité à entrer un mot de passe. Cependant, scp met en cache ce mot de passe pendant un certain temps, afin qu’il ne soit pas nécessaire de le réentrer pour les commandes scp ultérieures vers le même hôte. Même si ce n’est pas évident, scp peut « tirer » un fichier d’un système distant également, en ajoutant simplement un préfixe nom d’utilisateur et d’hôte à l’argument source :

scp jdoe@iseries.acme.com:/
@OpenSys/jdoe/*.pdf pdfs/

Et, si vous voulez exécuter sftp ou scp sans intervention humaine ? Par exemple, supposons que vous effectuiez une sauvegarde nocturne sur Internet et que personne ne soit là pour taper le mot de passe demandé. SSH prévoit ce cas en utilisant des paires de clés publique/privée pour fournir une authentification automatique, sans mettre en péril les comptes impliqués en stockant leurs mots de passe sur disque en
texte clair. Pour utiliser cette possibilité, il faut d’abord générer une paire de clés DSA publique/privée côté client :

ssh-keygen -t dsa -f /
filecopy/.ssh/id_dsa/

Vous devrez d’abord créer à l’avance un utilisateur nommé filecopy sur la machine client et, dans le répertoire de départ de cet utilisateur, créer un répertoire nommé .ssh (si n’existe pas déjà). Il vous sera demandé une phrase de passe : une chaîne difficile à deviner de 10 à 20 caractères. La sortie obtenue ressemblera à celle-ci :

Enter passphrase (empty
for no passphrase):

Enter same passphrase again:

Your identification has been
saved in
/filecopy/.ssh/id_dsa.

Your public key has been
saved in
/filecopy/.ssh/id_dsa.pub.

The key fingerprint is:
1e:7f:59:96:22:92:3f:fb:50:
3f:81:9e:f3:ca:a0:aa

Le repertoire .ssh est l’emplacement par défaut des fichiers de paramètres uniques à l’utilisateur du programme client SSH. Une fois la paire de clés publique/privée générée, la clé publique sera un fichier nommé id_dsa.pub ; la clé privée se trouvera dans id_dsa, mais elle ne sera pas directement lisible.

Sur le système distant, copiez le fichier id_dsa.pub (pas le fichier is_dsa !) dans le répertoire de départ sshd de l’hôte (sur l’iSeries, /QOpen Sys/QIBM/ UserData/SC1/OpenSSH/openssh-3.5p1/etc/). On appelle cela la distribution de clé publique, et vous pouvez utiliser scp pour l’exécuter :

scp id_dsa.pub
jdoe@iseries.acme.com

Ce n’est pas l’ultime demeure de la clé publique sur le serveur. Vous devez maintenant ajouter ce fichier à la fin du fichier nommé « authorized_keys » dans le répertoire de paramètres de l’hôte SSH. Exécutez la commande suivante dans l’environnement PASE iSeries :

ssh jdoe@iseries.acme.com
>cat id_dsa.pub >>
/QOpenSys/QIBM/UserData/
SC1/OpenSSH/openssh-3.1p1/
etc/authorized_keys

Le fichier authorized_keys contient une liste de clés publiques avec lesquelles le serveur SSH échangera des fichiers sans besoin d’un mot de passe. Quand la commande client scp ou sftp sera exécutée, elle enverra une requête d’authentification au serveur mais elle cryptera d’abord cette requête avec sa clé privée. La seule clé capable de décrypter la requête d’authentification est la clé publique correspondante du client, de sorte que le serveur soit certain que le client est bien qui il prétend être, s’il parvient à décrypter la requête.

Dans le cas où les clés publiques seraient compromises sur le serveur, les conséquences ne seraient pas graves parce que les clés publiques ne peuvent pas servir à crypter les requêtes d’authentification – seule la clé privée secrète du client peut faire cela. En fait, les clés publiques peuvent être publiées dans un répertoire complètement ouvert, et c’est d’ailleurs ce qu’une PKI (public key infrastructure) fait dans l’authentification basée sur certificats de SSL.