Claiming this as the SRE on clinic duty -- thanks all for the suggestions.

I chatted with @Kbrown and we agreed troubleshooting this in real-time is probably going to be more effective than via slower roundtrips on Phab, but I'll keep the ticket updated for posterity. For now we're going to leave it until Monday, when Karen will be back on the right machine.

@Kbrown Whenever you have a moment, some troubleshooting information to collect -- please open a terminal on that computer, run each of these commands, and just paste all the results here (or in a phab paste, and paste the link here). None of the output is sensitive or private.

• First let's make sure your SSH keys are in the right place and your configuration file looks right:
  • ls ~/.ssh
  • cat ~/.ssh/config
• Then, try this command, which just attempts to connect you as usual but with a little extra debugging information:
  • ssh -v mwmaint2002.codfw.wmnet

Then we'll chat again on Monday and use that information to get this sorted out. (I'm happy to hang onto this ticket after the end of the clinic duty shift.)

After that, I agree with both @Reedy and @Aklapper that we should take a look at both the T&S-internal documentation, and the decom workflow, to make it easier on everyone in the long run. But I'd like to focus on getting Karen's work unblocked first.

All set! For posterity, the issue turned out to be twofold -- one, exactly as @Reedy guessed, SSH was one version too old to understand ProxyJump so we replaced it with the equivalent ProxyCommand (and I verified there are no known security vulnerabilities for the version in use) and two, the SSH key filename didn't match the one in the example config, so we corrected it, and @Kbrown was able to connect. (Please do reopen this, or file another under SRE-Access-Requests, if you have any more trouble!)

Karen has also already taken care of updating the T&S docs to explain about using mwmaint1002 most of the time but mwmaint2002 during a switchover when the "do not use this server" MOTD pops up.

Finally, I'll open a separate task to see if we can improve documentation updates in the decom workflow. I'm not sure if {{obsolete}} on the bast4001 fingerprint page specifically would have helped much in this case, but it couldn't have hurt. In the case of mwmaint1001 maybe we could have searched and updated references in wikitech and officewiki (or maybe we did that, and we just missed one). I'm resolving this access ticket but I'll open a separate task to see about improvements in that area.