Beginner: Python, git, bash, etc ✅

The problem I don’t remember the ssh password and no idea how to get it back

The server host key now seems legitimate, matching one published on “GitHub’s SSH key fingerprints - GitHub Docs

You now see “publickey” is the single authentication option, same as me, which seems more like a legitimate github server (i.e. password is not allowed). So “maybe” there is some compromised device in your upstream internet providers. You might want to consider using a VPN.

debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey

So here you can see which key its trying to authenticate with…

debug1: Offering public key: /Users/Natsume/.ssh/id_ed25519 ED25519 SHA256:UFKLp/rN0o7czWwT5DukRK6TL2GyxKzfX8alHvlIimc explicit agent

but failed since you didn’t see…

debug1: Server accepts key ....................
debug1: Authentication succeeded (publickey).

So next I would look here (https://github.com/settings/keys) to just confirm you have a matching key configured. Below is a snapshot from one of my configured keys. In the red box below you should see your Key ID… SHA256:UFKLp/rN0o7czWwT5DukRK6TL2GyxKzfX8alHvlIimc

image

If not, copy/paste the contents of your file /Users/Natsume/.ssh/id_ed25519.pub to github SSH keys. Actually, I’m not sure whether the key id SHA256:UFKLp/rN0o7czWwT5DukRK6TL2GyxKzfX8alHvlIimc is meant to be private info or not. Once you finish troubleshooting it would probably be good to create new ssh-keys.

What should I do next? should I reinstall git?

No need to reinstall git. Thats not where the problem is. It “seems” like something is compromised upstream

  1. Double-check your public key loaded on github matches your the private key your local SSH is “offering” to authenticate with. Apart from the written instructions, maybe watch a few video tutorials.

  2. Change you DNS Resolver to use Google rather than your local ISP (and flush dns cache) in case that is where the issue is. Check using the domain name again… ssh -Tv git@github.com to see if you now get a legimitate server-host-key.

  3. Try a VPN, even if just on a trial for troubleshooting purposes. If ssh -Tv git@github.com then fails to report a legitimate server-host-key, then there may be something compromised on your local machine.

p.s. I hope you are not getting too discouraged by the issues. I think its actually SSH doing its job to keep your comms secure.

@kurianbenoy, to be specific, I think you are referring to the “SSH key passphrase” used to secure the private key, so called since you can spaces can be used for separating the words of a phrase. @Daniel, I forgot to ask if you were using this feature. fyi, I only use a passphrase to wrap a private-key stored a remote servers. Think of the passphrase similar to a password on a zipfile, that gives you access to a file (the private-key) stored inside the zip file.

2 Likes

Yeah correct I was referring to SSH key passphrase, or simply saying password you used to generate Ssh key.

Even if you don’t remember old password, create a new SSH key and use passphrase of that Ssh key.

1 Like

The password versus passphrase terminology is subtle and easy to misunderstand at first glance. Normally its not necessary to be pendantic, but since we are in the trenches troubleshooting, for reader clarity…

In the next image (copied from above), the password being asked for is for the “git” user on the “github” server - which of course, none of us know (and thats okay, we were wanting to test publickey access.)

But actually it shouldn’t be asking for a password since github have disabled password authentication, and the connected server was configured to allowed it…

  • debug1: Authentications that can continue: publickey,password,keyboard-interactive

(which is one reason to suspect a MITM, or alternatively a misconfigured github server)

Observe in the following description that the password is shared through the secure tunnel to be checked at the other end against the server’s password database. So a MITM can capture the password.

In contrast, passphrases are never sent over the wire. A passphrase is only used to unlock (unzip) the local file containing the private-key. For comparison, when a passphrase is used to lock a private key, the prompt looks like this…
image

2 Likes

Hi @bencoman and @kurianbenoy Thank you so much for helping me out here. I have to say I am overwhelmed with this git issue here. I will get back to it tomorrow.

I have used a previously created (2 days ago) key (I have not set nor used passphrase from the start), and this time there is some progress ( I have been authenticated) from the output of running ssh -Tv git@140.82.112.3. However, the git@github.com password is still blocking me from connecting to github.

(base) 13:21 ~ > ssh -Tv git@140.82.112.3
OpenSSH_8.6p1, LibreSSL 3.3.6
debug1: Reading configuration data /Users/Natsume/.ssh/config
debug1: /Users/Natsume/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 140.82.112.3 [140.82.112.3] port 22.
debug1: Connection established.
debug1: identity file /Users/Natsume/.ssh/id_ed25519 type 3
debug1: identity file /Users/Natsume/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.6
debug1: Remote protocol version 2.0, remote software version babeld-24a5c4c2
debug1: compat_banner: no match: babeld-24a5c4c2
debug1: Authenticating to 140.82.112.3:22 as 'git'
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
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: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host '140.82.112.3' is known and matches the ED25519 host key.
debug1: Found key in /Users/Natsume/.ssh/known_hosts:2
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: /Users/Natsume/.ssh/id_ed25519 ED25519 SHA256:UFKLp/rN0o7czWwT5DukRK6TL2GyxKzfX8alHvlIimc explicit agent
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,sk-ssh-ed25519-cert-v01@openssh.com,sk-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,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,ssh-ed25519,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256,rsa-sha2-512,rsa-sha2-256,ssh-rsa>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/Natsume/.ssh/id_ed25519 ED25519 SHA256:UFKLp/rN0o7czWwT5DukRK6TL2GyxKzfX8alHvlIimc explicit agent
debug1: Server accepts key: /Users/Natsume/.ssh/id_ed25519 ED25519 SHA256:UFKLp/rN0o7czWwT5DukRK6TL2GyxKzfX8alHvlIimc explicit agent
debug1: Authentication succeeded (publickey).
Authenticated to 140.82.112.3 ([140.82.112.3]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: pledge: filesystem full
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: client_input_hostkeys: searching /Users/Natsume/.ssh/known_hosts for 140.82.112.3 / (none)
debug1: client_input_hostkeys: searching /Users/Natsume/.ssh/known_hosts2 for 140.82.112.3 / (none)
debug1: client_input_hostkeys: no new or deprecated keys from server
debug1: Sending environment.
debug1: channel 0: setting env LC_TERMINAL_VERSION = "3.4.16"
debug1: channel 0: setting env LC_CTYPE = "UTF-8"
debug1: channel 0: setting env LC_TERMINAL = "iTerm2"
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
Hi EmbraceLife! You've successfully authenticated, but GitHub does not provide shell access.
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 2268, received 2344 bytes, in 0.7 seconds
Bytes per second: sent 3456.2, received 3572.0
debug1: Exit status 1
(base) 13:24 ~ > ssh git@github.com
git@github.com's password:
Permission denied, please try again.
git@github.com's password:
Permission denied, please try again.
git@github.com's password:
git@github.com: Permission denied (publickey,password,keyboard-interactive).
(base) 13:25 ~ >
(base) 13:25 ~ >

Could setting IP address manually be the solution? but I have no idea how to do it, nor did I find anything useful online.

Seems like your ssh keys are now working fine with Github. Github does not provide a ssh login access, instead it uses ssh keys to securely connect to the hosted git server.

By getting the reply above from ssh -T git@github.com, you can be rest assured that your ssh keys and github expectations are in sync now.

At this point, your keys are working and you should be able to run git commands that interact with Github, for eg. things like git clone, git push, git pull etc.

Try cloning a private repo(that you have access to) from Github using the SSH method to verify that everything’s working well.

There’s no point to try to ssh login into Github as you’re doing below, since it’s not a remote server that one can login to.

1 Like

Thanks for your help!

However, the problem is that whenever I try git push/ clone, the git@github.com password: pop up automatically and I have never set or used such password before.

Hmm, that could be because you’ve been using https url for cloning. Could you try running the following commands and paste the output here.

ssh -T git@github.com
cd /tmp && git clone git@github.com:fastai/fastai.git

If the first command succeeds without interaction, then the second should work accordingly as well. If not, then it might be something very odd going on. Let us know.

1 Like

After running the first line ssh -T git@github.com I got the following

I just wonder could changing IP address really help from the post above ?

I run the command and got the following result

(base) 22:11 ~ > ssh -Tv git@github.com
OpenSSH_8.6p1, LibreSSL 3.3.6
debug1: Reading configuration data /Users/Natsume/.ssh/config
debug1: /Users/Natsume/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to github.com port 22.
debug1: Connection established.
debug1: identity file /Users/Natsume/.ssh/id_ed25519 type 3
debug1: identity file /Users/Natsume/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6
debug1: compat_banner: match: OpenSSH_7.6 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug1: Authenticating to github.com:22 as 'git'
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
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: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-rsa SHA256:rEmlJenVMSL5GVemSY0Gk8WGw6B4ege4J85M+vup8R0
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /Users/Natsume/.ssh/known_hosts:1
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: /Users/Natsume/.ssh/id_ed25519 ED25519 SHA256:UFKLp/rN0o7czWwT5DukRK6TL2GyxKzfX8alHvlIimc explicit agent
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/Natsume/.ssh/id_ed25519 ED25519 SHA256:UFKLp/rN0o7czWwT5DukRK6TL2GyxKzfX8alHvlIimc explicit agent
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
git@github.com's password:

I have run ssh -Tv git@github.com several times with different locations, and got the same result

(base) 22:14 ~ > ssh -Tv git@github.com
OpenSSH_8.6p1, LibreSSL 3.3.6
debug1: Reading configuration data /Users/Natsume/.ssh/config
debug1: /Users/Natsume/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to github.com port 22.
debug1: Connection established.
debug1: identity file /Users/Natsume/.ssh/id_ed25519 type 3
debug1: identity file /Users/Natsume/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6
debug1: compat_banner: match: OpenSSH_7.6 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug1: Authenticating to github.com:22 as 'git'
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
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: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-rsa SHA256:rEmlJenVMSL5GVemSY0Gk8WGw6B4ege4J85M+vup8R0
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /Users/Natsume/.ssh/known_hosts:1
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: /Users/Natsume/.ssh/id_ed25519 ED25519 SHA256:UFKLp/rN0o7czWwT5DukRK6TL2GyxKzfX8alHvlIimc explicit agent
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/Natsume/.ssh/id_ed25519 ED25519 SHA256:UFKLp/rN0o7czWwT5DukRK6TL2GyxKzfX8alHvlIimc explicit agent
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
git@github.com's password:

Not quite at that point yet. It only worked direct to a known IP address, not to the domain “github.com

Awesome. Thats a really good step. This proves your keys are good and you are hitting a legitimate github server.

$ ssh -Tv git@github.com
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive

So “password” being available here as an “Authentication method” hints this server doesn’t belong to github, thus you should suspect your DNS resolution from “github.com to IP address” has been compromised. This could be either upstream or on your machine, so we need to discriminate between those.

Could setting IP address manually be the solution?

As last resort yes, but first should examine your DNS. If your DNS resolution is compromised, then that affects the security of your whole machine, so you should try to fix that first. The general scenarios are:

  1. The DNS servers of your ISP have been compromised/poisoned.
  2. The network packets sent to DNS servers are being intercepted and modified.
  3. Something on your local machine has been compromised.

These are in order of easiest to examine and isolate. The first case can be tested by changing which DNS servers do your DNS resolution. To use google’s DNS servers rather than your ISP’s DNS servers, follow instructions here…

2 Likes

Thank you @bencoman for pointing out the difference. I have been using SSH merely as user, yet it now looks I should put more effort to understand this.

1 Like

Great news! Right inside this page, lies the solution to my git problem!

Hello guys @bencoman @kurianbenoy @suvash, thank you all so much for helping me out!

Being cut out from using github is like being cut off from learning and sharing codes with the world, and most importantly from fastai community, which is unthinkable.

Luckily, I have wonderful support and help from all you guys and finally @suvash has been amazingly kind and offered me a video call to help me troubleshoot the git problem. Thank you so so much, Suvash!

The source of the problem (I will try to describe it as clear as I could) is that in some places of the world, people are blocked from google and now github completely (blocking port 25). The solution Suvash provided is that if people choose to connect to github on the port (port 443) where the rest websites are based, then the blocking won’t work.

You guys are amazing, thank you!

4 Likes

No worries Daniel ! I had some free hours during the day, and figured that I could try to help and sort this out a bit. Great that we were able to figure this out together.

Yeah, I haven’t really seen this in a while, but some ISP firewalls still like to ban/intercept/drop packets on SSH(22) ports. Good that Github allows connecting over the HTTPS(443) port, which solved your problem.

4 Likes

¡ Hello everyone! I’m doing JH’s tutorial to install nbdev and create a sample card package. I have a recurring git problem that I have “suffered” before and I don’t quite know how to get out of it. When I want to clone with the terminal the repository just created on Github, I get the following error message: Cloning in 'my-nbdev-repo'... git@github.com: Permission denied (public key). fatal: could not read from remote repository. I have tried to create new public and private ssh keys, but I can’t clone the repository. Does anyone know how to deal with this problem?

Read the several posts between myself and Daniel, starting here.

2 Likes

I am writing here because I saw you mention that you recommend that we use mamba to install packages because PIP doesn’t generally install packages in a way that works on GPUs.

I just wanted to flag that I’d used pip as my package manager when installing the course and everything seems to work fine for me.

My environment is Windows 11 running WSL, and my GPU is an RTX 3070Ti.
I’ve attached the results of the nvidia-smi monitoring as an image to make sure that the GPU is actually working and it’s not just me mistaking something for GPU use.

1 Like

Hello,
I just started this course and I’m a little confused on how you did this.


It looks like you are cloning into your windows Document folder. But then it says that you cloned into a git folder. And then you go into your WSL and open it up directly in VS Code but when I cloned it, it didnt automatically create a folder in git/ in my WSL.