If PuTTY defaults to anything other than type SSH port 22, TortoiseGit acts up on SSH cloning
By MartyMacGy... on May 20, 2013 03:49 (imported from Google Code)
I'm using TortoiseGit 1.8.3.0 + MSysGit 1.8.1.2 on WIndows 7 x64. I'm using TortoiseGitPLink.exe for the SSH client. (I use a separate copy of PuTTY for other connectivity.)
I recently noticed a problem when cloning, fetching, etc. from github when authenticating via SSH key. For example, I would get this:
git.exe clone --progress -v "git@github.com:username/foobar.git" "C:\foobar"
Cloning into 'C:\foobar'...
Unable to open connection:
Unable to open serial portfatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
(note also that there's never a proper newline before the "fatal:..." error text)
Serial? That sounded rather bizarre, but I could find nothing about the error out there other than the source code itself. Not helpful.
Did the usual debugging loop, finally creating a local ssh key copy to test via command-line git.exe. This worked for git.exe but didn't fix TortoiseGit.
Then I remembered: I'd changed my defaults for PuTTY from ssh to a COM (serial) port a while back. That should have exactly NO effect on anything else, but on a whim I changed it back to ssh.
Suddenly TGit works.
Changed it back. Suddenly TGit doesn't work anymore.
So, why does TortoiseGit / TortoiseGitPLink depend on the default session options for the terminal part of PuTTY? If my defaults were "telnet" would it try to use port 21? That doesn't really make sense, when this is specifically meant to handle SSH traffic.
If one must have PuTTY's terminal configured for port 22 SSH as its "Default Settings" to make Plink work right then that's awfully weird, but it should at least be called out somewhere, a useful and helpful "Did you configure PuTTY to use something other than SSH port 22 as its Default Settings?" message perhaps, rather than just a cryptic "Unable to open serial port" thing.
Otherwise, this is a bug. I'm not sure if it's a new bug or if this was always the case, but it's definitely happening in 1.8.3.0 and IMHO it would lead to a lot of unnecessary grief for users who have defaults other than SSH via port 22 for their PuTTY installations.