Discussion:
ssh fingerprint mismatch for one single client
(too old to reply)
Beco
2020-09-19 21:30:01 UTC
Permalink
Dear linuxers,

I've a server and one of my students is getting a wrong fingerprint when
trying to connect via SSH.

After a lot of debug, we are still unable to pinpoint why.

The server didn't change IP or keys, and other students still log in ok
with the correct fingerprint. Just one student, let's call him Bob (because
why not), is not getting through.

I've asked Bob to try a different machine, which he does not have, being a
poor student. But he had a mobile, so after trying the app juiceSSH and
wifi on, he again got the wrong fingerprint.

I asked him to turn the wifi off for the mobile and yes, he got the correct
fingerprint.

I also asked him to run a full antivirus scan in his notebook (windows) and
nothing was found.

He also hard-reseted the router, still the problem continues.

He called the ISP for any clues, but it is a small company who doesn't know
the word "fingerprint" neither in english nor in their native language. So,
not much help there.

I also asked him to check if his IP is what he think it is, and he checked
with one of these "what is my IP" website and it is ok.

As for DNS, I asked him to try to ssh directly using the server's IP
instead of the name, but still the wrong fingerprint.

Kinda crazy, right? I run out of ideas...

What else should I try to help that student?

Thanks
Beco
--
Dr Beco
A.I. researcher

"I know you think you understand what you thought I said but I'm not sure
you realize that what you heard is not what I meant" -- Alan Greenspan

GPG Key: https://pgp.mit.edu/pks/lookup?op=vindex&search=0x5A107A425102382A
Creation date: pgp.mit.edu ID as of 2014-11-09

Essa mensagem é destinada exclusivamente ao seu destinatário e pode conter
informações confidenciais, protegidas por sigilo profissional, direitos
autorais reservados, ou cuja divulgação seja proibida por lei. O uso não
autorizado de tais informações é proibido e está sujeito às penalidades
cabíveis.

This message is intended exclusively for its addressee and may contain
information that is confidential and protected by a professional privilege,
reserved copyright, or whose disclosure is prohibited by law. Unauthorized
use of such information is prohibited and subject to applicable penalties.
Lucas Castro
2020-09-19 21:50:02 UTC
Permalink
Post by Beco
Dear linuxers,
I've a server and one of my students is getting a wrong fingerprint
when trying to connect via SSH.
After a lot of debug, we are still unable to pinpoint why.
The server didn't change IP or keys, and other students still log in
ok with the correct fingerprint. Just one student, let's call him Bob
(because why not), is not getting through.
I've asked Bob to try a different machine, which he does not have,
being a poor student. But he had a mobile, so after trying the app
juiceSSH and wifi on, he again got the wrong fingerprint.
I asked him to turn the wifi off for the mobile and yes, he got the
correct fingerprint.
I also asked him to run a full antivirus scan in his notebook
(windows) and nothing was found.
He also hard-reseted the router, still the problem continues.
He called the ISP for any clues, but it is a small company who doesn't
know the word "fingerprint" neither in english nor in their native
language. So, not much help there.
I also asked him to check if his IP is what he think it is, and he
checked with one of these "what is my IP" website and it is ok.
As for DNS, I asked him to try to ssh directly using the server's IP
instead of the name, but still the wrong fingerprint.
Kinda crazy, right? I run out of ideas...
What else should I try to help that student?
Check if he's really reaching the right server.

ping the server from his computer and check with tcpdump on server side.

If not reaching the server, try traceroute to track where is going on.


Local address or Internet address address?

