[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ssh fingerprint mismatch for one single client



On Sun, Sep 20, 2020 at 01:59:41PM -0300, Beco wrote:
> I mean the numbers are completely different.
> PUTTY: not only different, but it appears to get a ED25519 which is not on
> the server.
> SSH powershell: It gets ECDSA, which is the algorithm accepted, but a
> completely different hex code.

Thank you for the effort.
IMO it proves that somehow your student connects to the different server
than yours. Let's disregard unusual things such as multiple sshd
listening different IPs on the same host.

There are many things that can be put to blame here:

1) Student's host configuration (aka virtual networks are teh hard).

2) Lack of understanding the consequences of using VPN (again, student's
configuration problem).

3) Misconfigured router at student's household.

4) Malicious/honestly stupid ISP at student's side.

5) Many more, that boil down to exactly one thing - something redirects
your student's connection to your server elsewhere.


So you have a good thing here and you have a bad one too.

Good one is - you show your students (note the plural) these two sets of
fingerprints, and you tell them - 'see, folks, that is what exactly SSH
is protecting you from'. A real-world example, a starting point for the
research, all that.

Bad one is - it's unlikely that you fix it unless you gain a complete
understanding of the student's LAN and WAN. Too many possibilities here,
and they need to be eliminated one by one.


Last one. tcpdump. It's kind of obvious that there will be inbound
traffic on tcp:22 to your server, and that's expected, and there's
nothing to see there. But, what you would see (or the output would be
lacking it) is the problematic student IP. That's what interesting here.
For obvious reasons, it requires a knowledge of the student's IP.

Reco


Reply to: