I've been able to both trigger and repair this problem. To trigger the bug (this is reliable, but is not the shortest method): Create a new local user (to be sure of no previous state) Do not create the .ssh directory or your public & private keys yet Use Xcode to try and clone the source. Xcode, "Source Control", "Clone ...", paste the URL into the "Enter repository URL" field at the top. Use a URL of the form "ssh://remoteuser@host.com/Users/remoteuser/path/repo.git". I.e. both SSH and non-default remote username. In the username authentication dialog that pops up, switch from "Username and Password" to "SSH Keys" Xcode notices you don't have ssh keys yet, and offers to create them. Hit "Create Key" Give it a passphrase, let it save your keys in the default .ssh directory. Minor bug: the dialog still thinks there are no existing keys. Hitting "SSH Keys" again will get it to notice they exist now. Hit Clone, then Trust to accept the remote hosts's id. Now it (appropriately) fails and you see "Unknown error" in the dialog. Hit cancel to dismiss the dialog window. Hit Clone again with the same URL. Now you get "An unknown error occurred" and "username does not match previous request (-1)" The real error is that your newly created public key is missing from the remote .ssh/authorized\_keys file, but this is the message you get from Xcode. And now it's stuck. Additional attempts to clone just gets the same error message without the username/password dialog prompts. And even after fixing ssh by adding your public key to the remote user's .ssh/authorized\_keys file, Xcode is still stuck with the same error message. There are many other (far shorter) ways to get stuck with this failure, but this demonstrates that there is no "previous request" or previous saved-state involved. The basic idea is that if Xcode's use of ssh fails you will get a bogus error message from Xcode about not matching previous requests and it is stuck. To repair: Quit Xcode if it's still running If still needed, fix your ssh problem (e.g. add your public key to the remote user's .ssh/authorized_keys). Test git in a shell (not in Xcode). E.g. "cd /tmp ; git clone ssh://remoteuser@host.com/Users/remoteuser/path/repo.git" Delete Xcode's preferences file in ~/Library/Preferences/com.apple.dt.Xcode Reboot. Let me shout that. You MUST REBOOT your computer at this point. Now when you try and clone it with Xcode you'll get the username/password dialog with "SSH Keys" selected and a request to unlock the passphrase. Give it the passphrase and the clone will work. And then next time it'll even fetch your passphrase from your keychain and you won't need to type it again. If you really really don't want to just delete your prefs file, you can do surgery on it to fix it, but it's pretty silly: With Xcode not running: cd ~/Library/Preferences plutil -convert xml1 com.apple.dt.Xcode (or use a plist editor that can process binary files) edit com.apple.dt.Xcode and find the key "IDESourceControlKnownSSHHostsDefaultsKey" delete both the key and its data. Save and ... REBOOT To repeat, after deleting or editing the prefs file you need to reboot. Quit and relaunch of Xcode is not enough. Logout and logging in again is not enough. There's some (tbd) account/identity daemon/state file that Xcode is chatting with that's caching the old bogus info. Additional notes: the occasional duplicate entries in the prefs file under DVTSourceControlAccountDefaultsKey appear to be minor issues that can be ignored. Xcode's use of ssh appears to just ignore the "User" directive in .ssh/config. This was tested with Xcode Version 12.3 (12C33) under MacOS 11.1.

See my response over in https://developer.apple.com/forums/thread/665666 Bottom line is that you need to fix your ssh environment (if it's still broken), then delete the Xcode prefs file and reboot. Without rebooting Xcode is able to restore the broken ssh account/remotehost info and you get stuck with this error.