On Sun, 29 Nov 2020 at 22:59, Alex Beamish <talexb@gmail.com> wrote:
On Sat, Nov 28, 2020 at 11:19 PM Giles Orr via talk <talk@gtalug.org> wrote:
Hi Alex.
On Sat, 28 Nov 2020 at 16:50, Alex Beamish via talk <talk@gtalug.org> wrote:
Hi All,
This is probably a blindingly obvious question, but I'm a little stumped. I've done a little work for local business, setting up a Linux server (Ubuntu), developing some code and pushing it to github. It's all worked wonderfully until a few weeks ago, when he had someone in to do something to the network. Since then, Things Are Broken in ways that I don't understand.
When I try to do anything with github, I see the response
Received disconnect from 140.82.113.3 port 22:2: Connection blocked because server only allows public key authentication. Please contact your network administrator.
Because I was worried I'd borked my account, this afternoon I tried again, creating a brand-new account and ssh-ing in .. and still got the same result.
My github account works fine from my own machine, and also from my web provider (pair.com), so I'm guessing there's something going on within my client's network. Suggestions gratefully received.
I apologize if this is something you've already looked at, but the #1 Google hit for "Connection blocked because server only allows public key authentication" does look relevant:
https://superuser.com/questions/1466177/connection-blocked-because-server-on...
Giles, Hugh,
Thank you both for your responses. I am beginning to suspect that there is some network thing that's breaking ssh.
From my own machine, the result of ssh -vT git@github.com looks like this: it works fine.
OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f 31 Mar 2020 debug1: Reading configuration data /home/tab/.ssh/config debug1: /home/tab/.ssh/config line 22: Applying options for * debug1: /home/tab/.ssh/config line 338: Applying options for * debug1: /home/tab/.ssh/config line 339: Deprecated option "useroaming" 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 github.com [140.82.113.3] port 22. debug1: Connection established. debug1: identity file /home/tab/.ssh/id_rsa type -1 debug1: identity file /home/tab/.ssh/id_rsa-cert type -1 debug1: identity file /home/tab/.ssh/id_dsa type -1 debug1: identity file /home/tab/.ssh/id_dsa-cert type -1 debug1: identity file /home/tab/.ssh/id_ecdsa type -1 debug1: identity file /home/tab/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/tab/.ssh/id_ecdsa_sk type -1 debug1: identity file /home/tab/.ssh/id_ecdsa_sk-cert type -1 debug1: identity file /home/tab/.ssh/id_ed25519 type -1 debug1: identity file /home/tab/.ssh/id_ed25519-cert type -1 debug1: identity file /home/tab/.ssh/id_ed25519_sk type -1 debug1: identity file /home/tab/.ssh/id_ed25519_sk-cert type -1 debug1: identity file /home/tab/.ssh/id_xmss type -1 debug1: identity file /home/tab/.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1 debug1: Remote protocol version 2.0, remote software version babeld-b85a2946 debug1: no match: babeld-b85a2946 debug1: Authenticating to github.com:22 as 'git' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256 debug1: kex: host key algorithm: rsa-sha2-512 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: ssh-rsa SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8 debug1: Host 'github.com' is known and matches the RSA host key. debug1: Found key in /home/tab/.ssh/known_hosts:3 debug1: rekey out after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey in after 134217728 blocks debug1: Will attempt key: /home/tab/.ssh/music2012 RSA SHA256:JzHBQSQHReaDXiXIEO4W3QtW/cqqoab6xuWt2V4eP30 agent debug1: Will attempt key: /home/tab/.ssh/id_rsa debug1: Will attempt key: /home/tab/.ssh/id_dsa debug1: Will attempt key: /home/tab/.ssh/id_ecdsa debug1: Will attempt key: /home/tab/.ssh/id_ecdsa_sk debug1: Will attempt key: /home/tab/.ssh/id_ed25519 debug1: Will attempt key: /home/tab/.ssh/id_ed25519_sk debug1: Will attempt key: /home/tab/.ssh/id_xmss debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss> debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering public key: /home/tab/.ssh/music2012 RSA SHA256:JzHBQSQHReaDXiXIEO4W3QtW/cqqoab6xuWt2V4eP30 agent debug1: Server accepts key: /home/tab/.ssh/music2012 RSA SHA256:JzHBQSQHReaDXiXIEO4W3QtW/cqqoab6xuWt2V4eP30 agent debug1: Authentication succeeded (publickey). Authenticated to github.com ([140.82.113.3]:22). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: pledge: network debug1: Requesting authentication agent forwarding. debug1: Sending environment. debug1: Sending env LANG = en_CA.UTF-8 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 Hi talexb! You've successfully authenticated, but GitHub does not provide shell access. debug1: channel 0: free: client-session, nchannels 1 Transferred: sent 2856, received 2468 bytes, in 0.1 seconds Bytes per second: sent 26439.1, received 22847.2 debug1: Exit status 1
I have 'ForwardAgent yes' in my ~/.ssh/config, so when I ssh to my client's machine, my authentication comes with me. But on that machine, the response to the same test is now different than it was three weeks ago:
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017 debug1: Reading configuration data /home/web/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to github.com [140.82.112.4] port 22. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file /home/web/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/web/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/web/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/web/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/web/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/web/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/web/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/web/.ssh/id_ed25519-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 debug1: Remote protocol version 2.0, remote software version babeld-b85a2946 debug1: no match: babeld-b85a2946 debug1: Authenticating to github.com:22 as 'git' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256 debug1: kex: host key algorithm: rsa-sha2-512 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: ssh-rsa SHA256:CJ1i1swJd0SjXdfpoh7CCQrmOp04K4zor8rYP1NlegA @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: POSSIBLE DNS SPOOFING DETECTED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ The RSA host key for github.com has changed, and the key for the corresponding IP address 140.82.112.4 is unknown. This could either mean that DNS SPOOFING is happening or the IP address for the host and its host key have changed at the same time. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is SHA256:CJ1i1swJd0SjXdfpoh7CCQrmOp04K4zor8rYP1NlegA. Please contact your system administrator. Add correct host key in /home/web/.ssh/known_hosts to get rid of this message. Offending RSA key in /home/web/.ssh/known_hosts:10 remove with: ssh-keygen -f "/home/web/.ssh/known_hosts" -R "github.com" RSA host key for github.com has changed and you have requested strict checking. Host key verification failed.
To make sure that my account wasn't broken in some other way, this weekend I created another brand new account on my client's machine and tried the same test command -- I got the same result.
I also tried ssh'ing to my web provider (pair.com) and then tried the same test command -- and got pretty much the same good response I got from my local machine. This tells me that my keys and my github account are working fine -- it's just something on my client's network that is interfering with the traffic.
Because I know enough about ssh to get my job done, but not a lot more, I wanted to confirm I wasn't missing something really obvious, some config file switch that needed changing. Again, thank you all for your patience with me on this.
Hi Alex. The first thing that occurs to me - and again, this is blatant speculation with no research behind it - is that those two big warnings might indicate that the new network equipment at your client's place is trying to MITM SSH. Not something I've heard of before, but corporations want to see inside any encrypted packets flowing in and out of their networks. If you want to prove/disprove that (I'd wait for confirmation from someone else that this is a remotely sane idea), you're going to learn a lot more about both SSH and network firewalls ... -- Giles https://www.gilesorr.com/ gilesorr@gmail.com