[Aide Connexion ssh Clé Rsa]

spectre59 · le 26 septembre 2016

Bonjour a tous et à toutes .

Je crée ce post afin de bénéficier de votre aide sur la configuration ssh avec clé rsa sur un synology .

je vous explique la manipulation déja faite pour ma part :

1)j'ai activer le service ssh dans le panneau de configuration .

2)je me suis connecté en ssh afin de me rendre dans le homes/admin pour ajouter au fichier authorized_key la clé rsa du poste qui doit se connecté en ssh.

3)j'ai également modifier le fichier /etc/ssh/sshd_config afin de le configurer comme ceci :

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

4)J'ai modifié les droit d’accès au fichier suivant :

chmod 755 /volume1/homes/admin
chmod 700 /volume1/homes/admin/.ssh
chmod 644 /volume1/homes/admin/.ssh/authorized_keys

Mon problème est que quand je me connecte en ssh depuis le poste en question et le bon compte (admin par exemple).

j ai'toujours la demande de mot de passe.

Merci de votre aide par avance .

Modifié le 27 septembre 2016 par spectre59

lordtaki · le 26 septembre 2016

Pour commencer, je suggère de passer en mode verbeux le client ssh utilisé sur le poste (sur linux en ligne de commande c'est l'option -v).

spectre59 · le 26 septembre 2016

Je suis passer en mode verbeux y a t il une ligne importante que vous souhaitez savoir ?

Modifié le 26 septembre 2016 par spectre59

lordtaki · le 26 septembre 2016

Autant ne pas trier si c'est du chinois pour vous :)

On fera le tri.

CoolRaoul · le 26 septembre 2016

L'étape 3 est inutile déjà (ce sont les valeurs par défaut que tu as ajouté)

Sinon jette un oeil dans /var/log/messages (grep sshd /var/log/messages | tail ) tu pourrais y trouver des pistes

spectre59 · le 27 septembre 2016

j ai un log qui reviens souvent :

Aug 26 01:43:28 Synology kernel: [4965686.600722] init: sshd main process (15720) terminated with status 255

Pour être franc je début sous shell linux .(soyé indulgent de mon ignorance )

Pour information l'étape 3 décrite au premier post j ai juste décommenté les champs existant du fichier .

CoolRaoul · le 27 septembre 2016

Il y a 2 heures, spectre59 a dit :

j ai un log qui reviens souvent :

Aug 26 01:43:28 Synology kernel: [4965686.600722] init: sshd main process (15720) terminated with status 255

C'est malheureusement insuffisant comme information. Ca indique souvent une erreur de syntaxe dans sshd_config, mais vu que la connection par mot de passe fonctionne, l'explication doit être ailleurs.

Il y a 2 heures, spectre59 a dit :

Pour information l'étape 3 décrite au premier post j ai juste décommenté les champs existant du fichier

C'est bien ce que j'imaginais et je confirme que c'est inutile: traditionnellement les paramétes en commentaires dans sshd_config sont précisément là pour illustrer les valeurs par défaut.

Modifié le 27 septembre 2016 par CoolRaoul

spectre59 · le 27 septembre 2016

Citation

OpenSSH_6.7p1 Debian-5+deb8u2, OpenSSL 1.0.1t 3 May 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.1.204 [192.168.1.204] port 22.
debug1: Connection established.
debug1: identity file /home/spectre59/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/spectre59/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/spectre59/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/spectre59/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/spectre59/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/spectre59/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/spectre59/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/spectre59/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.8p1-hpn14v6
debug1: match: OpenSSH_6.8p1-hpn14v6 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr umac-128-etm@openssh.com none
debug1: kex: client->server aes128-ctr umac-128-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 00:07:0a:51:62:66:c0:17:3c:00:80:f2:66:68:fb:f4
debug1: Host '192.168.1.204' is known and matches the ECDSA host key.
debug1: Found key in /home/spectre59/.ssh/known_hosts:1
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,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/spectre59/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/spectre59/.ssh/id_dsa
debug1: Trying private key: /home/spectre59/.ssh/id_ecdsa
debug1: Trying private key: /home/spectre59/.ssh/id_ed25519
debug1: Next authentication method: password

Voila le mode verbeux lors de la connection ssh

CoolRaoul · le 27 septembre 2016

Les logs coté client n'aideront pas des masses.

Rien d'intéressant trouvé dans /var/log/messages sinon ?

spectre59 · le 27 septembre 2016

malheureusement non . j ai copier la ligne de commande que vous m 'avez indiqué; au pire je vous post les logs demain

Fenrir · le 27 septembre 2016

Le 26/09/2016 à 10:17, spectre59 a dit :

/volume1/homes/admin

=>

/var/services/homes/admin

spectre59 · le 27 septembre 2016

J ai pas compris fenrir .

j'ai pas mis les bon droit au bon fichier ?

Fenrir · le 27 septembre 2016

ba si tu as compris :biggrin:

Les "vrais" homes des utilisateurs sont déclarés dans /etc/passwd. Par défaut sur un syno, ils sont dans /var/services/homes (sauf pour root qui est à sa place, dans /root).

lordtaki · le 28 septembre 2016

Sur le poste client (donc pas le NAS):

ls -al /home/spectre59/.ssh/

Je n'ai pas l'impression que ta clé privée soit détectée.

spectre59 · le 28 septembre 2016

Pourtant il y a bien 2 fichier présent dans le dossier /home/spectre59/.ssh le id_rsa et le id_rsa.pub (dans lequel j ai la clé public) (pour votre information le poste spectre59 est sous debian )

Modifié le 28 septembre 2016 par spectre59

CoolRaoul · le 28 septembre 2016