If local address, maybe he had already  accessed other server with the
same address.
Post by Beco
Thanks
Beco
--
Dr Beco
A.I. researcher
"I know you think you understand what you thought I said but I'm not
sure you realize that what you heard is not what I meant" -- Alan
Greenspan
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x5A107A425102382A
Creation date: pgp.mit.edu <http://pgp.mit.edu> ID as of 2014-11-09
Essa mensagem é destinada exclusivamente ao seu destinatário e pode
conter informações confidenciais, protegidas por sigilo profissional,
direitos autorais reservados, ou cuja divulgação seja proibida por
lei. O uso não autorizado de tais informações é proibido e está
sujeito às penalidades cabíveis.
This message is intended exclusively for its addressee and may contain
information that is confidential and protected by a professional
privilege, reserved copyright, or whose disclosure is prohibited by
law. Unauthorized use of such information is prohibited and subject to
applicable penalties.
--
Lucas Castro
Beco
2020-09-19 22:40:02 UTC
Permalink
Post by Lucas Castro
Check if he's really reaching the right server.
ping the server from his computer and check with tcpdump on server side.
If not reaching the server, try traceroute to track where is going on.
Local address or Internet address address?
If local address, maybe he had already accessed other server with the
same address.
--
Lucas Castro
Dear Lucas, thanks for the interest.

The ping server side is disabled, so this test is not possible.
Traceroute from student to server shows it is the correct server.


Not a clue yet. Thanks
--
Dr Beco
A.I. researcher

"I know you think you understand what you thought I said but I'm not sure
you realize that what you heard is not what I meant" -- Alan Greenspan

GPG Key: https://pgp.mit.edu/pks/lookup?op=vindex&search=0x5A107A425102382A
Creation date: pgp.mit.edu ID as of 2014-11-09

Essa mensagem é destinada exclusivamente ao seu destinatário e pode conter
informações confidenciais, protegidas por sigilo profissional, direitos
autorais reservados, ou cuja divulgação seja proibida por lei. O uso não
autorizado de tais informações é proibido e está sujeito às penalidades
cabíveis.

This message is intended exclusively for its addressee and may contain
information that is confidential and protected by a professional privilege,
reserved copyright, or whose disclosure is prohibited by law. Unauthorized
use of such information is prohibited and subject to applicable penalties.
mick crane
2020-09-19 22:00:06 UTC
Permalink
Post by Beco
Dear linuxers,
I've a server and one of my students is getting a wrong fingerprint when
trying to connect via SSH.
After a lot of debug, we are still unable to pinpoint why.
The server didn't change IP or keys, and other students still log in ok
with the correct fingerprint. Just one student, let's call him Bob (because
why not), is not getting through.
I've asked Bob to try a different machine, which he does not have, being a
poor student. But he had a mobile, so after trying the app juiceSSH and
wifi on, he again got the wrong fingerprint.
I asked him to turn the wifi off for the mobile and yes, he got the correct
fingerprint.
I also asked him to run a full antivirus scan in his notebook (windows) and
nothing was found.
He also hard-reseted the router, still the problem continues.
He called the ISP for any clues, but it is a small company who doesn't know
the word "fingerprint" neither in english nor in their native language. So,
not much help there.
I also asked him to check if his IP is what he think it is, and he checked
with one of these "what is my IP" website and it is ok.
As for DNS, I asked him to try to ssh directly using the server's IP
instead of the name, but still the wrong fingerprint.
Kinda crazy, right? I run out of ideas...
What else should I try to help that student?
Thanks
Beco
Just wild guess.
Student can connect via the mobile network but not through the ISP
router?
Might that be the port for ssh on the router ?

mick
--
Key ID 4BFEBB31
Beco
2020-09-19 22:50:01 UTC
Permalink
Post by mick crane
Just wild guess.
Student can connect via the mobile network but not through the ISP
router?
Might that be the port for ssh on the router ?
mick
--
Key ID 4BFEBB31
Hello Mick,

Thanks for the interest.

Yes, student can connect via mobile.

And, somewhat "yes", student can kind of connect via ISP. It is not that
the port is blocking traffic.
The fingerprint appears, and if accepted the wrong one, the password is
asked for.

But then, of course, the connection fail.

