OpenSSH4.6p1

Présentation

Vous trouverez une page pour les clients SSH pour windows dans la section Windows.
 

Comment ça marche

SSH1

Il y a quatre manières de s'authentifier.

La première méthode va sans doute rappeler à certains les commandes "r" (rlogin, rcp, remsh ou rsh). Si asterix est listé dans le fichier /etc/hosts.equiv ou /etc/shots.equiv d'obelix, et qu'il existe un compte veronique sur obelix, veronique pourra se connecter sans problème avec ssh sur obelix.
Si l'utilisateur olivier possède un fichier ~/.shosts ou~/.rhosts contenant:

asterix veronique

veronique pourra se connecter sur le compte d'olivier avec ssh (en donnant néanmoins le mot de passe d'olivier).
Ces deux formes d'authentification ne sont absolument pas sécurisées,  Le problème avec cette méthode est que n'importe quelle machine peut se faire passer pour asterix (spoofing).

La deuxième méthode est l'authentification toujours sur les fameux fichiers rhosts et hosts.equiv mais combinée avec une authentification en utilisant les clés RSA des machines. C'est à dire qu'on vérifie d'abord /etc/hosts.equiv,/etc/shosts.equiv,~/.rhosts et ~/.shosts puis ensuite on vérifier si la clé publique du de la machine qui cherche à se connecter se trouve dans le fichier /etc/ssh_known_hosts ou ~/.ssh/known_hosts. Cette méthode est plus sécurisée car elle évite qu'une machine se fasse passer pour une autre, car à la connexion il va y avoir vérification de la clé publique par rapport à la clé privée de la machine cliente.

La troisième méthode est basée sur l'échange des clés utilisateurs en utilisant le protocole de gestion des clés RSA,veronique donne sa clé publique à olivier , quand elle essaye de se connecter sur le compte d'olivier, SSH vérifie que la clé publique que détient olivier correspond bien à la clé privée de véronique . Plus précisément du côté d'olivier le serveur SSH crypte un nombre aléatoire (un "challenge" dans la doc en anglais) en utilisant la clé publique de véronique détenue par olivier, seule la clé privée de veronique pourra décrypter ce "challenge", celui-ci est envoyé au client SSH qui va le décrypter avec la clé privée de véronique ce qui va authentifier cette dernière complètement.

Et la dernière méthode consiste à donner le mot de passe du compte sur lequel on se connecte, le mot de passe circule crypté sur le réseau.

Voyons le fonctionnement en détail de l'établissement d'une connexion:

Chaque machine possède un couple de clé (publique et privée par défaut de 1024 bits) de type RSA, quand le daemon se lance il génére une clé serveur (server key) de type RSA (par défaut 768bits). Cette clé serveur est normalement détruite et reconstruite à intervalle régulier (toutes les heures par défaut) et n'est jamais stockée sur le disque.
Quand un client se connecte, le daemon répond en envoyant la clé publique de la machine serveur et la clé serveur. La machine cliente va comparer la clé publique de la machine serveur par rapport à celle qui possède (s'il l'a) pour voir si elle n'a pas changée. Le client va générer alors un nombre aléatoire de 256 bits. Il crypte ce nombre en se servant de la clé publique et de la clé serveur de la machine serveur. Ce nombre aléatoire va servir pour générer une clé de session, on l'appelle clé de session car elle est spécifique à la session de connexion, cette clé de session va servir à chiffrer tout ce qui va transiter pendant la connexion. Les algo qui sont choisis pour crypter les données avec la clé de session qui vont circuler sont Blowfish, tripleDES.

SSH2

Avec SSH2 on utilise aussi l'authentification par clé privée-publique au niveau utilisateur, mais cette fois-ci en utilisant l'algorithme de gestion des clés DSA plutôt que RSA(tombé dans le domaine public en septembre 2000)
Avec ce protocole on a en plus des moyens supplémentaires pour assurer la confidentialité des données,  on peut chiffrer les données qui transitent en utilisant, entre autres, le tripleDES, Blowfish, CAST128 ou Arcfour et l'intégrité avec des algorithmes de hachage comme SHA1 ou MD5 ce que ne possède pas la version 1 de SSH.

