[Aide Connexion ssh Clé Rsa]

[spectre59]

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]

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]

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]

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

On fera le tri.

[CoolRaoul]

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]

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]

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]

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]

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

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

[spectre59]

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

[Fenrir]

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

/volume1/homes/admin

=>

/var/services/homes/admin

[spectre59]

J ai pas compris fenrir . 

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

[Fenrir]

ba si tu as compris

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]

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]

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]

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 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]

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 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]

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

 

[CoolRaoul]

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]

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]

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

[spectre59]

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]

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.