Connection refused  [RESOLU]

Votre Apache se cache, votre Pi gémit, votre SoC fume ? La panne quoi ! C'est ici que vous trouverez sans doute une solution... Sinon du réconfort :)

Modérateurs : Francois, maxty01

marseillois
Messages : 61
Enregistré le : ven. 10 juin 2016 14:18

Re: Connection refused

Message par marseillois » mer. 27 mars 2019 16:40

Bonjour & Merci à tous

domi a écrit :
Si tu fais sur le Rpi un :
sudo netstat -anp | grep sshd
Peux tu donner le résultat afin de vérifier que le Rpi écoute bien sur l'IP et sur le port 22 en ipv4.

Pour ôter toute doute, il n'y a pas de Firewall installé sur le Rpi ?
Le résultat :

Code : Tout sélectionner

pi@raspberrypi:~$ sudo netstat anp | grep sshd
tcp	0	0  0.0.0.0:28841		0.0.0.0:*	LISTEN
437/sshd
tcp6	0	: : :28841			: : :*		LISTEN
437/sshd
Unix 3		[ ]         STREAM     CONNECTE         11896	437/sshd
[/quote]
A noter qu’à un 2eme essai 1186 est devenu 11645 et 437 est devenu 403??

Contrairement à ce dont j'étais persuadé c’est le port 28841 qui est cité dans le netstat ci dessus

Je pense que l’anomalie vient du fait que le port d’appel n’est pas le même les sur fichiers de config respectifs du client et du serveur. Je corrige donc celui du serveur en 22 et je relance : 

[code]gerard@gerard-L50:~$ ssh -v pi@192.168.1.87
OpenSSH_7.4p1 Debian-10+deb9u6, OpenSSL 1.0.2r  26 Feb 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.1.87 [192.168.1.87] port 22.
debug1: Connection established.
debug1: identity file /home/gerard/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gerard/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gerard/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gerard/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gerard/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gerard/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gerard/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gerard/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u6
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Raspbian-10+deb9u6
debug1: match: OpenSSH_7.4p1 Raspbian-10+deb9u6 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.1.87:22 as 'pi'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
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:XeiaygTtIdpimaTRV0JWpAt39aKI6azXaqtjTnlaL+A
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:XeiaygTtIdpimaTRV0JWpAt39aKI6azXaqtjTnlaL+A.
Please contact your system administrator.
Add correct host key in /home/gerard/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/gerard/.ssh/known_hosts:4
  remove with:
  ssh-keygen -f "/home/gerard/.ssh/known_hosts" -R 192.168.1.87
ECDSA host key for 192.168.1.87 has changed and you have requested strict checking.
Host key verification failed.
gerard@gerard-L50:~$ 
La connexion s’établit bien mais, malgré mes difficultés avec l’anglais je crois comprendre que la difficulté vient des clefs et que la procédure demande la suppression des 4 clefs existant chez le client

Dans cette hypothèse le fichier du client sera vide, ce qui suppose que je vais devoir reprendre la création des clefs depuis le début Exact ???

Dois-je aussi vider le fichier known_hosts du serveur au préalable ??? ou le fichier authorized_keys

Enfin, dernière question :
Pour répondre à ta demande j’ai travaillé à l’écran de ma TV , directement sur le rasp,
Malgré l’utilisation de sudo aucun mot de passe n’a été sollicité : pourtant j’ai bien créé un mot de passe utilisateur qui aurait du être demandé pour sudo ??
Aurais tu une idée à suggérer pour comprendre ce qu'il se passe ??

Pour info suite aux propositions d’artemus24 j’ai modifié les permissions sur le serveur
sudo chmod 700 ~/.ssh
sudo chmod 400 ~/.ssh/authorized_keys
Nouvelle occasion de constater que j’accède sans mot de passe ???

Merci & à+

marseillois
Messages : 61
Enregistré le : ven. 10 juin 2016 14:18

Re: Connection refused

Message par marseillois » mer. 27 mars 2019 17:07

Bonjour artemus24 et merci pour tes suggestions

artemus24 a écrit :
1 /
vous devez créer vos clefs en utilisant Putty.
Il existe un utilitaire qui se nomme "puttygen.exe"
Je vous laisse chercher sur le net comment l'utiliser.