Fonctionnement en détail:

C'est similaire à SSH1, chaque machine possède un couple de clé (publique et privée) de type DSA par contre. Quand le serveur se lance, aucune clé serveur n'est générée, on utilise une gestion de clé de type Diffie-Hellman. Cette gestion débouche sur la création d'une clé de session spécifique à la session de connexion qui servira à chiffrer les données qui vont transiter.

En pratique
Un utilisateur olivier sur la machine obelix peut autoriser certaines personnes venant de certaines machines à se connecter sous obelix en utilisant son compte. Pour cela il doit récupérer la clé publique de chacune de ces personnes. Lors de l'établissement de la communication SSH va vérifier que la clé publique d'un utilisateur que possède olivier correspond bien à clé privé de l'utilisateur en question.  En conséquence si olivier ne possède pas votre clé publique, il sera impossible de vous connecter sous son compte, le seul moyen est de "voler" la clé privée d'une personne habilitée (dont olivier possède la clé publique).
Si vous n'avez toujours pas compris, voici les différentes étapes pour établir une connexion via SSH entre les utilisateurs veronique sous asterix et olivier sous obelix.

veronique génére clé publique et privée sur asterix
olivier génére clé publique et privée sur obelix
veronique donne sa clé publique à olivier

veronique veut se connecter sous le compte d'olivier sous obelixen lançant un client SSH sous asterix
le daemon SSH sous obelix vérifie si olivierpossède bien la clé publique de veronique (autorisation)
Le daemon SSH sous obelix et le client SSH sous asterix rentrent en communication pour savoir si la clé publique de veronique que possède olivier correspond bien à la clé privée de veronique
veronique doit rentrer une phrase password (passphrase) pour s'identifier auprès du client SSH tournant sur asterix
veronique doit maintenant rentrer le mot de passe d'olivier(éventuellement)

Ca y est veronique est connecté sous le compte d'olivier après être passé par quatre phases d'identification.

Dans cette page on présentera OpenSSH pour un fonctionnement uniquement en utilisant SSH2, on passera sous silence tout ce qui concerne SSH1, notamment pour l'authentification en utilisant les fichiers.rhosts, .shosts,hosts.equiv et shosts.equiv.

OpenSSL

rpm -qa | grep -i openssl

Vous pouvez éventuellement supprimer les packages obtenus pour installer la version tarball généralement plus récente, avec la commande (rpm -e nom-du-package).

S'il y a une tonne de dépendances, ce n'est pas grave vous n'êtes pas obligé de supprimer le package, ça marchera très bien en faisant cohabiter la version mdk et la version tarball. Par contre pour pouvoir utilisé la dernière version d'OpenSSH vous devez utiliser aussi la dernière version d'OpenSSL qu'on peut récupérer  à l 'URL www.openssl.org sous la forme d'une archive tarball openssl-0.9.8e.tar.gz, qu'on va décompresser en tapant:

tar xvfz openssl-0.9.8e.tar.gz

Cela va nous créer un répertoire  openssl-0.9.8e dans lequel vous taperez

./config

Puis

make

Il est nécessaire avant d'aller plus loin de tester la biblio, pour cela préalablement si vous ne l'avez pas vous devez installer la commande bc (calculatrice en ligne), contenue dans une mandrake dans le package bc.

Tapons à présent:

make test

Vous ne devriez pas avoir d'erreur. Et enfin, en tant que root

make install

Cela va installer les fichiers (librairies, binaires, man, doc, ...) de SSL dans le répertoire /usr/local/ssl.

Installation d'OpenSSH

rpm -qa | grep -i openssh

Vous supprimez avec la commande rpm -e nomdupackage.

Vous pouvez récuperer la dernière version de OpenSSH   sur le site www.openssh.com. C'est une archive tarball openssh-4.6p1.tar.gz . La décompression de l'archive se fait dans un répertoire de travail en tapant:

tar xvfz openssh-4.6p1.tar.gz

