Forum Linux.debian/ubuntu SSH cassé: "client_input_hostkeys: no new or deprecated keys from server"

Posté par  . Licence CC By‑SA.
Étiquettes :
2
19
juin
2022

Bonjour,

Je n'arrive plus à me connecter sur ma machine Debian 11 testing.
J'ai testé depuis une Manjaro et une Linux Mint et je n'ai pas les mêmes infos fournies par l'option verbose.

Depuis Manjaro:

debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: client_input_hostkeys: searching /root/.ssh/known_hosts for 192.168.1.55 / (none)
debug1: client_input_hostkeys: searching /root/.ssh/known_hosts2 for 192.168.1.55 / (none)
debug1: client_input_hostkeys: hostkeys file /root/.ssh/known_hosts2 does not exist
debug1: client_input_hostkeys: no new or deprecated keys from server
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug2: channel 0: request shell confirm 1
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
client_loop: send disconnect: Broken pipe

Depuis Linux Mint:

debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug1: Sending env LANG = fr_FR.UTF-8
debug2: channel 0: request env confirm 0
debug2: channel 0: request shell confirm 1
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: send packet: type 98
debug3: send packet: type 1
client_loop: send disconnect: Broken pipe

Je ne vois pas ce que j'ai pu faire pour casser SSH, la dernière chose que j'ai faite sur le serveur, c'est installer proftpd.

Sinon:

  • Je n'ai pas modifié sshd_config de Debian.
  • J'ai réinstallé openssh-server sur Debian.
  • Les fichiers hosts.allow et hosts.deny du serveur sont vides.
  • telnet fonctionne sur le port 22.
  • Les 3 machines sont connectées sur la box.
  • Pas de problème pour se connecter en ssh entre Mint et Manjaro.

Je suis preneur de n'importe quelle piste.

Merci d'avance

  • # probleme de protocole de cypher ou de generation de clef

    Posté par  . Évalué à 4.

    j'avais eu ca en faisant une mise à jour,
    ca avait changé le paquet openssh-server
    qui dans sa nouvelle version ne prenait plus certains protocoles

    du coup, pour me connecter à un vieux serveur, il avait fallu que je modifie la config coté client pour autoriser les vieux protocoles de cypher

    faudrait que je retrouve la manip

  • # Logs serveur

    Posté par  (site web personnel) . Évalué à 3.

    Les logs d'un client qui parle à un serveur, ça ne donne qu'une partie de la conversation. Je suggère donc d'aller regarder s'il y a des infos dans /var/log/auth.log ou journalctl -u ssh. Si pas de piste évidente, augmenter la verbosité côté sshd et recommencer.

    Debian Consultant @ DEBAMAX

    • [^] # Re: Logs serveur

      Posté par  . Évalué à 1.

      Merci pour l'idée!

      En comparant avec une connexion qui se passe bien je peux voir que tout se passe bien la:

      juin 19 21:55:47 the-machine sshd[213922]: Accepted password for Goldorak from 192.168.1.183 port 38048 ssh2
juin 19 21:55:47 the-machine sshd[213922]: debug1: monitor_child_preauth: user Goldorak authenticated by privileged process
juin 19 21:55:47 the-machine sshd[213922]: debug1: monitor_read_log: child log fd closed
juin 19 21:55:47 the-machine sshd[213922]: debug1: PAM: establishing credentials
juin 19 21:55:47 the-machine sshd[213922]: pam_unix(sshd:session): session opened for user Goldorak(uid=1001) by (uid=0)
juin 19 21:55:48 the-machine sshd[213922]: User child is on pid 213949
juin 19 21:55:48 the-machine sshd[213922]: debug1: session_new: session 0
juin 19 21:55:48 the-machine sshd[213922]: debug1: SELinux support disabled

      Et que la suite n'est pas normale:

      juin 19 21:55:48 the-machine sshd[213922]: debug1: do_cleanup
juin 19 21:55:48 the-machine sshd[213922]: debug1: PAM: cleanup
juin 19 21:55:48 the-machine sshd[213922]: debug1: PAM: closing session
juin 19 21:55:48 the-machine sshd[213922]: pam_unix(sshd:session): session closed for user Goldorak
juin 19 21:55:48 the-machine sshd[213922]: debug1: PAM: deleting credentials
juin 19 21:55:48 the-machine sshd[213922]: debug1: temporarily_use_uid: 1001/1001 (e=0/0)
juin 19 21:55:48 the-machine sshd[213922]: debug1: restore_uid: 0/0
juin 19 21:55:48 the-machine sshd[213922]: debug1: session_pty_cleanup2: session 0 release /dev/pts/0
juin 19 21:55:48 the-machine sshd[213922]: debug1: audit_event: unhandled event 12

      Il s'avère que c'est ce qui arrive quand on se trompe de masque de sous réseau. J'ai mis un CDR de 25 au lieu de 24…

      Le problème est réglé.

      • [^] # Re: Logs serveur

        Posté par  (site web personnel) . Évalué à 3.

        Super. C'est effectivement assez cohérent avec le message d'erreur initial, qui faisait plus penser à un problème de tuyauterie qu'à un problème protocolaire (qui se solderait par un message plus explicite de type « on n'a pas réussi à se mettre d'accord »).

        Debian Consultant @ DEBAMAX

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.