A l'issu de cela, vous aurez trois fichiers, qui sont :
--> "public_key",
--> "private_key.ppk",
--> "authorized_keys".
Mon Résultat :
J’ai bien un fichier ~/.ssh/authorized_keys sur le serveur et un fichier id_rsa (pour la clef privée) et id_rsa_pub (pour la clef publique sur le client), placés par défaut dans le fichier ~/.ssh du satellite lors de la création des clefs
Ce qui remplit les conditions 2/ & 3/ que tu proposes, conformément à la procédure linux qui diffère de celle de Windows/putty

Artemus24 a écrit :

Code : Tout sélectionner

4/ Vous devez ensuite attribuer les droits :
--> pour le répertoire "chmod 700 .ssh".
--> pour le fichier "chmod 400 authorized_keys".
sans les droits, votre connexion peut-être rejetée.
Résultat :

Code : Tout sélectionner

sudo chmod 700 ~/.ssh
sudo chmod 400 ~/.ssh/authorized_keys
Nouvelle occasion de constater que j’accède sans mot de passe ???, mais les permissions sont conformes à la proposition

artemus24 a écrit :
6 / dans l'émetteur, vous devez placer votre fichier "Private_key.ppk" de manière à ce qu'il soit bien sécurisé.
a / ne changez pas le port 22. Si votre connexion est sécurisée, cela ne sert à rien.
Je ne comprends pas, je croyais que mot de passe ou passphrase (que j’ai privilégiée) était justement destinés à sécuriser la connexion

Comme tu peux le lire dans ma réponse à domi ci dessus, si j'ai bien trouvé la source de l'erreur sur la connexion, mes pbs sont loin d'être résolus mais je voudrais conserver la liaison par ssh avec une passphrase

Merci encore et à+

domi
Administrateur
Messages : 2838
Enregistré le : mer. 17 sept. 2014 18:12
Localisation : Seine et Marne

Re: Connection refused

Message par domi » mer. 27 mars 2019 18:51

Bonjour,

Les numéros qui ont changés sont du au fait que tu as du redémarrer le Pi ou le daemon sshd. En fait c'est son ID.