Cela va créer le répertoire openssh-4.6p1. Vous devez maintenant installer le package XFree86-devel (ou libxorg-x11-devel ou bien encore xorg-dev sous ubuntu) pour pouvoir exporter X, ainsi que le package zlib1-devel (zlib1g-dev sous ubuntu). Maintenant dans le répertoire d'OpenSSH, vous devez maintenant taper:

./configure --with-ssl-dir=/usr/local/linux/openssl-0.9.8e --with-ldflags=-ldl

Vous devez indiquer le chemin des sources openssl conforme à votre système. Dans le cas où vous utilisez le package openssl de la Mandriva ou de la ubuntu  il faudra installer le package openssl-devel et tapez simplement  ./configure

On obtient en fin de commande un récapitulatif des options de compilation

Puis

make

A présent en tant que root, vous pouvez taper

On doit maintenant créer un utilisateur sshd, on tapera les commandes suivantes en tant que root

mkdir /var/empty
chown root:sys /var/empty
chmod 755 /var/empty
groupadd sshd
useradd -g sshd -c 'sshd privsep' -d /var/empty -s /bin/false sshd

/var/empty ne doit contenir aucun fichier. Ceci permet de réaliser certaines opérations sans être root.

make install

A la fin des commandes les clés de votre machine sont générées dans le cas où celles ci n'existent pas sous /usr/local/etc

Generating public/private rsa1 key pair.
Your identification has been saved in /usr/local/etc/ssh_host_key.
Your public key has been saved in /usr/local/etc/ssh_host_key.pub.
The key fingerprint is:
46:06:b1:dd:a1:84:fa:36:d0:77:b1:d8:75:d6:bf:03 root@asterix.kervao.fr
Generating public/private dsa key pair.
Your identification has been saved in /usr/local/etc/ssh_host_dsa_key.
Your public key has been saved in /usr/local/etc/ssh_host_dsa_key.pub.
The key fingerprint is:
0e:6f:19:83:12:96:a6:d1:4d:2b:d6:40:93:39:05:98 root@asterix.kervao.fr
Generating public/private rsa key pair.
Your identification has been saved in /usr/local/etc/ssh_host_rsa_key.
Your public key has been saved in /usr/local/etc/ssh_host_rsa_key.pub.
The key fingerprint is:
6e:1a:ef:b6:2b:92:26:ea:6f:34:72:e4:59:5c:70:4f root@asterix.kervao.fr
/usr/local/sbin/sshd -t -f /usr/local/etc/sshd_config

Cela va créer les clés publiques et privées de la machine qui seront placées par défaut dans /usr/local/etc . Plus précisément on trouve la clé privée ssh_host_key si on utilise la gestion de clés type RSA (SSH1) et la publique associée  ssh_host_key.pub et la clé privée ssh_host_dsa_key  si on utilise la gestion de clés type DSA (SSH2) et la clé publique associée ssh_host_dsa_key.pub.

NOTES - En cas d'upgrade les clés de la machine ne seront pas écrasées de même que les fichiers de conf.
               - Dans le cas où les clés de la machine sont réinitialisées, pensez à supprimer les fichiers ~/.ssh/known_hosts qui contiennent les identifiants des anciennes versions, sous peine d'obtenir le warning suivant

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the DSA host key has just been changed.
The fingerprint for the DSA key sent by the remote host is
0e:6f:19:83:12:96:a6:d1:4d:2b:d6:40:93:39:05:98.
Please contact your system administrator.
Add correct host key in /home/olivier/.ssh/known_hosts to get rid of this message.
Offending key in /home/olivier/.ssh/known_hosts:1
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
X11 forwarding is disabled to avoid man-in-the-middle attacks.

L'installation va installer les binaires utilisateurs sous /usr/local/bin, le daemon sous /usr/local/sbin et le serveur ftp sécurisé sous /usr/local/libexec

Les fichiers de config sont sous /usr/local/etc (ssh_config pour le client sshd_config pour le serveur). Si ces chemins ne vous plaisent pas, lancer configure avec les arguments qui vont bien donnés par:

configure --help

A présent si vous utilisez PAM (par défaut sur une mandrake) vous devez prendre le fichier sshd.pam se trouvant sous ./openssh-4.6p1/contrib/redhat et le placer sous /etc/pam.d en le renommant sshd tout court. En vous plaçant donc dans le répertoire de travail d'OpenSSH:

