On Fri, 2 Nov 2001 15:17:53 +0100 (CET),
Félix Hauri <[EMAIL PROTECTED]> wrote:
> On Fri, 2 Nov 2001, Yann Sagon wrote:
> ...
> > sur ma machine, je fais ssh-keygen
> ...
> > $HOME/.ssh/authorized.key
> ...
> > debug1: try privkey: /home/ysagon/.ssh/id_dsa
> ...
>
> Essaie:
> $ ssh-keygen -d
> puis copier le fichier .ssh/id_dsa.pub vers la machine distante dans un
> fichier .ssh/authorized_keys2 ... (puis event. rtfm;)
>
> ... ou
> $ ssh -1 disthost
La réponse de Félix est essentiellement correcte, mais peut-être un peu
laconique. En gros, tu te génère et tu diffuse une clé pour la version 1 du
protocole, puis tu essayes de te connecter avec la version 2.
Pour info, voici *la version beta* d'un texte que j'ai diffusé il y a
quelques jours auprès de mes ex-collègues de l'EPFL. Remarques, coquilles
et compléments sont les biens venus.
INSTALLATION, CONFIGURATION ET UTILISATION DE SSH
=================================================
" ssh pour les nuls "
0) Hypothèses
-------------
RedHat Linux 7.1 sur PC sur toutes les machines. Installation via RPMs
binaires. Un environnement différent ne devrait rien changer, au pire il
faudra télécharger les sources et compiler.
1) Download
-----------
http://www.openssh.com/ -> For other OS's
ftp://sunsite.cnlab-switch.ch/pub/OpenBSD/OpenSSH/portable/rpm/
openssh-2.9.9p2-1.i386.rpm
openssh-clients-2.9.9p2-1.i386.rpm
openssh-server-2.9.9p2-1.i386.rpm
openssh-askpass-2.9.9p2-1.i386.rpm
openssh-askpass-gnome-2.9.9p2-1.i386.rpm
(éventuellement version plus récente)
2) Installer
-------------
2.1) la base (nécessaire)
rpm -Uvh openssh-2.9.9p2-1.i386.rpm
2.2) le serveur
rpm -Uvh openssh-server-2.9.9p2-1.i386.rpm
2.3) le client
rpm -Uvh openssh-clients-2.9.9p2-1.i386.rpm
3) Configurer le serveur (par root, tout est dans /etc/ssh)
------------------------
3.1) Générer les host keys :
ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N ""
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ""
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ""
La première est pour ssh1, les deux autres pour ssh2. Il y a toujours deux
fichiers, xxxx et xxxx.pub
Il n'est pas possible (ça n'aurait aucun sens) de les protéger par une
passphrase, d'où le -N ""
3.2) Regarder le fichier /etc/ssh/sshd.conf, en particulier mettre
X11Forwarding yes
3.3) Vérifier que le démon tourne
<root> [~] service sshd status
sshd (pid 478) is running...
<root> [~] service sshd restart
Shutting down sshd: [ OK ]
Starting sshd: [ OK ]
<root> [~] lsof -i | grep ssh
sshd 883 root 3u IPv4 1699 TCP *:ssh (LISTEN)
sshd n'utilise pas xinetd, ni tcpwrapper (/etc/hosts.{allow|deny})....
3.4) Vérifier qu'il est lancé au démarrage
<root> [~] chkconfig --list sshd
sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
4) Configurer le client (par chaque utilisateur, tout est dans ~/.ssh)
-----------------------
4.1) Regarder le fichier /etc/ssh/ssh.conf, en particulier mettre
ForwardX11 yes
Ceci définit la configuration par défaut de tous les clients sur une
machine donnée. Il est aussi possible de ne mettre ça que dans
~/.ssh/config
4.2) Générer les personal keys :
ssh-keygen -t rsa1 -f ~/.ssh/identity
ssh-keygen -t rsa -f ~/.ssh/id_rsa
ssh-keygen -t dsa -f ~/.ssh/id_dsa
La première est pour ssh1, les deux autres pour ssh2. Il y a toujours deux
fichiers, xxxx et xxxx.pub
Il est possible de les protéger par une passphrase qui devra être saisie à
chaque utilisation d'une s-commande. La saisie se fait
- de manière interactive, via stdin, au shell prompt (par défaut)
- via une fenêtre X11 ou Gnome, via la variable d'environnement
$SSH_ASKPASS, installer pour ça openssh-askpass et/ou
openssh-askpass-gnome et lire la partie sur SSH_ASKPASS dans man ssh
Ceci est utile pour ouvrir des fenêtres sur des serveurs distants
directement depuis un menu graphique, c-à-d sans shell prompt.
- via ssh-agent qui permet de n'entrer sa passphrase qu'une fois par
session, mais c'est plus compliqué.
Sans passphrase, quiconque ayant accès à votre ~/.ssh/ sur un de vos
comptes aura quasiment instantanément accès à tout vos autres comptes vers
lesquels vous aurez disséminé votre clé publique (cf ci-dessous). En outre,
à cause du fichier known_hosts, il saura où aller chercher ces comptes...
Les clés privés doivent donc impérativement être dans des fichiers lisibles
uniquement par l'utilisateur (mode 600), mais selon les cas, ce n'est pas
suffisant. C'est particulièrement dangereux lorsque votre $HOME est sur un
serveur de fichiers pas très bien protégé.
5) Connexion
------------
5.1) premiers tests : slogin [options] remoteuser@remotehost
Parmi les options les plus intéressantes, citons
-1 force l'utilisation de la version 1 du protocole
-2 force l'utilisation de la version 2 du protocole
-v -vv -vvv aide à voir ce qui ne marche pas
Lors de la première connexion depuis un compte donné sur une machine donnée
(le client) vers une nouvelle machine (le serveur), la host key (publique)
du serveur peut être transférée dans le fichier ~/.ssh/known_hosts resp.
~/.ssh/known_hosts2 pour que le serveur soit reconnu à l'avenir. Il n'est
pas nécessaire d'accepter cette clé, il est par contre prudent d'être
certain de la bonne transmission de cette clé. L'idéal (un peu utopique)
est de transférer cette clé par un autre moyen sécurisé _avant_ la première
connexion.
L'authentification se fait avec le mot de passe UNIX standard, comme pour
une r-commande, mais au moins le mot de passe est transféré crypté. Il est
cependant à la fois plus pratique et plus sûr d'utiliser l'authentification
basée sur les personal keys générées en 4.2 ci-dessus. Pour cela, il faut
copier la clé publique du protocole choisi ~/.ssh/*.pub du compte sur le
client vers le compte sur le serveur dans le fichier ~/.ssh/authorized_keys
resp. ~/.ssh/authorized_keys2. Attention là aussi à ce que cette diffusion
de clé soit faite de manière sécuriée.
5.2) Forwarding X11 : Si il a été configuré correctement, la variable
d'environnement $DISPLAY est mise automatiquement dans la session remote
(attention à ne pas la redéfinir (écraser) dans un fichier du genre .login,
.bashrc, .tcshrc ...). Elle ressemble souvent à une valeur du genre
client.toto.com:10.0 Cela permet au trafic X11 (ie programmes s'exécutent
sur le serveur mais s'affichant sur le client) d'utiliser un tunnel
sécurisé.
5.3) Le cas le plus fréquent : on veut mettre dans un menu d'une interface
graphique une entré qui ouvre depuis le client un shell sur le serveur. 2
solutions :
- xterm [options] -e slogin remoteuser@remotehost &
- ssh -f remoteuser@remotehost xterm [options]
En principe, la première est préférable, le xterm est local et ce sont les
IO au niveau du shell qui traversent le réseau via ssh. Mais la seconde qui
voit ssh ouvrir un tunnel X11 à travers lequel un xterm distant s'affiche
localement peut être utile dans certains cas, et s'applique telle quelle à
n'importe quel autre client X. L'option -f indique à ssh de passer en
arrière plan "au bon moment", c'est à dire _après_ avoir demandé la
passphrase.
6) Le reste...
--------------
ssh-agent, sftp, tunnels pour du POP ou autre, RTFM
--
___ _ ___ Jean-Albert FERREZ [EMAIL PROTECTED]
' / / \ \ EPFL - Chaire de Recherche Operationnelle - ROSO
,--/-/---\-\---------------------------------------------------------
\_/ / \ \ http://rosowww.epfl.ch/jaf/
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.
