CoolCoyote.net » ssh

Transfert de fichiers via SSH

Denis S. — Tue, 18 Aug 2009 20:53:48 +0000

Dernièrement j’ai eu à migrer le site d’un client d’un serveur dédié à un autre.

Au lieu de faire un backup des données sur ma machine puis les renvoyer sur le nouveau serveur, j’ai décidé de faire directement un transfert de serveur à serveur via SSH. C’est nettement plus rapide car on bénéficie de la bande passante du serveur.

Pour cela nous allons utiliser la commande scp. La procédure est toute simple, on se loggue sur le serveur de destination et on tape la commande suivante:

> scp -pr user@host:/home/user/www/ /home/user/

Quelques précisions:

-pr : signifie que l’on copie tout le contenu récursivement (dossiers, sous-dossiers et leur contenu) et que l’on veut conserver les options des fichiers
user@host : le login et l’adresse du serveur sur lequel on va chercher les fichiers. L’utilisateur est bien sûr un utilisateur valide sur le serveur sur lequel nous allons récupérer le contenu et qui a les droits de lecture sur les fichiers et dossiers que l’on veut télécharger.
/home/user/www : le chemin du répertoire contenant les fichiers à copier. Bien entendu c’est à personnaliser
/home/user/ : le chemin de destination des fichiers sur notre serveur local. A personnaliser aussi.

Notez que l’on vous demandera bien évidemment le mot de passe de l’utilisateur afin de pouvoir se connecter au serveur distant.

Les fichiers seront copiés en conservant le chmod de chaque fichier. Par contre leur appartenance sera changée selon l’utilisateur sous lequel vous allez faire l’opération. Si vous avez fait l’opération sous root, n’oubliez pas de faire un petit

> chown -R user:group /home/user/www

Les screens sous Debian

Denis S. — Mon, 04 Aug 2008 13:12:53 +0000

Les screens sont vraiment indispensables pour tous ceux qui travaillent en mode console sous ssh. Ils permettent de créer une ou des consoles virtuelles sous la même session qui ne se détruisent pas lorsque l’utilisateur se déconnecte. Concrêtement, lorsqu’on lance une compilation dans un screen, si vous avez un plantage réseau, connexion ou autre, la compilation continue. On peut se relogguer et récupérer la session screen qui était en cours. En plus de la protection apportées, les screens sont efficaces pour lancer un travail qui peut durer longtemps. On peut ainsi lancer un travail sur un serveur le soir, s’en déconnecter et aller se coucher, puis le lendemain reprendre le screen et obtenir le résultat.

Installation du paquet:

> apt-get install screen

les commandes screen à partir de la console:

> screen			// Lance un screen
> screen -r			// Reprends un screen détaché
> screen -d			// Force le détachement d'un screen en cas de plantage pour en reprendre le contrôle
> screen -ls			// Affiche la liste des screen mère

commandes à partir d’une console screen:

CTRL+A puis C = créer une nouvelle console screen
CTRL+A puis N = passer à la console screen suivante
CTRL+A puis P = passer à la console screen précédente
CTRL+A puis D = Détacher le screen et revenir sur la console classique
CTRL+D = fermer une console screen. Lorsqu’il n’y a plus qu’une seule console, ça quitte screen.

SSH: clé publique/privée

Denis S. — Mon, 04 Aug 2008 11:28:27 +0000

Cet article était présent sur l’ancienne version de coolcoyote.net. Comme je le trouve utile, je le remet, même si je ne l’ai pas retesté depuis.

Pour commencer nous allons définir que:

la machine locale sera la machine cliente, c’est-à-dire celle qui se connectera
la machine distante sera la machine serveur qui recevra la connexion

Générer les clés:

Pour ce faire, commencer par taper la commande ssh-keygen sur la machine locale:

> ssh-keygen -t dsa

l’option -t dsa indique que l’on utilise un cryptage dsa de la clé, utilisé par SSH2. La génération des clés commence:

Generating public/private dsa key pair.
Enter file in which to save the key (/usr/home/toto/.ssh/id_dsa):

Appuyer sur Enter pour accepter la localisation de la clef (il est plus simple d’accepter la localisation proposée). ssh-keygen demande ensuite une « passphrase » (équivalent d’un mot de passe, mais sous forme de phrase). Cette phrase sert à fortifier la clef pour la rendre plus difficilement cassable.

À partir de là, deux solutions :

Si on tape une phrase, la connexion sera plus sûre, mais il faudra utiliser ssh-agent pour ne pas avoir à la retaper à chaque fois
On ne tape pas de phrase (on appuie seulement sur Enter), la connexion sera moins sûre.

la fin de la procédure affiche quelque chose comme:

Your identification has been saved in /usr/home/toto/.ssh/id_dsa.
Your public key has been saved in /usr/home/toto/.ssh/id_dsa.pub.
The key fingerprint is:
1a:2a:3e:4a:1a:65:1c:89:10:92:9c:5c:1f:75:cc:de
toto@machineloc

Le générateur va créer 2 clés: id_dsa (la clé privée) et id_dsa.pub (la clé publique).

Utiliser les clés

Editer la clé publique et copier son contenu.
Se rendre sur la machine distante et éditer le fichier .ssh/authorized_keys (le créer s’il le faut)
Y copier le contenu de la clé publique sur une seule ligne
Sauvegarder

Procéder ainsi pour toutes les machines distantes sur lesquelles on veut se connecter

Tester la connexion

Une fois que les clés sont placées sur les serveurs local et distant, il faut tester la connexion ssh:

> ssh host "ls -a"

Normalement, le système va détecter la présence des clés et vous demander de confirmer l’utilisation de ces clés. Il faut donc taper « yes » et valider. Cette opération ne se fait qu’une seule fois.

The authenticity of host '213.186.158.139 (213.186.158.139)' can't be established.
RSA key fingerprint is 02:11:f2:db:ad:42:86:de:f3:10:9a:fa:41:2d:09:77.
Are you sure you want to continue connecting (yes/no)?