cp ./contrib/redhat/sshd.pam /etc/pam.d/sshd

NOTE Comment savoir si vous utilisez PAM, jetez un coup d'oeil dans /var/log/messages si vous voyez des mentions à PAM (PAM_pwdb par exemple quand vous vous loguez ou faites un su), c'est qu'il est actif sur votre système.

Vous noterez que dans le même répertoire on trouve aussi le fichier de démarrage de sshd en cas de démarrage standalone (voir chapitre correspondant ).

 

Configuration du serveur

# This is ssh server systemwide configuration file.

# port par défaut utilisé par SSH
# voir /etc/services
Port 22

# 2 si on utilise que SSH2
# si vous utilisez SSH1 et 2
# vous mettrez Protocol 2,1
Protocol 2

# adresse IP de l'interface d'où vont
# arriver les requêtes
# mettez l'adresse IP de votre carte réseau
ListenAddress 192.168.13.11

# fichier contenant la clé privée RSA si vous utilisez
# SSH1
# en commentaire ici, car on se sert que de SSH2
# HostKey /usr/local/etc/ssh_host_key

# fichier contenant la clé privée DSA si on utilise
# SSH2
# attention le fichier doit avoir pour droit 600
#HostKey /usr/local/etc/ssh_host_rsa_key
HostKey /usr/local/etc/ssh_host_dsa_key

# taille en bits et durée de validité de la clé serveur
# ne sert à rien pour SSH2
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 3600
#ServerKeyBits 768

# information de log
# on sauvegarde les logs dans /var/log/messages
# et /var/log/secure
SyslogFacility AUTH

# niveau de détail des logs
# pour plus de détails DEBUG
LogLevel INFO

# le serveur se déconnecte au bout de 600s
# si l'utilisateur n'a pas réussi à se loguer
LoginGraceTime 600

# est ce qu'on permet root de se loguer
# conseil: laisser à no
# il est préférable de se loguer en tant que simple utilisateur
# puis de faire su, ça laisse une trace au moins
PermitRootLogin no

# le serveur vérifier si les droits et le proprio de la home directory
# et des fichiers qui y contenus sont corrects avant d'accepter la connexion
StrictModes yes

# tentative de connexion limitée à 3
MaxAuthTries 3

# en cas d'authentification RSA
#RSAAuthentication yes

# si protocole SSH2 mettre à yes
PubkeyAuthentication yes
# fichier contenant les clés publiques
AuthorizedKeysFile     .ssh/authorized_keys

# concerne l'authentification basée sur les fichiers .rhosts...
# concerne SSH1
# on en veut pas ici
RhostsAuthentication no
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
IgnoreUserKnownHosts yes

# pour que l'utilisateur ait à donner le mot de passe
# du compte sur lequel il se connecte après avoir donné son passphrase
#PasswordAuthentication no

# en cas de mot de passe vide, la connexion
# est refusée systématiquement
# sert à rien si PasswordAuthentication à no
#PermitEmptyPasswords no

# mettre à no pour désactiver les mots de passe s/key (?)
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

#AFSTokenPassing no

# Kerberos TGT Passing only works with the AFS kaserver
#KerberosTgtPassing no

# on forwarde X
X11Forwarding yes

# le  DISPLAY sera fixé à serveur-ssh:10.0
X11DisplayOffset 10

# on peut afficher à la connexion un petit message
# contenu dans /etc/motd
PrintMotd no

# pour afficher la dernière date et heure de login
PrintLastLog yes

# lors d'une connexion, vérification régulière pour voir si le serveur
# n'est pas down pour pouvoir avertir l'utilisateur à temps.
TCPKeepAlive yes

# Laisser à no sinon le X forwarding ne marche pas
UseLogin no

# pour que certaines opérations soient réaliser en tant que non root
UsePrivilegeSeparation yes

# nombre de connexions non authentifiées max au serveur sshd
#MaxStartups 10

# On peut spécifier ici le path d'une bannière
#Banner /some/path

