Aller au contenu

[Aide Connexion ssh Clé Rsa]


Messages recommandés

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é par spectre59
Lien vers le commentaire
Partager sur d’autres sites

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 .
 

Lien vers le commentaire
Partager sur d’autres sites

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é par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

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 

Lien vers le commentaire
Partager sur d’autres sites

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é par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

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

Lien vers le commentaire
Partager sur d’autres sites

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 .

 

Lien vers le commentaire
Partager sur d’autres sites

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é par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

  • 3 semaines après...
  • 2 ans après...

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.

 

Lien vers le commentaire
Partager sur d’autres sites

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.