Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #227136 > unrolled thread

ssh fingerprint mismatch for one single client

Back to article view | Back to linux.debian.user

Contents

  ssh fingerprint mismatch for one single client Beco <rcb@beco.cc> - 2020-09-19 23:30 +0200
    Re: ssh fingerprint mismatch for one single client Lucas Castro <lucas@gnuabordo.com.br> - 2020-09-19 23:50 +0200
      Re: ssh fingerprint mismatch for one single client Beco <rcb@beco.cc> - 2020-09-20 00:40 +0200
    Re: ssh fingerprint mismatch for one single client mick crane <mick.crane@gmail.com> - 2020-09-20 00:00 +0200
      Re: ssh fingerprint mismatch for one single client Beco <rcb@beco.cc> - 2020-09-20 00:50 +0200
        Re: ssh fingerprint mismatch for one single client mick crane <mick.crane@gmail.com> - 2020-09-20 05:40 +0200
        Re: ssh fingerprint mismatch for one single client David Christensen <dpchrist@holgerdanske.com> - 2020-09-20 08:00 +0200
    Re: ssh fingerprint mismatch for one single client Reco <recoverym4n@enotuniq.net> - 2020-09-20 10:50 +0200
      Re: ssh fingerprint mismatch for one single client Beco <rcb@beco.cc> - 2020-09-20 19:10 +0200
        Re: ssh fingerprint mismatch for one single client Beco <rcb@beco.cc> - 2020-09-20 19:20 +0200
        Re: ssh fingerprint mismatch for one single client Reco <recoverym4n@enotuniq.net> - 2020-09-20 19:30 +0200
        Re: ssh fingerprint mismatch for one single client Fabien Roucaute <fabien.roucaute@free.fr> - 2020-09-20 20:40 +0200
        Re: ssh fingerprint mismatch for one single client tomas@tuxteam.de - 2020-09-21 09:20 +0200
          (solved) Re: ssh fingerprint mismatch for one single client Beco <rcb@beco.cc> - 2020-09-23 02:00 +0200
    Re: ssh fingerprint mismatch for one single client <tomas@tuxteam.de> - 2020-09-20 10:50 +0200

#227136 — ssh fingerprint mismatch for one single client

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [next] | [standalone]

#227138

[Multipart message — attachments visible in raw view] — view raw

On 9/19/20 6:28 PM, Beco wrote:
> 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.

>
> 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 <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

[toc] | [prev] | [next] | [standalone]

#227140

[Multipart message — attachments visible in raw view] — view raw

On Sat, 19 Sep 2020 at 18:46, Lucas Castro <lucas@gnuabordo.com.br> wrote:

>
> 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.

[toc] | [prev] | [next] | [standalone]

#227139

On 2020-09-19 22:28, Beco wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#227141

[Multipart message — attachments visible in raw view] — view raw

On Sat, 19 Sep 2020 at 18:55, mick crane <mick.crane@gmail.com> wrote:

>
> 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.

[toc] | [prev] | [next] | [standalone]

#227147

On 2020-09-19 23:42, Beco wrote:
> On Sat, 19 Sep 2020 at 18:55, mick crane <mick.crane@gmail.com> wrote:
> 
>> 
>> 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

[toc] | [prev] | [next] | [standalone]

#227151

On 2020-09-19 15:42, Beco wrote:
> On Sat, 19 Sep 2020 at 18:55, mick crane <mick.crane@gmail.com> wrote:

>> 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

[toc] | [prev] | [next] | [standalone]

#227157

	Hi.

On Sun, Sep 20, 2020 at 10:40:35AM +0200, tomas@tuxteam.de wrote:
> On Sat, Sep 19, 2020 at 06:28:29PM -0300, Beco wrote:
> > 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 <user@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!

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

[toc] | [prev] | [next] | [standalone]

#227175

[Multipart message — attachments visible in raw view] — view raw

Thank you all so much for thid new batch of input Mick, LARAC, David, Tomas
and Reco
Bellow I'll try to answer in a brief way all at once:




On Sun, 20 Sep 2020 at 00:34, mick crane <mick.crane@gmail.com> wrote:
> Is this Putty or something with keys on student's PC ?

No keys on PUTTY. Log in with password.

> 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 ?

> 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 -----




On sometime the last couple of days, LARAC (anonymous contributor) wrote:
>         Assuming it is the same server being contacted, which is likely
but not
> absolutely assured,

Ok, I'll test for that. (tcpdump suggested by Reco below)


> 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.



>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

> LARAC
> LARAC ends -----





On Sun, 20 Sep 2020 at 05:41, <tomas@tuxteam.de> wrote:
> 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.


> Could yout student just try
>   ssh -v <user@yourserver>

I've asked him, here it is the reply:



ubuntu@ubuntu:~$ ssh -v bob@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-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:+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.





> 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.


> Cheers
>  - t
> tomas ends -----





On Sun, 20 Sep 2020 at 05:47, Reco <recoverym4n@enotuniq.net> wrote:
> 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:

root@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)




> 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)


> 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.

[toc] | [prev] | [next] | [standalone]

#227176

[Multipart message — attachments visible in raw view] — view raw

On Sun, 20 Sep 2020 at 13:59, Beco <rcb@beco.cc> wrote:


> 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.

[toc] | [prev] | [next] | [standalone]

#227177

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

[toc] | [prev] | [next] | [standalone]

#227178

Le 20/09/2020 à 18:59, Beco a écrit :

> 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.
>

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.

[toc] | [prev] | [next] | [standalone]

#227200

[Multipart message — attachments visible in raw view] — view raw

On Sun, Sep 20, 2020 at 01:59:41PM -0300, Beco wrote:
> Thank you all so much for thid new batch of input Mick, LARAC, David, Tomas
> and Reco
> Bellow I'll try to answer in a brief way all at once:
> 
> 
> 
> 
> On Sun, 20 Sep 2020 at 00:34, mick crane <mick.crane@gmail.com> wrote:
> > Is this Putty or something with keys on student's PC ?
> 
> No keys on PUTTY. Log in with password.
> 
> > 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

[toc] | [prev] | [next] | [standalone]

#227265 — (solved) Re: ssh fingerprint mismatch for one single client

[Multipart message — attachments visible in raw view] — view raw

> 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
>


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.

[toc] | [prev] | [next] | [standalone]

#227159

[Multipart message — attachments visible in raw view] — view raw

On Sat, Sep 19, 2020 at 06:28:29PM -0300, Beco wrote:
> 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 <user@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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web