Clé SSH Problème mise en place

Bonjour,

Suite à l’installation d’un système de supervision “centreon”, j’ai besoin de faire une connexion entre mes serveurs via une clé ssh, afin de ne pas mettre de mot de passe.

j’ai actuellement deux serveurs : (les ip ne sont que pour expliquer )
-Master : 1.1.1.1
-slave : 2.2.2.2

j’ai crée sur les deux serveurs le même utilisateur appelé "centreon"
le home du centreon est : /var/lib/centreon
le dossier .ssh : /var/lib/centreon/.ssh
chmod 700 sur .ssh et chmod 600 sur authorized_keys

etape 1 : je crée sur mon serveur1 (master ) avec le compte centreon un ssh-keygen
je ne remplie pas la passphrase car pas besoin dans mon cas je veux juste une connexion sans mot de passe donc sans passphrase également

etape2 : duplication de la clé sur le serveur2 (slave) :
ssh-copy-id -i ~/.ssh/id_dsa.pub centreon@2.2.2.2

[code]réponse :
Now try logging into the machine, with “ssh ‘centreon@2.2.2.2’”, and check in:

.ssh/authorized_keys

to make sure we haven’t added extra keys that you weren’t expecting.[/code]

est la sa ne fonctionne pas j’ai les erreurs suivantes :

ssh -vvv centreon@2.2.2.2 OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 2.2.2.2 [2.2.2.2] port 22. debug1: Connection established. debug1: identity file /var/spool/centreon/.ssh/identity type -1 debug3: Not a RSA1 key file /var/spool/centreon/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /var/spool/centreon/.ssh/id_rsa type 1 debug3: Not a RSA1 key file /var/spool/centreon/.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /var/spool/centreon/.ssh/id_dsa type 2 debug1: loaded 3 keys debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4 debug1: match: OpenSSH_6.0p1 Debian-4 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 126/256 debug2: bits set: 525/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /var/spool/centreon/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug3: check_host_in_hostfile: filename /var/spool/centreon/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug1: Host '2.2.2.2' is known and matches the RSA host key. debug1: Found key in /var/spool/centreon/.ssh/known_hosts:1 debug2: bits set: 502/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /var/spool/centreon/.ssh/identity ((nil)) debug2: key: /var/spool/centreon/.ssh/id_rsa (0x2ab355376ad0) debug2: key: /var/spool/centreon/.ssh/id_dsa (0x2ab355378350) debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /var/spool/centreon/.ssh/identity debug3: no such identity: /var/spool/centreon/.ssh/identity debug1: Offering public key: /var/spool/centreon/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password debug1: Offering public key: /var/spool/centreon/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password
Mon fichier sshd_config :

[code]

Package generated configuration file

See the sshd_config(5) manpage for details

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
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

Lifetime and size of ephemeral version 1 server key

KeyRegenerationInterval 3600
ServerKeyBits 768

Logging

SyslogFacility AUTH
LogLevel INFO

Authentication:

LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile ~/.ssh/authorized_keys
#AuthorizedKeyFile %h/.ssh/authorized_keys

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

Change to yes to enable challenge-response passwords (beware issues with

some PAM modules and threads)

ChallengeResponseAuthentication no

Change to no to disable tunnelled clear text passwords

#PasswordAuthentication yes

Kerberos options

#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

GSSAPI options

#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

Allow client to pass locale environment variables

AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

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 and

PasswordAuthentication. Depending on your PAM configuration,

PAM authentication via ChallengeResponseAuthentication may bypass

the setting of “PermitRootLogin without-password”.

If you just want the PAM account and session checks to run without

PAM authentication, then enable this but set PasswordAuthentication

and ChallengeResponseAuthentication to ‘no’.

UsePAM no[/code]

Merci pour votre retour

Bonne après midi
Cordialement,

Salut,

Première erreur.

Il te faut décommenter cette ligne en sshd_config :

Et lui indiquer le bon chemin.

Deuxième erreur.

La clé ne se situe pas au bon endroit !!

Redémarres les services de part et d’autre.

@BelZéButh : Attention, y’a pas de raison que tout le serveur soit centré sur l’utilisateur centreon, qu’est-ce qui se passe si norbert essaie de se connecter en ssh ?