# sshd peut vérifier que l'hôte distant a le nom qui correspond bien
# à son adresse IP
#VerifyReverseMapping no

# Pour avoir le ftp sécurisé
Subsystem       sftp    /usr/local/libexec/sftp-server

Les autres paramètres intéressants sont:

AllowUsers et AllowGroups pour spécifier les utilisateurs et groupes d'utilisateurs habilités à se connecter, ceux non listés n'ont pas le droit de se connecter. Dans le même style DenyGroups et DenyUsers qui a l'effet inverse.

ClientAliveInterval pour que sshd envoie un message si le client n'a pas d'activité au bout d'un certain temps. Marche avec ClientAliveCountMax qui fixe le nombre de message sans réponse à partir duquel la connexion est stoppée.

Ciphers  type de cryptage utiliser pour chiffrer le message, on a le choix entre 3des-cbc, blowfish-cbc, arcfour et cast128-cbc, par défaut on a 3des-cbc qui correspond au triple DES.

Configuration du client

# On peut spécifier des paramètres différents suivant
# le serveur avec le paramètre suivant
# voir exemple plus bas
Host *

# Est ce qu 'on forwarde aussi l'agent
# d'authentification
   ForwardAgent no

# est ce qu'on forwarde X
   ForwardX11 yes

# concerne l'authentification basée sur les fichiers
# concerne SSH1
# on ignore
RhostsRSAAuthentication no

# ça s'applique uniquement à SSH1
#   RSAAuthentication yes

# on utilise SSH2 donc à yes
PubkeyAuthentication yes

# pour rentrer le mot de passe du compte
# sur lequel on se connecte
PasswordAuthentication no

# si connexion par ssh échoue
# on tente par rsh
FallBackToRsh no

# est ce qu'on utilise rsh
UseRsh no

# si vous ne voulez ni rentrer le passphrase
# ni le mot de passe, on met à yes
# utilise pour lancer une connexion ssh
# en mode batch (dans un script)
BatchMode no

#Vérification de l'adresse IP du serveur
CheckHostIP yes

# Avant de rajouter la clé publique d'un serveur
# dans la liste de serveurs reconnus
# ssh va le demander à l'utilisateur
StrictHostKeyChecking ask

# fichier pour SSH1 seulement
#IdentityFile ~/.sshd/identity

# clés DSA pour SSH2
#Identity File ~/.ssh/id_rsa
IdentityFile ~/.ssh/id_dsa

# port par défaut du serveur
Port 22

# on utilise le protocole SSH2
   Protocol 2

# type de chiffrement pour SSH1
# Cipher 3des

# type de chiffrement pour SSH2 dans l'ordre de préférence
Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc

# caractère d'échappement par défaut
  EscapeChar ~

Les autres paramètres intéressants sont:

Compression pour en plus de crypter, compresser les données, pour info on utilise gzip. Marche avec CompressionLevel qui précise le niveau de compression (1 rapide mais compression moyenne à 9 lent mais bonne compression).

LogLevel pour avoir le niveau de détail quand on lance ssh en mode verbeux (-v), par défaut INFO mais on peut mettreDEBUG en cas de problèmes.

SmartcardDevice pour accèder à la carte à puce de l'utilisateur contenant la clé RSA !

Pour la variable Host vous pouvez spécifier des paramètres différents suivant le serveur, exemple avec le serveur tetepa (utilise SSH2) et atopa (utilise SSH1).

Host tetepa
    port 22
    Protocol 2
    Pubkeyauthentication yes
    PasswordAuthentication yes

Host atopa
    port 22
    Protocol 1
    RSAAuthentication yes
    PasswordAuthentication yes

Lancement du daemon sshd

NOTE Accessoirement si SSH devient votre outil de connexion préféré, supprimer le fichier telnet se trouvant sous /etc/xinetd.d .

Lancement avec xinetd
Créez le fichier ssh dans le répertoire /etc/xinetd.d

service ssh
{
        socket_type     = stream
        protocol        = tcp
        port            = 22
        wait            = no
        user            = root
        server          = /usr/local/sbin/sshd
        log_on_success          += USERID
       log_on_failure          += USERID
       server_args     = -i
}

