This site uses cookies! Learn More

Ce site utilise des cookies !

En continuant à utiliser ce site, vous vous engagez à nous permettre de stocker des cookies sur votre ordinateur.

 

Si nous utilisons des cookies et retenons des données anonymes, c’est pour nous aider à mieux gérer notre mesure d’audience, aider nos partenaires commerciaux à nous rémunérer et nos partenaires publicitaires à proposer des annonces qui vous correspondent.

 

Grâce à ces cookies, le forum est en mesure de savoir qui écrit un message et utile pour le système d'authentification.

 

En cliquant sur « J'accepte », vous acceptez l'utilisation par NAS-Forum de cookies publicitaires et de mesure d'audience fine.

spectre59

[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

Partager ce message


Lien à poster
Partager sur d’autres sites

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 

Partager ce message


Lien à poster
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 .
 

Partager ce message


Lien à poster
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

Partager ce message


Lien à poster
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 

Partager ce message


Lien à poster
Partager sur d’autres sites

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).

Partager ce message


Lien à poster
Partager sur d’autres sites

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é par spectre59

Partager ce message


Lien à poster
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

Partager ce message


Lien à poster
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

Partager ce message


Lien à poster
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 .

 

Partager ce message


Lien à poster
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

Partager ce message


Lien à poster
Partager sur d’autres sites

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.

Partager ce message


Lien à poster
Partager sur d’autres sites

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é par spectre59

Partager ce message


Lien à poster
Partager sur d’autres sites

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.

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

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.