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.cr...@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, <to...@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 b...@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-poly1...@openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1...@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 <recovery...@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.