Puis relancez le daemon

/etc/rc.d/init.d/xinetd restart

C'est bon xinetd est relancé, et le daemon sshd est prêt à recevoir les requêtes des clients.

ATTENTION En lançant sshd par xinetd, vous utilisez donc les TCP_WRAPPERS. Vous devez veiller à ce que les clients devant se connecter ne soient pas listés dans /etc/hosts.deny .

NOTE Il faut savoir que le lancement par xinetd n'est pas conseillé, car il génère des temps d'attente trop long (voir man sshd).

Lancement en standalone avec Mandriva
On prendra le fichier sshd.init se trouvant sous ./openssh-4.6p1/contrib/redhat  et on le placera sous /etc/rc.d/init.d en le renommant sshd . En se plaçant donc sous openssh-4.6p1, on tapera:

cp ./contrib/redhat/sshd.init /etc/rc.d/init.d/sshd

On veillera à modifier les chemins présents dans ce fichier  (notamment celui de ssh-keygen, des clés, de préciser le chemin absolu de sshd). Maintenant pour lancer sshd aux niveaux de marche 3, 4 et 5, on tapera:

chkconfig --level 345 sshd on

Pour l'arrêter aux niveaux de marche 0, 1, 2 et 6

chkconfig --level 0126 sshd off

Pour lancer sshd, il suffit maintenant de taper:

/etc/rc.d/init.d/sshd start

Manip qui sera effectué dès lors automatiquement au démarrage et que vous n'aurez plus à refaire.

Voilà un fichier de lancement à placer sous /etc/init.d et à nommer sshd

Création et échange des clés