[quote=“protec”]j’ai crée sur les deux serveurs le même utilisateur appelé “centreon”

le home du centreon est : /var/lib/centreon

le dossier .ssh : /var/lib/centreon/.ssh

chmod 700 sur .ssh et chmod 600 sur authorized_keys

etape 1 : je crée sur mon serveur1 (master ) avec le compte centreon un ssh-keygen

etape2 : duplication de la clé sur le serveur2 (slave) :

ssh-copy-id -i ~/.ssh/id_dsa.pub centreon@2.2.2.2
[/quote]

Où est le souci ? Si tenté …

* edit *

Norbert, Pierre, Paul, Jacques, n’étant pas les dépositaires de la dite clé => Connexion Refusé !

Tout à fait, mais oncques n’a pas besoin de spécifier où se trouve authorized_keys : si quelqu’un cherche à se connecter en tant que centreon sur la machine 2.2.2.2 par clef rsa, ça va chercher directement dans le fichier ~/.ssh/authorized_keys par défaut. Mais si ensuite c’est norbert qui veut se connecter, là ça pourrit tout si /var/lib/centreon/.ssh/authorized-keys n’est pas accessible par norbert (c’est ce que tu dis quand tu spécifies /var/lib/centreon/.ssh/authorized_keys directement dans le fichier /etc/ssh/sshd_config, qui est le fichier de conf’ général de SSH).

En tous cas, je dirais à vue de nez que le problème doit se trouver dans /var/lib/centreon/.ssh/config, ou que la clef SSH a été mal générée (moins probable). Ce n’est pas un problème de configuration générale de SSH, mais un problème spécifique à l’utilisateur centreon apparemment.

debug1: identity file /var/spool/centreon/.ssh/id_rsa type 1 debug3: Not a RSA1 key file /var/spool/centreon/.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype

Par ailleurs une recherche sur “debug3: Not a RSA1 key file” sur google me donne ceci : linuxquestions.org/questions … ue-659069/ (ils disent que ça a résolu le pb en mettant les bonnes infos dans le fichier ~/.ssh/config).

Quelques extraits.

[quote=“man ssh”]The file ~/.ssh/authorized_keys lists the public keys that are permitted for logging in. When the user logs in, the ssh program tells the server which key pair it would
like to use for authentication. The client proves that it has access to the private key and the server checks that the corresponding public key is authorized to accept
the account.

~/.ssh/
This directory is the default location for all user-specific configuration and authentication information. There is no general requirement to keep the entire
contents of this directory secret, but the recommended permissions are read/write/execute for the user, and not accessible by others.

 ~/.ssh/authorized_keys
         Lists the public keys (DSA/ECDSA/RSA) that can be used for logging in as this user.  The format of this file is described in the sshd(8) manual page.  This file
         is not highly sensitive, but the recommended permissions are read/write for the user, and not accessible by others.[/quote]

[quote=“man sshd”]AUTHORIZED_KEYS FILE FORMAT
AuthorizedKeysFile specifies the files containing public keys for public key authentication; if none is specified, the default is ~/.ssh/authorized_keys and
~/.ssh/authorized_keys2. Each line of the file contains one key (empty lines and lines starting with a ‘#’ are ignored as comments).
[/quote]

[quote]AuthorizedKeysFile .ssh/authorized_keys

Indique le chemin vers le fichier cntenant les clés autorisée pour l’authentification par clé publique.

Le chemin peut être absolu (de type /mon/chemin/fichier) ou relatif au home de l’utilisateur (c’est le cas si l’on met .ssh/authorized_keys qui est équivalent à /home/user1/.ssh/authorized_keys où user1 est un utilisateur).[/quote]

Bonsoir,

Merci à vous deux d’une part pour le script qui fonctionne très bien (testé sur une VM )
ensuite mon erreur, j’avais deja décommenté la ligne pour la vérification du fichier, cependant il ne pointé pas au bon endroit maintenant c’est 100% ok.

j’ai perdu pas mal de temps avec la CLé ssh mais sa fonctionne parfaitement un grand merci à tous