Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 02/03/2017, à 23:33

josran

[Résolu]Connexion SSH refusée malgré l'essai d'une solution conseillée

Bonjour,

Je ne peux plus accéder en SSH à mon serveur alors que j'avais réussi auparavant.

Cela commence comme ça :

└─ $ ▶ ssh tt@192.168.1.28
Permission denied (publickey).
tt @ ttx  ~

Je tente alors cette méthode suggérée précédememnt :

└─ $ ▶ unset SSH_AUTH_SOCK
tt @ ttx  ~
└─ $ ▶ ssh tt@192.168.1.28
Permission denied (publickey).
tt @ ttx  ~

Toujours guidé par un conseil précédent, j'effectue ce traçage :

└─ $ ▶ ssh -v tt@192.168.1.28
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 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.28 [192.168.1.28] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/tt/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tt/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tt/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tt/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tt/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tt/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tt/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tt/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.8p1-hpn14v6
debug1: match: OpenSSH_6.8p1-hpn14v6 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.1.28:22 as 'tt'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:7PXeS+4RITtlm+UDZh9heDCpYS6bUEcQbtl/B5O3Txs
debug1: Host '192.168.1.28' is known and matches the ECDSA host key.
debug1: Found key in /home/tt/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/tt/.ssh/id_rsa
debug1: Trying private key: /home/tt/.ssh/id_dsa
debug1: Trying private key: /home/tt/.ssh/id_ecdsa
debug1: Trying private key: /home/tt/.ssh/id_ed25519
debug1: No more authentication methods to try.
Permission denied (publickey).

Je vérifie que je n'ai pas de clé RSA :

tt @ ttx  ~/.ssh
└─ $ ▶ ls -al
total 12
drwx------  2 tt tt  4096 févr. 25 17:36 .
drwxr-xr-x 66 tt adm 4096 mars   3 01:50 ..
-rw-r--r--  1 tt tt   222 févr. 25 17:36 known_hosts

ainsi que si j'ai des hôtes connus :

tt @ ttx  ~/.ssh
└─ $ ▶ cat known_hosts
|1|KOvFKSCIo8RIbsl5b9bLkpLcfWM=|8dEu+JPAZYSMy7M8fb0L9lQal18= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNcDvnnvL765cE2OnltYOcyVQSZiYET/FrpYsTfW6tiSxK1+ImQSAjDs2vDpYwMFkOoOdTS9ff8A4rOcNJKaF44=

Je me résouds donc à générer des clés :

└─ $ ▶ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/tt/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/tt/.ssh/id_rsa.
Your public key has been saved in /home/tt/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:jAcRDBpxx7BfMv0Bqt2yFLMNv41cQvAJjCX8TXMbRAU tt@ttx
The key's randomart image is:
+---[RSA 2048]----+

Muni de mes clés, j'essaye en vain de les installer sur le serveur :

└─ $ ▶  ssh-copy-id -i /home/tt/.ssh/id_rsa.pub tt@192.168.1.28
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/tt/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
Permission denied (publickey).

Pourtant, elles sont là :

└─ $ ▶ ls .ssh/
id_rsa  id_rsa.pub  known_hosts

J'ai déjà réinstallé le système DSM 6.1 sur mon NAS, en vain. Je ne sais plus quoi faire.

Dernière modification par josran (Le 04/03/2017, à 12:18)

Hors ligne

#2 Le 03/03/2017, à 09:24

bruno

Re : [Résolu]Connexion SSH refusée malgré l'essai d'une solution conseillée

Bonjour,

Je ne suis pas sur d'avoir tout bien suivi, mais de ce que je vois :
- ton serveur n’accepte que les connexions par clés ;
- avant de (re)générer tes clés tu n'avais pas de clé dans ~/.ssh sur le client ce qui rendait la connexion impossible ;
- enfin tu tentes de copier ta clé publique sur le serveur alors que l'accès SSH ne fonctionne pas…

Si tu veux que cela fonctionne il faut reconfigurer le serveur pour qu'il accepte aussi les connexion par mot de passe. Ensuite tu pourras y copier ta clé publique et enfin tenter une connexion par clés. Si cela fonctionne tu pourra configurer le serveur pour qu'il n'accepte plus les connexion par mot de passe.

Hors ligne

#3 Le 03/03/2017, à 12:17

josran

Re : [Résolu]Connexion SSH refusée malgré l'essai d'une solution conseillée

Bonjour,

C'est aussi la solution à laquelle je pense.

Le problème est que, pour modifier le fichier sshd_config sur le serveur, je suis obligé de me connecter en tant qu'utilisateur root et, avec le logiciel DSM 6.1 qui tourne sur le serveur, je ne peux me connecter en tant qu'utilisateur root que par le biais de SSH : que ce soit par PuTTY client aussi bien qu'en lançant SSH au terminal, je suis bloqué.

Par ailleurs, quand je lance Xubuntu en live, je suis bloqué de la même façon et quand je réinitialise DSM 6.1 sur le serveur, c'est exactement pareil; or, je n'ai pas envie de faire un RAZ complet sur le serveur vu le temps que j'ai passé à le configurer et que j'y perdrais obligatoirement des données.

Merci de m'avoir lu.

Hors ligne

#4 Le 03/03/2017, à 14:07

bruno

Re : [Résolu]Connexion SSH refusée malgré l'essai d'une solution conseillée

Autrement dit, tu as fermé la porte à clé et tu as jeté les clés par la fenêtre … wink
Il faut que tu regardes dans la doc de DSM s'il y a un autre moyen d'avoir un accès root à ton système.

Hors ligne

#5 Le 03/03/2017, à 15:38

wido

Re : [Résolu]Connexion SSH refusée malgré l'essai d'une solution conseillée

Bonjour,
tu peux te connecter en root en ftp?

Hors ligne

#6 Le 03/03/2017, à 17:46

josran

Re : [Résolu]Connexion SSH refusée malgré l'essai d'une solution conseillée

Bonjour,

Je ne l'ai jamais fait mais d'après ce que j'ai lu, il faut préalablement avoir eu accès au serveur pour modifier ses fichiers de configuration.

Or, mon problème est précisément que je ne peux pas accéder au serveur et avec aucun identifiant utilisateur quel qu'il soit.

Je vais regarder du côté de PuTTY dans l'idée de me glisser par ce biais vers les fichiers de configuration du serveur que j'ai mal renseignés au départ et de les corriger afin de ne plus être bloqué.

Dernière modification par josran (Le 03/03/2017, à 17:47)

Hors ligne

#7 Le 04/03/2017, à 12:24

josran

Re : [Résolu]Connexion SSH refusée malgré l'essai d'une solution conseillée

Bonjour,

J'ai résolu mon problème en me connectant au serveur par Telnet en tant qu'utilisateur root, ce qui m'a permis d'aller corriger le fichier de configuration sshd_config.

Ainsi, je peux de nouveau me connecter en root par SSH :

└─ $ ▶ ssh root@192.168.1.28
root@192.168.1.28's password: 
root@Syntt:~# exit
logout
Connection to 192.168.1.28 closed.

Merci à tous ceux qui ont pris le temps de se pencher dessus.

Hors ligne