Besoin d'aide pour débug ssh Le sujet est résolu

[piratebab]

J'ai une connexion ssh qui ne fonctionne plus (client et serveur debian, derriere proxy identifiant)
Je passe par corkscrew, ça fonctionnait bien, mais il y du y avoir une mise à jour quelque part (proxy ?).
Je n'arrive pas à identifier l'origine du probléme. Je lance le client ssh avec debug niveau 3 (-vvv), si vous y voyez une info sur l'origine du probleme, je suis preneur

Code : Tout sélectionner

OpenSSH_8.3p1 Debian-1, OpenSSL 1.1.1g  21 Apr 2020
debug1: Reading configuration data /home/xxx/.ssh/config
debug1: /home/xxx/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /xxx/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname xxxxx is address
debug1: Executing proxy command: exec corkscrew xxxxxx ~/.corkscrew/corkscrew-auth
debug1: identity file /home/xxx/.ssh/id_rsa type -1
.......
debug1: identity file /home/xxx/.ssh/id_xmss type -1
debug1: identity file /home/xxx/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.3p1 Debian-1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.3p1 Debian-1
debug1: match: OpenSSH_8.3p1 Debian-1 pat OpenSSH* compat 0x04000000
debug2: fd 5 setting O_NONBLOCK
debug2: fd 4 setting O_NONBLOCK
debug1: Authenticating to xxxxx as 'xxxxx'
debug3: put_host_port: [xxx]:443
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
Connection closed by UNKNOWN port 65535

Quelques infos complémentaires:
- synaptic passe le proxy , donc les identifiants sont bons
- depuis un tel android, je me connecte sans probleme au serveur en ssh

[piratebab]

D'aprés es recherches et analyses,il s'agit d'un probleme de ssh, pas de corkscrew.
J'ai essayer de regarder le auth.log sur le serveur, mais j'ai de centaines de tentatives de connexion rejetées par le serveur, avec des noms d'utilisateurs probablement issus de de listes standard (par ex "testeur", "www", root).
Impossible de retrouver mes propres tentatives de connexion (surtout via un tel android connecté en ssh sur le server!)

[piratebab]

J'ai analyér le auth.log coté serveur, pas de trace de tentative de connexion avec l'utilisateur concerné.
du coup, je ne suis pas aussi certains que ça passe corkscrew.

[piratebab]

quelqu'un pourrais m'indiquer comment exploiter les log d'une connexion ssh lancée avec l'option -vvv . Je ne trouve rien sur internet
ma connexion bloque à
SSH2_MSG_KEXINIT sent
et je me fait éjecté par un
Connection closed by UNKNOWN port 65535

[Lolo]

Salut piratebab,

Tu peux voir aussi coté serveur comme tu l'a mentionné.
Tu peux augmenter la "verbosité" de sshd dans /var/log/auth.log

Regarde via /etc/ssh/sshd_config en changeant la ligne LogLevel
http://www.delafond.org/traducmanfr/man ... fig.5.html

Code : Tout sélectionner

SyslogFacility AUTH
LogLevel DEBUG3

Visiblement la connexion coté client bloque au moment de la transmission de la clef privée d'après ce que j'ai pu lire via une recherche "SSH2_MSG_KEXINIT".

As tu essayé sans clef privé, simplement par mot de passe, juste pour voir "la base" est encore bonne ?
Tu te connectes avec une clef privé ou c'est corkscrew qui dispose d'une clef privé pour se connecter ?

[piratebab]

Merci pour ta réponse.
Je vais augmenter la verbosité coté serveur, mais il faut que je trouve une solution en amont pour bloquer les multiples tentatives de pénétration, parfois plusieurs par seconde.
Pour le moment aucune trace de mes tentatives de connexion coté serveur.

Il n'y a pas d'échange de clefs, c'est déja par mot de passe.
C'est une config qui fonctionnait bien depuis des mois , et puis à la rentrée, message d'erreur

[Lolo]

Les multiples tentatives de pénétration journalisées que tu mentionne utilisent le même accès que celui qui te pose problème ?
Via un téléphone Android c'est OK.

Peut être un problème du coté de la machine cliente ?

[piratebab]

Ce sont clarement des attaques en force brute, souvent sur le compte root (qui n'est pas autorisé en ssh, ils peuvent toujours tenter ..).
Je pense que je vais installer un fail2ban sur cette machine. Il n'y a que le port ssh de routé sur internet pour cette machine.

C'est OK avec le tel android, j'utilise juicyssh, trés pratique, mais pas trés ergonomique (pas de clavier!)

[piratebab]

J’ai sorti la grosse artillerie (wireshark), et c'est bien le proxy qui coupe brutalement la connexion dès qu’il se rend compte que ce qui transite vers le port 443 est du ssh. J'ouvre un sujet spécifique.