dmx44
Voilà j'ai l'habitude de faire des échanges de clés entre mes différents comptes linux pour éviter de retapper mes mots de passe à partir de ma machine ...
Mais là un compte fait de la résistance !!!
Donc sur ce compte distant j'ai bien rajouter ma clé publique RSA (et aussi DSA) dans authorized_keys
sur la meme machine j'ai 2 comptes
- root (j'arrive a me conncter sans devoir tapper le mot de passe, l'échange de clé = ok )
et
- flush (impossible ... je dois tjs tapper le mot de passe, alors que j'ai meme copier le fichier authorized_keys de root !)
voilà ma console vers flush :
[jp@naustradamus ~]$ ssh flush@xxx.xxx.15.140 -v
OpenSSH_4.3p2, OpenSSL 0.9.8a 11 Oct 2005
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to xxx.xxx.15.140 [xxx.xxx.15.140] port 22.
debug1: Connection established.
debug1: identity file /home/jp/.ssh/identity type -1
debug1: identity file /home/jp/.ssh/id_rsa type 1
debug1: identity file /home/jp/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.2
debug1: match: OpenSSH_4.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'xxx.xxx.15.140' is known and matches the RSA host key.
debug1: Found key in /home/jp/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/jp/.ssh/identity
debug1: Offering public key: /home/jp/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Offering public key: /home/jp/.ssh/id_dsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: password
flush@xxx.xxx.15.140's password:
Quelqu'un a une idée ?
:-?
Merci.
drpixel
J'en ai fait un tuto :
http://drpixel.tuxfamily.org/index.php?2006/07/09/10-ssh-authentification-par-cle
Vérifies bien les permissions du dossier $HOME/.ssh et des fichiers contenus dedans.
dmx44
Pareille 😢
Voilà mes fichiers de configuration :
ssh_config :
Host *
GSSAPIAuthentication yes
RSAAuthentication yes
IdentityFile ~/.ssh/id_rsa
StrictHostKeyChecking no
ForwardX11Trusted yes
sshd_config :
#Port 22
Protocol 2,1
#Protocol 2
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768
# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
MaxAuthTries 10
#RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
#PasswordAuthentication yes
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
#UsePAM no
UsePAM yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#ShowPatchLevel no
# no default banner path
#Banner /some/path
# override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server
drpixel
ll -d ~/.ssh
ll ~/.ssh
dmx44
Oui ca me donne bien 2 résultats différents mais je ne comprends pas ?
Clairement c'est un problème de répertoire ?
ici peut-être :
AuthorizedKeysFile .ssh/authorized_keys
?
J'ai essayé :
AuthorizedKeysFile ~/.ssh/authorized_keys
mais toujours le même souci ... ca ne change rien (mon root marche tjs et mon flush tjs pas !)
drpixel
Quel est le résultat des commandes ? Ton fichier de conf était bon remet le comme il était
dmx44
[flush@server ~]$ ll -d ~/.ssh
drwxr--r-- 2 flush webmasters 4,0K jui 12 21:25 /home/flush/.ssh
[flush@server ~]$ ll ~/.ssh
total 20K
-rw-r--r-- 1 flush webmasters 1021 jui 12 20:31 authorized_keys
-rw------- 1 flush webmasters 1,2K jui 12 20:53 id_dsa
-rw-r--r-- 1 flush webmasters 1,1K jui 12 20:53 id_dsa.pub
-rw------- 1 flush webmasters 1,7K jui 12 20:53 id_rsa
-rw-r--r-- 1 flush webmasters 393 jui 12 20:53 id_rsa.pub
[flush@server ~]$
Ca n'as pas l'air d'être un problème de droit ... j'ai vérifier comme sur ton blog ... répertoire en 700 fichiers, les clés privés en 600 les clés publiques en 644.
drpixel
C'est le fichier authorized_keys de root ? ou c'en est un autre ?
dmx44
J'ai essayez avec le même fichier que le root et avec un nouveau ... pareille !
Franchement je comprends rien !! Et la j'ai plus du tout d'accès ssh du coup ... alors que je suis à distance la grosse galère quoi ...
Anvil
Un repertoire 'r' et pas 'x' ca sert a rien. Mais passons. Verifie les permissions cote serveur du ~/.ssh/authorized_keys, du ~/.ssh/ et du ~/.
dmx44
Je pense pas que ca viennent d'un problème de droits, j'ai essayer de mettre les répertoires + fichiers en 777 (chmod 777 .ssh/ -R) côté serveur et côté client et pareille ...
Franchement j'ai fais cette opération une dizaine de fois déjà sans souci ! La je ne vois pas le souci ... je vais essayez avec un nouveau compte peut-être que mon compte a un souci ...
Anvil
Je pense pas que ca viennent d'un problème de droits, j'ai essayer de mettre les répertoires + fichiers en 777 (chmod 777 .ssh/ -R) côté serveur et côté client et pareille ...
Non mais tu reflechis a ce que tu fais ? C'est *exactement* pour ca que ca foire.
dmx44
Ha bon ? Trop de droits ca peux poser problème ? (a part au niveau sécurité ?)
Enfin avec les bons droits ou quelque chose rock n' roll ... rien 😢
Anvil
Evidemment que ca pose probleme. Non seulement c'est stupide de le faire dans 99.99999% des cas mais en plus, dans ce cas precis, tu demandes a un programme qui s'appelle ssh (Secure SHell quand meme) d'accepter le fait que n'importe qui puisse usurper l'identite du compte cote serveur et en autorisant tout le monde a poser sa cle publique dans l'authorized_keys, et en permettant a tout le monde recuperer ta cle privee.
Les bon droits c'est :
1. Les $HOME et les $HOME/.ssh : pas de `w' pour other et group
2. Les authorized_keys : pas de w pour pour other et group.
3. Les cles privees ne doivent etre lisible que par son proprietaire.
dmx44
Mes droits sont donc bon :
[flush@server ~]$ ll -d ~/.ssh
drwxr--r-- 2 flush webmasters 4,0K jui 12 21:25 /home/flush/.ssh
[flush@server ~]$ ll ~/.ssh
total 20K
-rw-r--r-- 1 flush webmasters 1021 jui 12 20:31 authorized_keys
-rw------- 1 flush webmasters 1,2K jui 12 20:53 id_dsa
-rw-r--r-- 1 flush webmasters 1,1K jui 12 20:53 id_dsa.pub
-rw------- 1 flush webmasters 1,7K jui 12 20:53 id_rsa
-rw-r--r-- 1 flush webmasters 393 jui 12 20:53 id_rsa.pub
[flush@server ~]$
Anvil
Quid des permissions sur le $HOME ?
dmx44
[flush@server home]$ ll -d $HOME
drwxr--r-- 3 flush webmasters 4,0K jui 12 20:52 /home/flush
chmod 744 sur mon répertoire $HOME
dmx44
c'est bon ca marche !!!
Le problème est alluciant, c'était bien un problème de droit :
[flush@lephp ~]$ ll .ssh/ -d
drwxr--r-- 2 flush webmasters 4,0K jui 12 22:38 .ssh/
[flush@lephp ~]$ chmod 700 .ssh/
740 ca marche pas, mais 700 ca marche !!! Merci pour tout !!!
drpixel
Mais c'était précisé sur le blog !? ^^
Il faut vérifier les droits sur les clés, ssh nécessite que le dossier .ssh ait les permissions 700 (rwx pour l'utilisateur, rien pour le groupe et les autres)
Le "problème" de droit est très bien expliqué par Anvil d'ailleurs.
dmx44
Entièrement d'accord 😉
C'est de ma faute ! Je pensais pas que un accès en lecture sur groupe pouvait tout changer !
