GitHub to be trusted their own SSH host key?
Jun 11th, 2023 by miki

A May 24th 2023 change of GitHub’s RSA SSH host key just hit me on an older, less used, system doing a git clone. The change was prompted by an unintended exposure of the private part of the host key by GitHub itself.’s RSA SSH private key was briefly exposed in a public GitHub repository

Github blog-post, “We updated our RSA SSH host key”, 2023-03-23

I’m getting even more reluctant to trust a large organization where such a thing can happen. Additionally they didn’t communicate about this in a way that caught my attention. And now that it has my attention, they do not want to share the specifics about the incident to enable assessment of impact (like exposure duration, popularity of repository etc).

Below is the manual recovery with explanations of what happens and why. I don’t like the way the official blog-post instructs users to retrieving the validated host key in a non-visible way, without human eye balls doing the validation. This is the only chance in the process for injecting human trust into the validation of the host key, don’t skip it!

Consequence #1: fatal MitM warning
When an SSH server’s host key is different to a connecting client (system) compared to what the system has previously seen and acknowledged by the user to be a valid key from the intended counterpart (you do check those host key fingerprint strings, right? If not; PHComp help, WinSCP help), it obviously should and do warn the user about this. Whether the change is of malicious origin or not, is up to the user to investigate. So with OpenSSH this happens;

$ git clone
Cloning into 'name-suggestion-index'...
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
Please contact your system administrator.
Add correct host key in <~>/.ssh/known_hosts to get rid of this message.
Offending RSA key in <~>/.ssh/known_hosts:17
  remove with:
  ssh-keygen -f "<~>/.ssh/known_hosts" -R ""
RSA host key for has changed and you have requested strict checking.
Host key verification failed.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Remedy #1: remove known host keys for domain (pr. OpenSSH instruction)
Remove host keys associated with domain using -R option to ssh-keygen (default for -f is the UserKnownHostsFile config keyword with default ~/.ssh/known_hosts, so no need to specify that):

$ ssh-keygen -R
# Host found: line 17
# Host found: line 18
# Host found: line 19
<~>/.ssh/known_hosts updated.
Original contents retained as <~>/.ssh/known_hosts.old

Consequence #2: non-fatal domain and IP mismatch
Now, because host key references are cached for both the domain and IP there are still mismatches caused by the key exchange choosing ECDSA host key and the key associated with the IP address is the old RSA key. This is prompted during each connection attempt:

$ git clone
Cloning into 'name-suggestion-index'...
Warning: the ECDSA host key for '' differs from the key for the IP address ''
Offending key for IP in <~>/.ssh/known_hosts:63
Matching host key in <~>/.ssh/known_hosts:72
Are you sure you want to continue connecting (yes/no)? yes
remote: Enumerating objects: 153255, done.
remote: Counting objects: 100% (177/177), done.
remote: Compressing objects: 100% (103/103), done.
remote: Total 153255 (delta 103), reused 121 (delta 74), pack-reused 153078
Receiving objects: 100% (153255/153255), 550.17 MiB | 2.39 MiB/s, done.
Resolving deltas: 100% (111423/111423), done.

Remedy #2: remove known host keys for IPs
To get rid of the mismatch warning, the known host keys associated with IP addresses needs to be removed also. Potentially any of the listed endpoint IP addresses used with an RSA host key on the system earlier will now conflict with the ECDSA from server, requiring removal:

$ ssh-keygen -R
# Host found: line 63
<~>/.ssh/known_hosts updated.
Original contents retained as <~>/.ssh/known_hosts.old

$ ssh-keygen -R
# Host found: line 161
<~>/.ssh/known_hosts updated.
Original contents retained as <~>/.ssh/known_hosts.old

After remedy
Now, the SSH client will see an unknown host key and prompt for validation. Be sure to verify the presented host key with the officially communicated one (from doc. article or API):
$ git clone
Cloning into 'name-suggestion-index'...
The authenticity of host ' (' can't be established.
ECDSA key fingerprint is SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added ',' (ECDSA) to the list of known hosts.
remote: Enumerating objects: 153152, done.
remote: Counting objects: 100% (183/183), done.
remote: Compressing objects: 100% (83/83), done.
Receiving objects: 100% (153152/153152), 550.22 MiB | 1.42 MiB/s, done.
remote: Total 153152 (delta 109), reused 158 (delta 100), pack-reused 152969
Resolving deltas: 100% (111352/111352), done.
GNOME Shell attach-modal-dialogs true?!
Jun 2nd, 2023 by miki

While once again being annoyed by the obnoxious way modern GNOME handles in-application dialogues (fx. Nautilus’ Properties dialog) as modal (ie. freezes the parent window) AND even prevents movement of the dialogue relative to the parent I did some searching which revealed a partly solution!

This was also complained about in a 2017 LibreOffice bug report which concluded that the immobility is a GNOME 3 desktop default behaviour caused by the setting attach-modal-dialogs.

Details in the related GNOME bug report shows how to disable this by modifying gsettings;

In a regular upstream GNOME session, `gsettings set attach-modal-dialogs false`, a schema of ‘’ for the classic session and afaik ‘org.gnome.mutter’ for a Ubuntu-patched GNOME.

Now knowing which term to search for, lots of discussion about this shows up (including posts similar to this), the best write up of the mitigation is probably this askubuntu question. And the mother opinionated Ubuntu bug report is this where Ubuntu officially states;

We do not consider Gnome’s defaults in this area unreasonable.

But the reason for this behaviour? Seems to be unknown as even this 2018 bug report on gnome-shell hasn’t received any official answer or comment about why this would be a sane default. Go figure…

On Ubuntu 20.04 and similar distributions turn off GNOME’s attach-modal-dialogs feature by doing;

$ gsettings set org.gnome.mutter attach-modal-dialogs false

Or if you like the mouse; install & launch gnometweaks and click “Windows” -> “Attach Modal Dialogues”;

Oh, and remember to read the Nielsen Norman Group article “Modal & Nonmodal Dialogs: When (& When Not) to Use Them” (summary: Modal dialogs interrupt users and demand an action. They are appropriate when user’s attention needs to be directed toward important information).

2023-07-30: add gnome-tweaks approach

»  Substance:WordPress   »  Style:Ahren Ahimsa
© 2023 Mikkel Kirkgaard Nielsen, contents CC BY-SA 4.0