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.
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=0x5A107A425102382ACreation 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.