[olivier@obelix olivier]$ssh-keygen -d
Generating public/private dsa key pair.
Enter file in which to save the key (/home/olivier/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/olivier/.ssh/id_dsa.
Your public key has been saved in /home/olivier/.ssh/id_dsa.pub.
The key fingerprint is:
4c:33:be:2e:b2:5e:4d:fa:52:50:bd:56:c6:95:7a:b9 olivier@obelix.kervao.fr

NOTE: l'option -d correspond à SSH2  pour la gestion de clés en utilisant DSA.

Les clés sera sauvegardée par défaut dans ~/.ssh , la clé privée a pour nom id_dsa et la clé publique id_dsa.pub

Il est nécessaire de rentrer un mot de passe (passphrase), à noter que ce mot de passe peut être une phrase avec des blancs.

Maintenant veronique doit faire de même sous asterix , elle doit ensuite par un moyen ou un autre faire parvenir sa clé publique (id_dsa.pub) à olivier, ce dernier va mettre le contenu de ce fichier dans le fichier (éventuellement à créer) ~/.ssh/authorized_keys.

ATTENTION il est primordial que la clé publique de veronique tienne sur UNE seule ligne dans le fichier authorized_keys, il ne doit pas y avoir de retour chariot.

NOTE Si olivier autorise plusieurs personnes à se connecter sur son compte par ssh, la syntaxe de authorized_keys deviendra:

# utilisateur veronique
contenu de id_dsa.pub de veronique sur une seule ligne

# utilisateur lambda
contenu de id_dsa.pub de lamba sur une seule ligne

# ainsi de suite

# est le début de commentaires, et les lignes vides ne sont pas prises en compte.

NOTE Pour changer de pass-phrase au niveau de ssh-keygen , il suffit de taper:

ssh-keygen -p

Connexion simple avec ssh

[veronique@asterix .ssh]$ ssh -l olivier obelix
The authenticity of host 'obelix (192.168.13.11)' can't be established.
DSA key fingerprint is bb:aa:0a:92:66:a8:6c:08:ab:6b:35:18:4d:ab:19:13.
Are you sure you want to continue connecting (yes/no)?yes
Warning: Permanently added 'obelix,192.168.13.11' (DSA) to the list of known hosts.
Enter passphrase for key '/home/veronique/.ssh/id_dsa':
Last login: Sat Jun 22 14:11:43 2002
[olivier@obelix olivier]$

C'est bon on est connecté,  à noter:

Warning: Permanently added 'obelix,192.168.13.11' (DSA) to the list of known hosts.

La machine obelix va être rajoutée à la liste des machines connues, y aura plus ce message par la suite, si vous voulez que la machine obelix ne soit pas rajoutée de manière permanente mettez le paramètre StrictHostKeyChecking  à yes dans ssh_config mais dans ce cas il faudra récupérer la clé publique d'obelix pour la mettre manuellement dans le fichier  ~/.ssh/known_hosts

A noter aussi que la prochaine fois que vous essayerez de vous connecter sur obelix, il ne sera plus nécessaire de rajouter -l olivier , ça sera ajouté automatiquement par défaut.

NOTES - Les infos sur la machine seront sauvegardées dans le fichier ~/.ssh/known_hosts
               - Pour ne pas avoir à saisir à chaque fois le passpharase, il faut utiliser un agent

Lancement une commande à distance

[veronique@asterix .ssh]$ ssh obelix df
Enter passphrase for key '/home/veronique/.ssh/id_dsa':
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/sdb1               149712     75053     66929  53% /
/dev/sda1               991995    806267    134478  86% /alphonse
/dev/sdb3               239979     77414    150175  34% /roger
/dev/sdb4                99136     42591     51425  45% /home
/dev/sdc5               938296    497756    392876  56% /usr
/dev/sdb5               496627    334344    136633  71% /usr/local
[veronique@asterix .ssh]$

Après exécution de la commande, la connexion est automatiquement coupée.

Lancement d'une commande X à distance

Remarquer bien que sur le client SSH, DISPLAY est positionné à localhost qui correspond au serveur c'est tout à fait normal,  et là si vous lancez une commande X elle s'affichera bien à l'écran d'asterix et non pas d'obelix.
xauth permet d'ajouter, éditer les autorisations pour se connecter à un serveur X, concrètement sshd va appeler xauth pour que les commandes X puissent s'afficher sur le client.

Bon par contre, si vous avez l'erreur suivante

[olivier@obelix olivier]$ xmms &
[1] 1036
[olivier@obelix olivier]$ Gdk-ERROR **: X connection to obelix.armoric.bz:10.0 broken (explicit kill or server shutdown).

[1]+  Exit 1                  xmms

Il faudra modifier le fichier .bashrc de l'utilisateur olivier au lieu de:

export XAUTHORITY=$HOME/.Xauthority

On mettra

[ -z $XAUTHORITY ] && export XAUTHORITY=$HOME/.Xauthority

Et là magique ça marche !! 

A noter que j'ai été incapable de faire marcher le X forwarding avec la Mandrake 8.2 (serveur et client).

Copier des fichiers

[veronique@asterix veronique]$ scp toto obelix:/tmp
Enter passphrase for DSA key '/home/veronique/.ssh/id_dsa':
toto                 100% |****************************************|    27       00:00

Maintenant on veut récupérer le fichier titi se trouvant dans la home directory d'olivier, pour le mettre sous le /tmp d'asterix

[veronique@asterix veronique]$ scp obelix:/home/olivier/titi /tmp
Enter passphrase for DSA key '/home/veronique/.ssh/id_dsa':
olivier@obelix's password:
titi                 100% |****************************************|    15       00:00

Maintenant on va récupérer tout le répertoire php d'olivier pour le placer dans le répertoire courant (.)

[veronique@asterix veronique]$ scp -r obelix:/home/olivier/php .
Enter passphrase for DSA key '/home/veronique/.ssh/id_dsa':
fichier1                 100% |****************************************|     5       00:00
repertoire1          100% |****************************************|     5       00:00
fichier2                 100% |****************************************|     5       00:00

Autres options intéressantes de scp:

-v verbose pour avoir un max de commentaires, notamment pour l'établissement de la connexion et l'identification.
-p pour préserver les droits (conseillé)
-c pour changer le type de cryptage
-B mode batch pour mettre scp dans un script (plus besoin de rentrer le passphrase et le mot de passe)
-C pour compresser

[Retour haut de la page ]

 Utilisation d'un agent

[Retour page d'accueil ]

[Retour haut de la page ]