Repository navigation
Add additional troubleshooting for non-standard SSH keyfile name #42109
Description
Code of Conduct
- I have read and agree to the GitHub Docs project's Code of Conduct
What article on docs.github.com is affected?
https://docs.github.com/en/authentication/troubleshooting-ssh/error-permission-denied-publickey
What changes are you suggesting?
This proposed edit is to include steps to specify the exact key filename as part of the ssh -vT git@github.com command while troubleshooting SSH connection issues. This resolves the issue of a user experiencing a git@github.com: Permission denied (publickey). error while following the linked troubleshooting article if they chose to use a non-default filename for their keyfile.
The expected outcome is a user will have clarity on how to specify the SSH keyfile while troubleshooting, preventing false-positive error messages that detract from the original troubleshooting flow.
I'll be opening a PR momentarily that links to this issue, per process.
Additional information
No response
Activity
welcome commentedon Dec 31, 2025
Thanks for opening this issue. A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.
github-actions commentedon Feb 17, 2026
A stale label has been added to this issue, because it has been open for 30 days with no activity. If you think this issue should remain open, please add a new comment.
github-actions commentedon Mar 23, 2026
A stale label has been added to this issue, because it has been open for 30 days with no activity. If you think this issue should remain open, please add a new comment.
subatoi commentedon Aug 27, 2026
@kmanwar89 Hello, and please accept my apologies that this wasn't addressed when you raised it.
I note that #45636 has been raised. I don't see any problem with what you're proposing, but I don't think it needs to reproduce the whole example, and can just be a sentence. I'd like to give you the opportunity to raise a PR yourself so you can get the attribution, or if you prefer, feel free to add a review to 45636.
Thank you 🙇
kmanwar89 commentedon Aug 28, 2026
Thanks @subatoi - I'd be happy to raise another PR. A single sentence edit might be OK, but I would advocate that the original commit I raised helps in both understanding the pass, and fail, scenarios with example output, which is helpful for developers.
My original issue was actually #42110 so I imagine I would want to link that as well, correct? Would it make sense to re-open that existing PR and work through edits in there, or would you like an entirely new PR with links instead?
subatoi commentedon Aug 28, 2026
@kmanwar89 I'm afraid the answer would remain the same as was already noted for such a detailed addition; there's only so much we can expect one article on GitHub docs specifically to cover. I would, however, be happy to accept a PR similar to #45636.
If you're happy to do that, I'd recommend opening a new PR and marking it as
closesthis issue. Thank you!kmanwar89 commentedon Sep 1, 2026
I'm not quite sure I understand the resistance to well-written, thorough documentation here. GitHub is a platform for millions of developers, and developers do not shy away from details, verbosity, or in-depth explanations.
That said, I understand the point you're making. To be clear, would the request here simply be a one-line update, with no logs or examples? Are said logs or examples available in other articles that can be hyperlinked? I feel strongly that one should advocate for the correct level of details, especially human-written details, to help other developers and users towards a successful result. Artificially shortening those details for an arbitrary reason undermines the time and effort taken to write the PR.
If we aren't able to come to an agreement, that's totally fine, and I'll agree for the author under 45636 to submit their PR and receive proper attribution.
subatoi commentedon Sep 1, 2026
@kmanwar89 As you may imagine, we receive a huge amount of input into what content should go on docs.github.com, and decisions are made based on research and evidence. I would also add that our readers are not all developers. In this instance, I don't see enough evidence to suggest this is something we should document in detail, and provide logs about. Truthfully, I'm not even entirely sure it's something a significant number of users would ever encounter, but adding a potentially useful sentence is harmless (and worth it if it helps even a small fraction of users); adding a large amount of content that would make the page less readable without a payoff is not.
I would be more than happy to be proven wrong, and you are very welcome to open a community discussion about this. If it gains traction and the community team report back, I would happily approve adding the more detailed content to the docs after that time, but in the interim, I would close this issue out and #45636. Alternatively, the way forward will be to approve #45636.
subatoi commentedon Sep 3, 2026
I'm going to go ahead and approve #45636, which will close this out when merged, but please do feel free to raise a community discussion per my comment above, and as I mentioned, we can explore an expansion of the content. Thanks for your interest in the GitHub docs, and sorry this wasn't exactly the answer you were looking for.
kmanwar89 commentedon Sep 4, 2026
Saying the "majority of readers" on a platform like GitHub aren't developers seems incredibly obtuse. Do what you feel is best, but your comment seems a bit detached from reality.