Also, he was able to connect the day before. So whatever it is, it is
recent, and just for one single student.

Also, I asked him to check the router port 22 if it was ok. He did a hard
reset (factory reset) on it. He took a look and it is open.


My best,
Beco
--
Dr Beco
A.I. researcher

"I know you think you understand what you thought I said but I'm not sure
you realize that what you heard is not what I meant" -- Alan Greenspan

GPG Key: https://pgp.mit.edu/pks/lookup?op=vindex&search=0x5A107A425102382A
Creation date: pgp.mit.edu ID as of 2014-11-09

Essa mensagem é destinada exclusivamente ao seu destinatário e pode conter
informações confidenciais, protegidas por sigilo profissional, direitos
autorais reservados, ou cuja divulgação seja proibida por lei. O uso não
autorizado de tais informações é proibido e está sujeito às penalidades
cabíveis.

This message is intended exclusively for its addressee and may contain
information that is confidential and protected by a professional privilege,
reserved copyright, or whose disclosure is prohibited by law. Unauthorized
use of such information is prohibited and subject to applicable penalties.
mick crane
2020-09-20 03:40:02 UTC
Permalink
Post by Beco
Post by mick crane
Just wild guess.
Student can connect via the mobile network but not through the ISP
router?
Might that be the port for ssh on the router ?
mick
Hello Mick,
Thanks for the interest.
Yes, student can connect via mobile.
And, somewhat "yes", student can kind of connect via ISP. It is not that
the port is blocking traffic.
The fingerprint appears, and if accepted the wrong one, the password is
asked for.
But then, of course, the connection fail.
Also, he was able to connect the day before. So whatever it is, it is
recent, and just for one single student.
Also, I asked him to check the router port 22 if it was ok. He did a hard
reset (factory reset) on it. He took a look and it is open.
Is this Putty or something with keys on student's PC ?
If worked before maybe something went wrong with the saved connection
but that doesn't explain why cannot connect via phone>router WIFI unless
there is separate issue there.
I guess I would try connect via command line with verbosity but I'd have
to look up exactly the syntax.

mick
--
Key ID 4BFEBB31
David Christensen
2020-09-20 06:00:01 UTC
Permalink
Post by Beco
Post by mick crane
Student can connect via the mobile network but not through the ISP
router?
Might that be the port for ssh on the router ?
Yes, student can connect via mobile.
And, somewhat "yes", student can kind of connect via ISP. It is not that
the port is blocking traffic.
The fingerprint appears, and if accepted the wrong one, the password is
asked for.
But then, of course, the connection fail.
First, disable Bob's account until later (see below).


Second, assess if your server(s) and/or network(s) have been compromised.


Third, tighten security.


Related to this incident, set up an unprivileged account for yourself,
install your authorized_keys file, make sure you can login to your
account via public key authentication, and make sure you can su(1) to
root or use sudo(8) to get a root shell. Then edit sshd_config(5) so
that unprivileged users log in with SSH public keys and the root user
cannot log in:

PasswordAuthentication no

PermitRootLogin no


Restart sshd for the settings to take effect:

# service sshd restart

# service sshd status


Your students will need to send you their authorized_keys files and you
will need to install those files for the students to log in. Passwords
will no longer be required nor accepted. If a fingerprint does not
match and a student tries to login anyway, their account and your server
will not be compromised. Enable Bob's account.


Security is an endless topic. Please post if you have questions or need
more ideas.


David
Reco
2020-09-20 08:50:01 UTC
Permalink
Hi.
Post by Beco
Dear linuxers,
I've a server and one of my students is getting a wrong fingerprint when
trying to connect via SSH.
Lots of wild guessing and we still don't know the problem. There are
different fingerprints involved, so we don't know exactly what "a
wrong fingerprint" means.
Could yout student just try
(Or whatever "verbose" equivalent there is for his ssh client) and
post the results (suitably edited, to hide sensitive information!)
here?
My hunch is that this student's ssh client picked at some time the
wrong host key and is now complaining, but that's only a hunch!
A better idea. Does the student in question even connects to the server?