Ce que je ne comprend pas, c'est que dans le "/etc/ssh/sshd_config" du Rpi que tu donnes un peu plus haut, le port d'écoute est celui par défaut, le 22.
Le netstat nous informe que le Pi écoute sur le 28841.
La j'en perd mon latin !!!!
Ou on se comprend mal dans les fichiers :(

Pour le problème de clé, c'est pas grave, on verra plus tard, dans l’immédiat il pourra juste râler que la clé n'est pas valide, mais on devrait au moins arriver à la demande de mot de passe.
Avant de modifier le fichier "/etc/ssh/ssh_config" du Rpi, as tu conservé une copie de l'original ?
Passionné de Raspberry, Arduino, ESP8266, ESP32, et objets connectés :
Spécial débutant, concevez vous-même votre domotique DIY : https://www.youtube.com/c/DomoticDIY

domi
Administrateur
Messages : 2838
Enregistré le : mer. 17 sept. 2014 18:12
Localisation : Seine et Marne

Re: Connection refused

Message par domi » mer. 27 mars 2019 18:57

Je n'avais pas déroulé tous le message qui est dans la balise code.

Lors de la tentative de connexion, tu as toujours le message

Code : Tout sélectionner

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Si oui, il faut que tu fasses sur "gerard" :

Code : Tout sélectionner

ssh-keygen -f "/home/gerard/.ssh/known_hosts" -R 192.168.1.87
car il a encore une ancienne empreinte de la connexion, qui semble avoir changée.
Puis retenter une connexion.
Passionné de Raspberry, Arduino, ESP8266, ESP32, et objets connectés :
Spécial débutant, concevez vous-même votre domotique DIY : https://www.youtube.com/c/DomoticDIY

marseillois
Messages : 61
Enregistré le : ven. 10 juin 2016 14:18

Re: Connection refused

Message par marseillois » mer. 27 mars 2019 19:28

Salut domi

1 / le fichier “au dessus” est erroné et je m’en excuse : je croyais avoir mis là le fichier avec le port 28841, avec lequel j’ai travaillé un moment
Je m’en suis rendu compte en allant interroger ce fichier sur le rasp à l’écran TV et j’ai donc corrigé le port en 22 pour rétablir la cohérence, ce qui m’a permis d’obtenir la connexion non abouitie à cause du problème de clefs

2 / Qu’appelles tu le fichier original, le fichier à la création des clefs : la réponse serait oui. Il faut que je le cherche

3 / j’ai lancé la commande que tu préconises

Résultat :

Code : Tout sélectionner

gerard@gerard-L50:~$ ssh-keygen -f "/home/gerard/.ssh/known_hosts" -R 192.168.1.87
# Host 192.168.1.87 found: line 4
/home/gerard/.ssh/known_hosts updated.
Original contents retained as /home/gerard/.ssh/known_hosts.old
gerard@gerard-L50:~$ ssh -v pi@192.168.1.87
OpenSSH_7.4p1 Debian-10+deb9u6, OpenSSL 1.0.2r  26 Feb 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.1.87 [192.168.1.87] port 22.
debug1: connect to address 192.168.1.87 port 22: No route to host
ssh: connect to host 192.168.1.87 port 22: No route to host
gerard@gerard-L50:~$ 
Merci & à+

marseillois
Messages : 61
Enregistré le : ven. 10 juin 2016 14:18

Re: Connection refused

Message par marseillois » mer. 27 mars 2019 19:42

Re salut domi et milles excuses

3bis /

Pardon la connexion n’était pas fonctionnelle et je ne l’avais pas sous le nez

Nouvel essai

Code : Tout sélectionner

gerard@gerard-L50:~$ ssh -v pi@192.168.1.87
OpenSSH_7.4p1 Debian-10+deb9u6, OpenSSL 1.0.2r  26 Feb 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.1.87 [192.168.1.87] port 22.
debug1: connect to address 192.168.1.87 port 22: No route to host
ssh: connect to host 192.168.1.87 port 22: No route to host
gerard@gerard-L50:~$ gerard@gerard-L50:~$ ssh -v pi@192.168.1.87
OpenSSH_7.4p1 Debian-10+deb9u6, OpenSSL 1.0.2r  26 Feb 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.1.87 [192.168.1.87] port 22.
debug1: Connection established.
debug1: identity file /home/gerard/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gerard/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gerard/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gerard/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gerard/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gerard/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gerard/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gerard/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u6
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Raspbian-10+deb9u6
debug1: match: OpenSSH_7.4p1 Raspbian-10+deb9u6 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.1.87:22 as 'pi'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
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:XeiaygTtIdpimaTRV0JWpAt39aKI6azXaqtjTnlaL+A
The authenticity of host '192.168.1.87 (192.168.1.87)' can't be established.
ECDSA key fingerprint is SHA256:XeiaygTtIdpimaTRV0JWpAt39aKI6azXaqtjTnlaL+A.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.87' (ECDSA) to the list of known hosts.
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/gerard/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
sign_and_send_pubkey: signing failed: agent refused operation
debug1: Trying private key: /home/gerard/.ssh/id_dsa
debug1: Trying private key: /home/gerard/.ssh/id_ecdsa
debug1: Trying private key: /home/gerard/.ssh/id_ed25519
debug1: Next authentication method: password
pi@192.168.1.87's password: 
Authentication failed.
Mais là il me demande un mot de passe que j’ignore : j’ai essayé tous les mots de passe possibles dont raspberry et même la passphrase, mais rien n’y fait ???
C'est un pb que j'ai déjà rencontré précédemment au début de mes travaux

Une idée ??? En attendant je continue à chercher

Merci

domi
Administrateur
Messages : 2838
Enregistré le : mer. 17 sept. 2014 18:12
Localisation : Seine et Marne

Re: Connection refused

Message par domi » mer. 27 mars 2019 20:19

Ah bien la c'est bon, il demande le mot de passe.

C'est le même que celui que tu utilises pour te connecter au Rpi lorsqu'il est branché sur la TV.
Ton utilisateur est bien "pi" où tu l'as changé ?

Un fois la connexion fonctionnelle, on va pouvoir se pencher sur la connexion par clé.
Passionné de Raspberry, Arduino, ESP8266, ESP32, et objets connectés :
Spécial débutant, concevez vous-même votre domotique DIY : https://www.youtube.com/c/DomoticDIY

marseillois
Messages : 61
Enregistré le : ven. 10 juin 2016 14:18

Re: Connection refused

Message par marseillois » mer. 27 mars 2019 22:57

Salut domi

Le problème c'est que lorsque j'ouvre directement par le rpi à l'écran de la Télé, il ne me demande jamais de mot de passe, pas plus que lorsque je travaille en sudoer : c'est ce que je t'ai signalé à plusieurs reprises au fur et à mesure des essais que tu m'as suggéré

Et pourtant je suis certain d'avoir modifié le mot de passe par défaut (raspberry) lors de la mise en route : mais ni raspberry ni mon mot de passe n'ont été accepté au terminal

Merci

domi
Administrateur
Messages : 2838
Enregistré le : mer. 17 sept. 2014 18:12
Localisation : Seine et Marne

Re: Connection refused

Message par domi » jeu. 28 mars 2019 05:55

Bonjour,

Dans ce cas il suffit d'ouvrir une console puis d'effectuer les commandes suivantes : Pour connaitre le nom de l'utilisateur en cours, et s'assurer qu'il s'agit bien de "pi".
Puis pour changer son mot de passe :

Code : Tout sélectionner

sudo passwd <user>
où <user> est le nom de l'utilisateur retourné à la commande précédente.
Passionné de Raspberry, Arduino, ESP8266, ESP32, et objets connectés :
Spécial débutant, concevez vous-même votre domotique DIY : https://www.youtube.com/c/DomoticDIY

marseillois
Messages : 61
Enregistré le : ven. 10 juin 2016 14:18

Re: Connection refused

Message par marseillois » jeu. 28 mars 2019 19:40

Salut domi
J’ai modifié le mot de passe du serveur comme tu me l’as proposé, puis j’ai relancé la liaison ssh à partir du client vers le serveur

Résultat

Code : Tout sélectionner

gerard@gerard-L50:~$ who
gerard   tty2         2019-03-28 18:43 (:0)
gerard@gerard-L50:~$ ssh -v pi@192.168.1.87
OpenSSH_7.4p1 Debian-10+deb9u6, OpenSSL 1.0.2r  26 Feb 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.1.87 [192.168.1.87] port 22.
debug1: Connection established.
debug1: identity file /home/gerard/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gerard/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gerard/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gerard/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gerard/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gerard/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gerard/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/gerard/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u6
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Raspbian-10+deb9u6
debug1: match: OpenSSH_7.4p1 Raspbian-10+deb9u6 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.1.87:22 as 'pi'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
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:XeiaygTtIdpimaTRV0JWpAt39aKI6azXaqtjTnlaL+A
debug1: Host '192.168.1.87' is known and matches the ECDSA host key.
debug1: Found key in /home/gerard/.ssh/known_hosts:4
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/gerard/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
sign_and_send_pubkey: signing failed: agent refused operation
debug1: Trying private key: /home/gerard/.ssh/id_dsa
debug1: Trying private key: /home/gerard/.ssh/id_ecdsa
debug1: Trying private key: /home/gerard/.ssh/id_ed25519
debug1: Next authentication method: password
A ce stade, une fenêtre s’ouvre,

Code : Tout sélectionner

“Saisissez le mot de passe pour déverrouiller la clef…..
une application veut accéder à la clef privée gerard@gerard-L50 mais elle est verrouillée.
Mot de passe : “
j’ai essayé successivement:
1 / Le mot de passe de gerard (utilisateur du client), sans succès
2 / Le mot de passe du root de la machine cliente, sans succès
3 / Le mot de passe de pi , sans succès
Je clicque”annuler” dans la fenêtre et je reste avec mon terminal ouvert complété par :

Code : Tout sélectionner

pi@192.168.1.87's password: 
où je tape le mot de passe de gerard, ce qui termine la commande au terminal :

Code : Tout sélectionner

Authentication failed.
gerard@gerard-L50:~$ 
J’avoue que je ne comprends plus :
d’une part la fenêtre semble demander le mot de passe de gerard pour ouvrir la clef
d’autre part le terminal demande le mot de passe du serveur après annulation de la fenêtre et pour finir je suis sur de n’avoir proposé que la passphrase lors de la création des clefs : je suis trop nul en anglais pour comprendre le mode verbeux de ma commande

J’en déduis qu’il doit y avoir des contradictions entre le ssh_config du client et le sshd_config du serveur

Je cherche le détail de chacun à ce jour, étant précisé qu’il s’agit des versions initiales actuellement en place : dis moi si tu en as besoin ???

Merci pour ta patience & ta fidélité

Répondre

Retourner vers « En panne ? »