Il y a 4 heures, lordtaki a dit :

Je n'ai pas l'impression que ta clé privée soit détectée.

Non: les deux lignes suivantes du log client :

debug1: identity file /home/spectre59/.ssh/id_rsa type 1
/../
debug1: Offering RSA public key: /home/spectre59/.ssh/id_rsa

montrent bien au contraire que la clé id_rsa ("/home/spectre59/.ssh/id_rsa") est effectivement lue par le client ssh

Modifié le 28 septembre 2016 par CoolRaoul

loli71 · le 28 septembre 2016

Le lundi 26 septembre 2016 à 10:17, spectre59 a dit :

chmod 644 /volume1/homes/admin/.ssh/authorized_keys

Personnellement, moi j'ai fait plutôt un chmod 600 sur le fichier authorized_keys, je ne sais pas si cela change quelque chose ou pas.

Je suis encore en DSM5, et depuis que syno a enlever les logs de connection ssh du /var/log/message, j'ai mis en place les modifications suivantes pour avoir à nouveau les logs ssh (qui pourraient peut être te montrer le problème) :

1) Créer en tant que root le fichier /usr/local/etc/syslog-ng/patterndb.d/sshd.conf comme suit :

filter f_messages {
        level(info..emerg)
        and not facility( mail, news, cron)
        and not program(syslog-ng)
        and not filter(f_local)
        and not filter(f_synology);
};

2) Faire un chmod 644 sur le fichier /usr/local/etc/syslog-ng/patterndb.d/sshd.conf créé

3) Relancer le syslog pour prise en compte du fichier, sous DSM5 c'est la commande suivante (sinon un reboot du syno) :

synoservicecfg --restart syslog-acc

En espérant que cela t'aidera

spectre59 · le 28 septembre 2016

Bon j' activer les nouveaux droits sur le dossier /var/services/homes/admin ; j ai relancé le service ssh toujours pareil demande de mot de passe .

Je me dit je vais lancer la connexion ssh en root sur le poste spectre59 et la surprise ... un jolie message comme celui-ci

Citation

The authenticity of host 'amraam (192.168.XXX.XXX)' can't be established. RSA key fingerprint is c6:ee:c6:e4:9a:b6:7e:46:4c:17:b4:d0:7b:80:af:2c.

Are you sure you want to continue connecting (yes/no)?

Je fais yes ....

autre message

Citation

Warning: Permanently added 'amraam' (RSA) to the list of known hosts.

et la BING ....... demande de mot de passe .

CoolRaoul · le 28 septembre 2016

Le 9/28/2016 à 14:00, loli71 a dit :

Je suis encore en DSM5, et depuis que syno a enlever les logs de connection ssh du /var/log/message, j'ai mis en place les modifications suivantes pour avoir à nouveau les logs ssh (qui pourraient peut être te montrer le problème) :

C'est vrai que j'oublie parfois que si j'ai les logs ssh dans syslog c'est grâce à cette astuce que j'ai appliquée depuis 2013 (ref) et je conclue un peu rapidement que tout le monde les a aussi.

Avec ces modifs on devrait trouver l'explication je pense

Le 9/28/2016 à 14:24, spectre59 a dit :

Je me dit je vais lancer la connexion ssh en root sur le poste spectre59 et la surprise ... un jolie message comme celui-ci

ce message indique juste que c'est la première fois que le compte root de spectr59 se connecte au NAS,

Modifié le 30 septembre 2016 par CoolRaoul

spectre59 · le 28 septembre 2016

oui je te l accorde mais je me souviens pas avoir eu ce même message en temps que users

CoolRaoul · le 28 septembre 2016

Tu as du oublier ou pas faire gaffe. Enfin, bref, c'est anecdotique

Le principal est maintenant que tu appliques la modif de conf syslog qui t'a été suggérée pour avancer dans le diagnostic.

Fenrir · le 28 septembre 2016

Plutôt que de le faire à la main et de rater un truc (chemin/droits/copie/...) : ssh-copy-id -i /chemin/vers/ta/clef login@serveur

spectre59 · le 29 septembre 2016

j'ai fait la modification pour voir les logs je ferai un test demain et je reviendrai vers vous .

spectre59 · le 18 octobre 2016

Bonjour à tous désolé pour ma longue absence . J 'ai activé les log comme indique et redémarré le service .

Dans les logs (centre des journeaux je voit rien de particulier) .

Modifié le 18 octobre 2016 par spectre59

PierU · le 17 décembre 2018

Bonjour,

Je me greffe sur ce sujet, car j'ai exactement le même souci. A-t'il a été résolu de votre côté depuis ?

J'ai décommenté les lignes suivantes dans /etc/ssh/sshd_config (ce qui n'est sans doute pas utile vu que ce sont les valeurs par défaut) :

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

J'ai copié ma clef publique dans .authorized_keys côté NAS, fait un chmod 755 sur le home de l'utilisateur, et un chmod 600 sur le .ssh/ et sur le .ssh/authorized_keys. Et il me demande toujours le mot de passe.

Connexion

[Aide Connexion ssh Clé Rsa]

Messages recommandés

spectre59

lordtaki

spectre59

lordtaki

CoolRaoul

spectre59

CoolRaoul

spectre59

CoolRaoul

spectre59

Fenrir

spectre59

Fenrir

lordtaki

spectre59

CoolRaoul

loli71

spectre59

CoolRaoul

spectre59

CoolRaoul

Fenrir

spectre59

spectre59

PierU

Rejoindre la conversation

Qui est en ligne 6 membres, 0 anonyme, 333 invités (Afficher la liste complète)

Contributeurs populaires

Forum

Discussions

Articles

Information importante