tcpdump -pni any tcp port 22

Should answer this.

BTW, is the server in question public? I.e. can any of the list members
connect to it and find out for themselves that's a good fingerprint
looks like?

Reco
Beco
2020-09-20 17:10:01 UTC
Permalink
Thank you all so much for thid new batch of input Mick, LARAC, David, Tomas
and Reco
Post by mick crane
Is this Putty or something with keys on student's PC ?
No keys on PUTTY. Log in with password.
Post by mick crane
If worked before maybe something went wrong with the saved connection
but that doesn't explain why cannot connect via phone>router WIFI unless
there is separate issue there.
Exactly. How come phone>wifi don't work, and phone>mobile-net works ?
Post by mick crane
I guess I would try connect via command line with verbosity but I'd have
to look up exactly the syntax.
mick
--
Key ID 4BFEBB31
mick ends -----
Assuming it is the same server being contacted, which is likely
but not
Post by mick crane
absolutely assured,
Ok, I'll test for that. (tcpdump suggested by Reco below)
Post by mick crane
then the difference should be a conflict in the
known_hosts file on the client machine,
Ok, I've asked him to delete those files.
The message simply changed from the scary warning
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!@

to the usual warning.
The authenticity of host 'the.server.in.question (198.200.100.50)' can't be
established.
Post by mick crane
I don't think you have mentioned what the
client is, or on what platform it is running, BTW, which would be very
helpful.
Bob's client 1: PuTTY. Currently this is 0.74, released on 2020-06-27.
http://putty.org


Bob's client 2: windows version 10, powershell version
PS C:\> Get-Host
Name : ConsoleHost
Version : 5.1.19041.1


Bob's client 3: ubuntu from usb stick 20.04


Server is debian 10 buster
OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d
Post by mick crane
LARAC
LARAC ends -----
Lots of wild guessing and we still don't know the problem. There are
different fingerprints involved, so we don't know exactly what "a
wrong fingerprint" means.
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.

If I run on my notebook the command:
My answer is OK

