Add Host key verification failed page

[jsoref]

Why:

Closes: #19283

What's being changed (if available, include any code snippets, screenshots, or gifs):

https://docs-25401-51ea48.preview.ghdocs.com/en/authentication/troubleshooting-ssh/error-host-key-verification-failed

Adding an article for Host key verification failed and a link to it

Check off the following:

• I have reviewed my changes in staging, available via the View deployment link in this PR's timeline.

  • For content changes, you will also see an automatically generated comment with links directly to pages you've modified. The comment won't appear if your PR only edits files in the data directory.

• For content changes, I have completed the self-review checklist.

[github-actions]

Automatically generated comment ℹ️

This comment is automatically generated and will be overwritten every time changes are committed to this branch.

The table contains an overview of files in the content directory that have been changed in this pull request. It's provided to make it easy to review your changes on the staging site. Please note that changes to the data directory will not show up in this table.

---

Content directory changes

You may find it useful to copy this table into the pull request summary. There you can edit it to share links to important articles or changes and to give a high-level overview of how the changes in your pull request support the overall goals of the pull request.

Source	Preview	Production	What Changed
New file: authentication/troubleshooting-ssh/error-host-key-verification-failed.md	fpt ghec	fpt ghec
authentication/troubleshooting-ssh/index.md	fpt ghec ghes@ 3.10 3.9 3.8 3.7 3.6 ghae	fpt ghec ghes@ 3.10 3.9 3.8 3.7 3.6 ghae

---

fpt: Free, Pro, Team
ghec: GitHub Enterprise Cloud
ghes: GitHub Enterprise Server
ghae: GitHub AE

[cmwilson21]

👋 @jsoref Thanks so much for opening a PR! I'll get this triaged for review ⚡

[isaacmbrown]

Hi @jsoref, thanks for the PR! This article looks like it adds some useful context on the error, but it would be nice to offer some resolution steps for the second paragraph (the server has changed its keys).

We published some steps in the GitHub blog recently: https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/#what-you-can-do

What do you think about incorporating this advice into the article?

[jsoref]

I'm open to it. I don't suppose you'd be able to provide the precise content to copy paste?

Alternatively, this could be merged and then you could add that content separately.

My goal here is to start the process so that others can expand things later, but at the very least give people something which should be better than nothing.

[isaacmbrown]

Hi @jsoref, no worries, that make sense. We'll review this PR as is, and I'll open a follow-up issues internally for the next steps.

[isaacmbrown]

Hey @jsoref Thank you for contributing this article and sorry for the delay in getting it reviewed 🙇

I added some suggestions below -- in general I suggest we add a bit of focus on GitHub specifically. Let me know if you want to discuss anything further

[isaacmbrown]

There's some duplication here

Is there a way we can use language that is slightly more beginner-friendly than 'client' here? For example, could we just say "the server to which you're connecting"? Alternatively, can we be slightly more explicit as to what we mean (e.g. "your SSH client")?

Suggested change

	This means that the key that the server to which your client is connecting presented a key that doesn't match the keys that your client has seen in the past.
	This error means that the server to which your client is connecting presented a key that doesn't match the keys that your client has seen in the past.

[jsoref]

So, client here on average, more or less, means git. In general that's effectively git.exe or /usr/bin/git, although if someone is using jgit, or go-git or dulwich (which is sometimes used, e.g. by Mercurial to talk to git via HgGit), libgit2, or js-git, it could mean one of those.

But, it could mean any ssh implementation in case someone is actually just connecting directly via ssh.

[jsoref]

Basically, I'm using client to cover for the fact that I don't know if they're using git (or an implementation) or ssh (or an implementation).

[jsoref]

And, if they're using git (or an implementation) or worse a wrapper for git, like an IDE (whether that's IntelliJ, VSCode, Eclipse, or something else) -- I can't know that they'll really know what ssh is or that they're using it.

[isaacmbrown]

I think "the server to which you're connecting" might be a useful abstraction here, but again go with your preference

[jsoref]

I'll take that, but it still leaves a client at the end of the sentence.

One might consider:

-doesn't match the keys that your client has seen in the past.
+doesn't match the keys that it has used in the past.

But this could easily be a globally incorrect statement while technically accurate from the perspective of the local client. And I'm not terribly comfortable w/ that tradeoff. (Can you tell I like my precision?)

But, let's try a variant of that and see what you think.

[isaacmbrown]

I think it's worth mentioning the case where the server hasn't actually recently changed its keys, but the key isn't in your known hosts file for whatever reason. Again we can keep this GitHub focused.

