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.