$ nmap -p22 -n --script ssh-hostkey the.server.in.question
Starting Nmap 7.70 ( https://nmap.org ) at 2020-09-19 19:12 -03
Nmap scan report for the.server.in.question (198.200.100.50)
Host is up (0.0055s latency).
PORT STATE SERVICE
22/tcp open ssh
| ssh-hostkey:
| 2048 33:44:55:66:77:88:99:11:22:33:44:55:66:77:aa:bb (RSA)
| 256 cc:99:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee (ECDSA)
Nmap done: 1 IP address (1 host up) scanned in 1.05 seconds

My notebook (external) shows correct server IP and the 2 accepted
fingerprints.



On Bob's notebook:

$ nmap -p22 -n --script ssh-hostkey the.server.in.question
Starting Nmap 7.70 ( https://nmap.org ) at 2020-09-19 18:12 -03
Nmap scan report for the.server.in.question (198.200.100.50)
Host is up (0.0055s latency).
PORT STATE SERVICE
22/tcp open ssh
| ssh-hostkey:
| 2048 12:34:56:78:9c:cd:dc:cd:de:ef:f0:01:12:13:14:15 (RSA)
| 256 5b:6b:4b:3b:2b:1b:8b:2b:7b:9b:9b:0b:3b:5b:4b:3b (ECDSA)
|_ 256 a1:a2:a3:a4:a5:a6:a7:a8:a9:a0:a1:a2:a3:a4:a5:a6 (ED25519)
Nmap done: 1 IP address (1 host up) scanned in 1.05 seconds

All wrong.
Post by mick crane
Could yout student just try
I've asked him, here it is the reply:



***@ubuntu:~$ ssh -v ***@the.server.in.question
OpenSSH_8.2p1 Ubuntu-4, OpenSSL 1.1.1f 31 Mar 2020
debug1: Reading configuration data /etc/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 *
debug1: Connecting to the.server.in.question [198.200.100.50] port 22.
debug1: Connection established.
debug1: identity file /home/ubuntu/.ssh/id_rsa type -1
debug1: identity file /home/ubuntu/.ssh/id_rsa-cert type -1
debug1: identity file /home/ubuntu/.ssh/id_dsa type -1
debug1: identity file /home/ubuntu/.ssh/id_dsa-cert type -1
debug1: identity file /home/ubuntu/.ssh/id_ecdsa type -1
debug1: identity file /home/ubuntu/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/ubuntu/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/ubuntu/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/ubuntu/.ssh/id_ed25519 type -1
debug1: identity file /home/ubuntu/.ssh/id_ed25519-cert type -1
debug1: identity file /home/ubuntu/.ssh/id_ed25519_sk type -1
debug1: identity file /home/ubuntu/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/ubuntu/.ssh/id_xmss type -1
debug1: identity file /home/ubuntu/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1
Debian-10+deb10u2
debug1: match: OpenSSH_7.9p1 Debian-10+deb10u2 pat OpenSSH* compat
0x04000000
debug1: Authenticating to the.server.in.question:22 as 'bob'
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-***@openssh.com MAC:
<implicit> compression: none
debug1: kex: client->server cipher: chacha20-***@openssh.com MAC:
<implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256
SHA256:+2abcdf2312QbKjdsafdkjfIOIjnCCDIOej129831jasROY.
The authenticity of host 'the.server.in.question (198.200.100.50)' can't be
established.
ECDSA key fingerprint is
SHA256:+2abcdf2312QbKjdsafdkjfIOIjnCCDIOej129831jasROY.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

---------

This fingerprinting (ending with ROY in the example) is incorrect.


Server and IP are correct on the command above.
Post by mick crane
My hunch is that this student's ssh client picked at some time the
wrong host key and is now complaining, but that's only a hunch!
Thanks. That is useful insight. Let's hunt the hunch.
Post by mick crane
Cheers
- t
tomas ends -----
A better idea. Does the student in question even connect to the server?
tcpdump -pni any tcp port 22
Should answer this.
Great. Thanks! Here the returned output:

***@ubuntu:~# tcpdump -pni any tcp port 22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size
262155 bytes
16:15:50.625508 IP 192.168.0.111.50318 > 198.200.100.50.22: Flags [S], seq
679150150, win 65250, options [mss 1560,sackOK,TS val 1851137962 ecr
0,nop,wscale 7], length 0
16:15:50.629235 IP 198.200.100.50.22 > 192.168.0.111.50318: Flags [S.], seq
3925591115, ack 679150151, win 65160, options [mss 1550,sackOK,TS val
1590695331 ecr 1851137962,nop,wscale 7], length 0
16:15:50.629329 IP 192.168.0.111.50318 > 198.200.100.50.22: Flags [.], ack
1, win 502, options [nop,nop,TS val 1851137966 ecr 1590695331], length 0
16:15:50.630663 IP 192.168.0.111.50318 > 198.200.100.50.22: Flags [P.], seq
1:33, ack 1, win 502, options [nop,nop,TS val 1851137968 ecr 1590695331],
length 32
16:15:50.633895 IP 198.200.100.50.22 > 192.168.0.111.50318: Flags [.], ack
33, win 509, options [nop,nop,TS val 1590695336 ecr 1851137968], length 0
16:15:50.653739 IP 198.200.100.50.22 > 192.168.0.111.50318: Flags [P.], seq
1:52, ack 33, win 509, options [nop,nop,TS val 1590695356 ecr 1851137968],
length 51
16:15:50.653798 IP 192.168.0.111.50318 > 198.200.100.50.22: Flags [.], ack
52, win 502, options [nop,nop,TS val 1851137981 ecr 1590695356], length 0
16:15:50.655585 IP 192.168.0.111.50318 > 198.200.100.50.22: Flags [.], seq
33:1561, ack 52, win 502, options [nop,nop,TS val 1851137981 ecr
1590695356], length 1528
16:15:50.655655 IP 192.168.0.111.50318 > 198.200.100.50.22: Flags [P.], seq
1561:1555, ack 52, win 502, options [nop,nop,TS val 1851137981 ecr
1590695356], length 85
16:15:50.662535 IP 198.200.100.50.22 > 192.168.0.111.50318: Flags [P.], seq
52:1122, ack 33, win 509, options [nop,nop,TS val 1590695359 ecr
1851137981], length 1080
16:15:50.662625 IP 192.168.0.111.50318 > 198.200.100.50.22: Flags [.], ack
1122, win 595, options [nop,nop,TS val 1851137999 ecr 1590695359], length 0
16:15:50.662685 IP 198.200.100.50.22 > 192.168.0.111.50318: Flags [.], ack
1561, win 501, options [nop,nop,TS val 1590695362 ecr 1851137981], length 0
16:15:50.665500 IP 198.200.100.50.22 > 192.168.0.111.50318: Flags [.], ack
1555, win 501, options [nop,nop,TS val 1590695366 ecr 1851137981], length 0
16:15:50.675058 IP 192.168.0.111.50318 > 198.200.100.50.22: Flags [P.], seq
1555:1593, ack 1122, win 501, options [nop,nop,TS val 1851138011 ecr
1590695366], length 58
16:15:50.676605 IP 198.200.100.50.22 > 192.168.0.111.50318: Flags [.], ack
1593, win 501, options [nop,nop,TS val 1590695379 ecr 1851138011], length 0
16:15:50.687798 IP 198.200.100.50.22 > 192.168.0.111.50318: Flags [P.], seq
1122:1575, ack 1593, win 501, options [nop,nop,TS val 1590695390 ecr
1851138011], length 552
16:15:50.687855 IP 192.168.0.111.50318 > 198.200.100.50.22: Flags [.], ack
1575, win 598, options [nop,nop,TS val 1851138025 ecr 1590695390], length 0
16:15:53.358993 IP 192.168.0.111.50318 > 198.200.100.50.22: Flags [F.], seq
1593, ack 1575, win 501, options [nop,nop,TS val 1851150696 ecr
1590695390], length 0
16:15:53.367708 IP 198.200.100.50.22 > 192.168.0.111.50318: Flags [F.], seq
1575, ack 1595, win 501, options [nop,nop,TS val 1590698070 ecr
1851150696], length 0
16:15:53.367730 IP 192.168.0.111.50318 > 198.200.100.50.22: Flags [.], ack
1575, win 501, options [nop,nop,TS val 1851150705 ecr 1590698070], length 0
^C
20 packets captured
20 packets received by filter
0 packets dropped by kernel



The server IP is correct (198.200.100.50 fictitious but correct)
Post by mick crane
BTW, is the server in question public? I.e. can any of the list members
connect to it and find out for themselves that's a good fingerprint
looks like?
It is not, sorry about that.
But I think the command above "nmap" gives a good example.

Bad fingerprint:
ECDSA key fingerprint is
SHA256:+2abcdf2312QbKjdsafdkjfIOIjnCCDIOej129831jasROY.
or as md5:
| 256 5b:6b:4b:3b:2b:1b:8b:2b:7b:9b:9b:0b:3b:5b:4b:3b (ECDSA)

---

Good fingerprint:
AADSkjdsd98ajdasfnSlkjl2k342ASndsnfjdsfJKJOsdkn123ssasd2dscjcjodifjadsf8jdfjsncFLY
or as md5:
| 256 cc:99:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee (ECDSA)
Post by mick crane
Reco
Reco ends -----
Also: i asked him to try connecting via cable (instead of wifi). Same
problem.

I also asked him to bring his notebook to a neighbor to try to connect from
there. We'll see his reply soon.

Thanks all for the rich input. I hope we can find something.



--
Dr Beco
A.I. researcher

"I know you think you understand what you thought I said but I'm not sure
you realize that what you heard is not what I meant" -- Alan Greenspan

GPG Key: https://pgp.mit.edu/pks/lookup?op=vindex&search=0x5A107A425102382A
Creation date: pgp.mit.edu ID as of 2014-11-09

Essa mensagem é destinada exclusivamente ao seu destinatário e pode conter
informações confidenciais, protegidas por sigilo profissional, direitos
autorais reservados, ou cuja divulgação seja proibida por lei. O uso não
autorizado de tais informações é proibido e está sujeito às penalidades
cabíveis.

This message is intended exclusively for its addressee and may contain
information that is confidential and protected by a professional privilege,
reserved copyright, or whose disclosure is prohibited by law. Unauthorized
use of such information is prohibited and subject to applicable penalties.
Beco
2020-09-20 17:20:01 UTC
Permalink
Post by Beco
I also asked him to bring his notebook to a neighbor to try to connect
from there. We'll see his reply soon.
Update:

He went to his neighbor with his notebook in hand, tried there and he got
the correct fingerprint and connected to the server with no issues.



Cheers,
Beco
--
Dr Beco
A.I. researcher

"I know you think you understand what you thought I said but I'm not sure
you realize that what you heard is not what I meant" -- Alan Greenspan

GPG Key: https://pgp.mit.edu/pks/lookup?op=vindex&search=0x5A107A425102382A
Creation date: pgp.mit.edu ID as of 2014-11-09

Essa mensagem é destinada exclusivamente ao seu destinatário e pode conter
informações confidenciais, protegidas por sigilo profissional, direitos
autorais reservados, ou cuja divulgação seja proibida por lei. O uso não
autorizado de tais informações é proibido e está sujeito às penalidades
cabíveis.

This message is intended exclusively for its addressee and may contain
information that is confidential and protected by a professional privilege,
reserved copyright, or whose disclosure is prohibited by law. Unauthorized
use of such information is prohibited and subject to applicable penalties.
Reco
2020-09-20 17:30:02 UTC
Permalink
Post by Beco
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
Fabien Roucaute
2020-09-20 18:40:01 UTC
Permalink
Post by Beco
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.
My answer is OK
$ nmap -p22 -n --script ssh-hostkey the.server.in.question
Starting Nmap 7.70 ( https://nmap.org ) at 2020-09-19 19:12 -03
Nmap scan report for the.server.in.question (198.200.100.50)
Host is up (0.0055s latency).
PORT   STATE SERVICE
22/tcp open  ssh
|   2048 33:44:55:66:77:88:99:11:22:33:44:55:66:77:aa:bb (RSA)
|   256 cc:99:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee (ECDSA)
Nmap done: 1 IP address (1 host up) scanned in 1.05 seconds
My notebook (external) shows correct server IP and the 2 accepted
fingerprints.
$ nmap -p22 -n --script ssh-hostkey the.server.in.question
Starting Nmap 7.70 ( https://nmap.org ) at 2020-09-19 18:12 -03
Nmap scan report for the.server.in.question (198.200.100.50)
Host is up (0.0055s latency).
PORT   STATE SERVICE
22/tcp open  ssh
|   2048 12:34:56:78:9c:cd:dc:cd:de:ef:f0:01:12:13:14:15 (RSA)
|   256 5b:6b:4b:3b:2b:1b:8b:2b:7b:9b:9b:0b:3b:5b:4b:3b (ECDSA)
|_  256 a1:a2:a3:a4:a5:a6:a7:a8:a9:a0:a1:a2:a3:a4:a5:a6 (ED25519)
Nmap done: 1 IP address (1 host up) scanned in 1.05 seconds
All wrong.
Very strange, could be a router in your network that NAT his connection
to the wrong server. Have you tried to scan other servers in your
network to look for the same fingerprints?
I can't see how he can get back answering packets with the right IP but
not the right fingerprint if a network device wasn't changing the IP
somewhere on the route between him and the server.
t***@tuxteam.de
2020-09-21 07:20:02 UTC
Permalink
Post by Beco
Thank you all so much for thid new batch of input Mick, LARAC, David, Tomas
and Reco
Post by mick crane
Is this Putty or something with keys on student's PC ?
No keys on PUTTY. Log in with password.
Post by mick crane
If worked before maybe something went wrong with the saved connection
but that doesn't explain why cannot connect via phone>router WIFI unless
there is separate issue there.
Exactly. How come phone>wifi don't work, and phone>mobile-net works ?
Yes. Given the data you've provided, I retract my first hunch: it seems
your student is seeing a different host:

- either DNS resolves to a different IP address -- then you'd see
different IP addresses for your server as viewed from your student's
workstation wrt the "rest of the world

- or routing sends your student to a different host (claiming the
same IP address, that stinks ;-)

Traceroute might help in the second case. Besides, you wouldn't see your
student's access attempts in your server logs -- after all, he's knocking
at another door.

Cheers
- t
Beco
2020-09-23 00:00:02 UTC
Permalink
Post by t***@tuxteam.de
Yes. Given the data you've provided, I retract my first hunch: it seems
- either DNS resolves to a different IP address -- then you'd see
different IP addresses for your server as viewed from your student's
workstation wrt the "rest of the world
- or routing sends your student to a different host (claiming the
same IP address, that stinks ;-)
Traceroute might help in the second case. Besides, you wouldn't see your
student's access attempts in your server logs -- after all, he's knocking
at another door.
Cheers
- t
Dear Linuxers,

I just want to close this issue by thanking everyone who chipped in with
help and attempts to solve the problem

Unfortunately the mistery will go on, because my student solve the problem
by changing his ISP server.

He told that the problem was solved immediately, as we predict and tested
(via mobile and the neighbor's internet).

So, I cannot run any more tests, and I'll stay curious about what really
happened.

My bet: the "homebrew ISP" has a DNS problem.

Thanks.

Dr. BÚco
--
Dr Beco
A.I. researcher

"I know you think you understand what you thought I said but I'm not sure
you realize that what you heard is not what I meant" -- Alan Greenspan

GPG Key: https://pgp.mit.edu/pks/lookup?op=vindex&search=0x5A107A425102382A
Creation date: pgp.mit.edu ID as of 2014-11-09

Essa mensagem é destinada exclusivamente ao seu destinatário e pode conter
informações confidenciais, protegidas por sigilo profissional, direitos
autorais reservados, ou cuja divulgação seja proibida por lei. O uso não
autorizado de tais informações é proibido e está sujeito às penalidades
cabíveis.

This message is intended exclusively for its addressee and may contain
information that is confidential and protected by a professional privilege,
reserved copyright, or whose disclosure is prohibited by law. Unauthorized
use of such information is prohibited and subject to applicable penalties.
t***@tuxteam.de
2020-09-20 08:50:02 UTC
Permalink
Post by Beco
Dear linuxers,
I've a server and one of my students is getting a wrong fingerprint when
trying to connect via SSH.
Lots of wild guessing and we still don't know the problem. There are
different fingerprints involved, so we don't know exactly what "a
wrong fingerprint" means.

Could yout student just try

ssh -v <***@yourserver>

(Or whatever "verbose" equivalent there is for his ssh client) and
post the results (suitably edited, to hide sensitive information!)
here?

My hunch is that this student's ssh client picked at some time the
wrong host key and is now complaining, but that's only a hunch!

Cheers
- t
Loading...