Suggested change

	You can find an up-to-date list of {% data variables.product.company_short %}'s public SSH keys on {% data variables.product.prodname_docs %}. You may need to add these keys to your `~/.ssh/known_hosts` file. For more information, see "[AUTOTITLE](/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints)."

[jsoref]

I should note that ~/.ssh/known_hosts is mostly a Unix-ism. But I don't have the energy to think about an alternative suggestion (this is mostly a problem for Windows where ~ is mostly not a thing).

I'm going to take this suggestion, and basically each suggestion where I added 👍 and 👀 -- as a pair the 👀 are a reminder to me to think about and the 👍 is a thing I like -- once I've incorporated a thing, I'll remove the 👀.

[isaacmbrown]

That's a good point, feel free to simplify to "known_hosts file"! If we wanted to make that change then I think the article we're linking to should do the heavy lifting of explaining the file's location across different OSs

[jsoref]

Hmm, yeah, that file is defective, but I really want to leave it as outside the scope of this PR. I'll simplify this content to known_hosts. It does currently mention ~/.ssh/known_hosts, so for the Unix case, it is no worse wrt information after I add this content (albeit w/ one level of indirection):

docs/content/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints.md

Line 25 in d0559d6

You can add the following ssh key entries to your `~/.ssh/known_hosts` file to avoid manually verifying {% data variables.product.prodname_dotcom %} hosts:

If I was going to go on a spree, I'd also change 3 instances of github.com to {% data variables.command_line.codeblock %} in:

docs/content/authentication/troubleshooting-ssh/using-ssh-over-the-https-port.md

Lines 24 to 73 in d0559d6

	$ ssh -T -p 443 git@ssh.github.com
	> Hi USERNAME! You've successfully authenticated, but GitHub does not
	> provide shell access.
	```
	{% note %}
	**Note**: The hostname for port 443 is `ssh.{% data variables.command_line.backticks %}`, not `{% data variables.command_line.backticks %}`.
	{% endnote %}
	If that worked, great! If not, you may need to [follow our troubleshooting guide](/authentication/troubleshooting-ssh/error-permission-denied-publickey).
	Now, to clone the repository, you can run the following command:
	```
	git clone ssh://git@ssh.{% data variables.command_line.codeblock %}:443/YOUR-USERNAME/YOUR-REPOSITORY.git
	```
	## Enabling SSH connections over HTTPS
	If you are able to SSH into `git@ssh.{% data variables.command_line.backticks %}` over port 443, you can override your SSH settings to force any connection to {% data variables.location.product_location %} to run through that server and port.
	To set this in your SSH configuration file, edit the file at `~/.ssh/config`, and add this section:
	```
	Host {% data variables.command_line.codeblock %}
	Hostname ssh.{% data variables.command_line.codeblock %}
	Port 443
	User git
	```
	You can test that this works by connecting once more to {% data variables.location.product_location %}:
	```shell
	$ ssh -T git@{% data variables.command_line.codeblock %}
	> Hi USERNAME! You've successfully authenticated, but GitHub does not
	> provide shell access.
	```
	## Updating known hosts
	The first time you interact with {% data variables.product.prodname_dotcom %} after switching to port 443, you may get a warning message
	that the host wasn't found in `known_hosts`, or that it was found by another name.
	```ShellSession
	> The authenticity of host '[ssh.github.com]:443 ([140.82.112.36]:443)' can't be established.
	> ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU.
	> This host key is known by the following other names/addresses:
	> ~/.ssh/known_hosts:32: github.com

(This is the only other file that mentions it.)

But, I really don't. I have more than enough other tasks to work on...

[jsoref]

Btw, should I expect the Azure - Deploy Preview Environment to fail each time I push? (This feels like a relatively new thing.)

[cmwilson21]

@jsoref That preview check should be fixed now 👍

[jsoref]

@cmwilson21 #25401 (comment) still seems unhappy? 😦

[isaacmbrown]

@jsoref I updated from main and the job seems to be working now

[isaacmbrown]

@jsoref Thanks for the updates, looks good to me! 🚀 I'm assuming you're ready for this to be merged now but let us know if you're planning any further updates. Good to work with you on this 🖖

[jsoref]

I'm fine with you merging it. I can always make another PR.

[github-actions]

Thanks very much for contributing! Your pull request has been merged 🎉 You should see your changes appear on the site in approximately 24 hours. If you're looking for your next contribution, check out our help wanted issues ⚡