Après avoir tapé 231 fois le mot de passe, on en a marre surtout si le nom de la machine est nomtreslong.lichtenstein.loin et le login bouvardetpecuchet.flaubert
On souhaiterait faire directement
ssh labas
Fabrication des clefs:
Faire
$ ssh-keygen -t dsa
Lui donner un nom par exemple labas:
Enter file in which to save the key (/home/francois/.ssh/id_dsa): ~/.ssh/labas
Taper pour les passphrases.
Configuration de ssh
Editer le fichier ~/.ssh/config et rajouter
Host labas
HostName nomtreslong.lichtenstein.loin
User bouvardetpecuchet.flaubert
PasswordAuthentication no
IdentityFile ~/.ssh/labas
Sur la machine nomtreslong.lichtenstein.loin
rajouter à la fin du fichier ~/.ssh/authorized_keys le contenu du fichier ~/.ssh/labas.pub qui a été crée sur votre machine. Ce fichier est du texte pur et un copier/coller suffit. Changer les droits de ~/.ssh/authorized_keys en 600 (ou 644 qui marche aussi)
Essai
Pour se connecter sur la machine voulue, au lieu de
Ça ne marche pas, il demande les mots de passes: Vérfier que les droits de ~/.ssh/authorized_keys soit rw-------, sinon la reconnaissance par clefs est désactivée. Eventuellement regarder la configuration de /etc/ssh/sshd_config sur nomtreslong.lichtenstein.loin. Elle est peut être exotique et exige quoiqu’il arrive la reconnaissance par mot de passe. Il doit y avoir l’option
Ça m’a l’air très pratique, en effet mais question :
est-ce qu’il faut taper mot à mot le code indiqué (en dehors des noms d’user, etc;), y-compris les tildes ‘~’ ou ces derniers représente un chemin ?
~ represente le home de l’user en cours. Par exemple, ~ en tant que ricardo signifie /home/ricardo.
~ signifie “le home de tel user”. Par exemple ~root signifie /root (quel que soit l’user en cours dans cette deuxiême notation).
J’ai un probleme:
J’ai crée la clé avec la premiere commande, dans dup (un ~/.ssh/dup ne passe pas: no such file or directory, même avec mkdir ~/.ssh/dup)
Donc j’ai édité le fichier config dans .ssh, avec mes hosts etc …
Là mon fichier authorized_keys était vide ( ), donc j’ai directement copié le dup.pub vers /.ssh/authorized_keys, puis un chmod600.
Et à la fin je me delogue, je fais ssh dup, et j’ai un connexion time out. En direct c’est ok
Je pense que le blem est au niveau du authorized_keys, mais je suis pas sur.
Quelqun at-til rencontré ce probleme ?
Cldt dupdup17.
EDIT: probleme réglé. Je pense que c’etait du a une inversion de host et hostname. J’ai mis les mêmes, ca tourne.
Bon j’ai essayer la manip et sa marche pas il me demande le password ?
serveur: 192.168.1.64
client : 192.168.1.65
Donc sur le client je me suis placer dans /home/user/.ssh
pour faire le ssh-keygen -t dsa
on obtiens 2 fichier.
je cree le fichier /home/user/.ssh/.config
Host p
HostName 192.168.1.64
User userserveur
PasswordAuthentication no
IdentityFile ~/.ssh/p
Sure le serveur je par a la recherche du fichier
je fait un find / -iname authorized_keys qui me renvoiye rien …
bon je tente de crée un fichier vide dans /home/userserveur/.ssh/authorized_keys
dans le qu’elle je colle le contenu complet du fichier xxx.pub obtenu sure la machine cliente (avec ssh-keygen -t dsa)
j’ouvre un terminal sur la machine cliente et:
Donc je supose que la clef va ailleurs mai ou ?
PubkeyAuthentication yes ce trouve bien dans le fichier de configuration sure le serveur
[quote][b]3) Sur la machine nomtreslong.lichtenstein.loin
rajouter à la fin du fichier ~/.ssh/authorized_keys le contenu du fichier ~/.ssh/labas.pub qui a été crée sur votre machine. Ce fichier est du texte pur et un copier/coller suffit. Changer les droits de ~/.ssh/authorized_keys en 600 (ou 644 qui marche aussi)[/b]
[/quote]
Si le fichier n’existe pas tu le crées. Où? Ben dans ton répertoire ~/ssh sur le serveur.
hello
J’ai carrément effacer ce qu’il y avait dans le /home/user/.ssh des deux machine: note sur le serveur il n’y avait pas de répertoire .ssh.
j’ai donc copier le fichier p.pub sur le serveur que j’ai renommer en authorized_keys dans le répertoire /home/userserveur/.ssh histoir d’exclure tout erreur de manip qui fausserai la clef.
profiter pour relancer le serveur ssh (des foit que)
Sure la machine cliente j’ai constater qu’un fichier du nom de known_hosts qui contiens la clef envoyée par le serveur l’or de la première connections ou il pose la question
Le fichier sshd_config
ssh p
The authenticity of host '192.168.1.64 (192.168.1.64)' can't be established.
RSA key fingerprint is XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:censurer:XX:XX:XX:XX.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.64' (RSA) to the list of known hosts.
Password:
Linux pmch 2.6.18-5-k7 #1 SMP Wed Oct 3 00:47:27 UTC 2007 i686
voici les fichier de config :
# Package generated configuration file
# See the sshd(8) manpage for defails
# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# ...but breaks Pam auth via kbdint, so we have to turn it off
# Use PAM authentication via keyboard-interactive so PAM modules can
# properly interface with the user (off due to PrivSep)
#PAMAuthenticationViaKbdInt no
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768
# Logging
SyslogFacility AUTH
LogLevel INFO
# Authentication:
LoginGraceTime 600
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
# rhosts authentication should not be used
#RhostsAuthentication no
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Uncomment to disable s/key passwords
#ChallengeResponseAuthentication no
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
# To change Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no
# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes
X11Forwarding no
X11DisplayOffset 10
PrintMotd no
#PrintLastLog no
KeepAlive yes
#UseLogin no
#MaxStartups 10:30:60
#Banner /etc/issue.net
#ReverseMappingCheck yes
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes
Le fichier ssh_config
# This is the ssh client system-wide configuration file. See
# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.
# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.
# Site-wide defaults for some commonly used options. For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.
Host *
# ForwardAgent no
# ForwardX11 no
# ForwardX11Trusted yes
# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# Port 22
# Protocol 2,1
# Cipher 3des
# Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
Qu’as tu dans ton répertoire .ssh sur la machine serveur ET sur la machine client (fais un ls -al)[quote]Pour être exact en fait, «forward» indique le relais et lo = interface loopback donc l’ordinateur lui même. Cette règle accepte de relayer une connexion venant de l’ordinateur lui même.[/quote]
ls -la /home/user/.ssh/
total 12
drw-r--r-- 2 user user 4096 2007-12-09 21:32 .
drwx------ 26 user user 4096 2007-12-10 14:18 ..
-rw-r--r-- 1 user user 597 2007-12-09 21:29 authorized_keys
Client
ls -la .ssh
total 24
drwx------ 2 user user 4096 2007-12-09 22:35 .
drwxr-xr-x 65 user user 4096 2007-12-10 21:42 ..
-rw-r--r-- 1 user user 86 2007-12-09 10:25 config
-rw-r--r-- 1 user user 442 2007-12-09 22:35 known_hosts
-rw------- 1 user user 672 2007-12-09 22:28 p
-rw-r--r-- 1 user user 597 2007-12-09 22:28 p.pub
Note j’ai remplacer le véritable nom de l’utilisateur par user!
), donc j’ai directement copié le dup.pub vers /.ssh/authorized_keys, puis un chmod600.
