Hi, I'm just reporting back that WinSCP 4.1 beta works like a charm. Indeed, upstream issues can be annoying! :-) Thank you!

Same Problem here with newest versions of putty, pagent and winscp:
WinSCP ignores the private key specified in the connection profile, so the wrong key (for SVN purpose) is used from pagent.
Really annoying!

But: WinSCP is great stuff, I like it very much!!

Thank you,
Michael

I've found that there was change in key handling in PuTTY 0.59 (follow here). The change will get into WinSCP with some future version.

martin wrote:

That's how PuTTY works. I cannot (do not want to) change that.

But you may find useful that if there are more keys loaded in pageant, the one specified as explicit key has always precedence, disregarding the actual order in pageant. So you can load both your keys, the SVN one as second, to give the regular one precedence. And override the precedence by explicitly selecting SVC key for your SVN session.

I disagree. With multiple keys loaded in pagent, PuTTY (Release 0.59) uses the private key specified in the session configuration.

How do you specify a key as an explicit key in pageant? I haven't been able to find it in the PuTTY doc.

Regardless of the order I load the 2 private keys, the one that authenicates with the public key containing the "command=" is the first key listed in pageant. Therefore, WinSCP fails to authenicate.

I am currently running WinSCP 4.0b but I had the same issue with version 3.8.2.

That's how PuTTY works. I cannot (do not want to) change that.

But you may find useful that if there are more keys loaded in pageant, the one specified as explicit key has always precedence, disregarding the actual order in pageant. So you can load both your keys, the SVN one as second, to give the regular one precedence. And override the precedence by explicitly selecting SVC key for your SVN session.

I have a somewhat interesting SSH public key system setup. I have a normal, password protected key which performs a regular SSH login, and I also have a non-password protected key that is exclusively for SVN repository access. What this means is that if I log in with the first key, I get a shell prompt, but if I log in with the second key, I get an svnserver, which is not acceptable for SFTP.

For convenience's sake, I keep the non-password protected key constantly loaded in pageant. When I SSH into the box, I explicitly tell PuTTY to use the other key.

With winscp, I'm having some problems where winscp appears to check pageant for a public key first, and use it, even if I have explicitly specified the private key I'd like to use.

Steps to reproduce:
1. Create an SSH account with multiple authorized keys. With one authorized key, define a forced command that boots up some sort of server, such as svnserve, example:

command="svnserve -t -r /svn/repos" ssh-rsa [key data]
ssh-rsa [key data]

(First key is the SVN key, second is the regular key

2. Load the SVN key into pageant
3. Open up WinSCP, fill in the login parameters, select the regular key as the private key
4. Attempt to log in

Expected result: Regular key is used, SFTP works
Actual result: Login works, but SFTP initialization fails due to overly large SFTP packet (i.e. SVN key was used)

Removing the SVN key from pageant fixes the problem.

I recognize that this quite a bit of an edge case, but I think that nonetheless the behavior is a bug: explicit private key should win any day over pageant.