Hi,

I got it working in Windows 7 by removing Heimdal Kerberos and 64bit putty.

Intalled:

https://web.mit.edu/kerberos/dist/kfw/3.2/kfw-3.2.2/kfw-3-2-2.exe

Configured c:\windows\krb5.ini:

[libdefaults]
default_realm = MYREALM.COM
dns_lookup_kdc = false
dns_lookup_realm = false

[realms]
MYREALM.COM = {
kdc = primary.mydom.com:88
kdc = secondary.mydom.com:88
admin_server = primary.mydom.com
default_domain = MYREALM.COM
}

[domain_realm]
.mydom.com = MYREALM.COM
mydom.com = MYREALM.COM

Installed 32bit putty from:
<invalid hyperlink removed by admin>
Use default during installation.

Start Putty.
Under Category->SSH->Auth->GSSAPI
check: Attempt GSSAPI authentication (SSH-2only)

In box: Preference order for GSSAPI libraries
mark: User-specified GSSAPI DLL
and klick "Up" to move it to the top.

In "User-supplied GSSAPI library path":
Browse and choose "C:\Program Files (x86)\MIT\Kerberos\bin\gssapi32.dll"
Under "Saved sessions"
Mark "Default Settings"
Klick "Save"

Install WinSCP 5.1.3 (or later)

Check: "Advanced options"
Mark: SSH->Authentication
Check: "Attempt GSSAPI authentication (SSH-2)

Mark "Preferences" to left
Klick the "Preferences..." button.
Mark Integration->Applications
Make sure Putty path is: C:\Program Files (x86)\PuTTY\putty.exe
Klick "OK"
Mark Session at the top
Klick the arrow to right of the Save button and choose "Set defaults"
Klick "OK".

Get a ticket in Network Indentity Manager
Putty, pscp, plink, WinSCP etc will use the kerberos ticket.

Thanks!
Keep up the good work.

Regards
Bernt Jernberg

At the times of WinSCP 3.8.2, PuTTY did not support Kerberos and WinSCP used unofficial implementation of Kerberos. Nowdays PuTTY has it own, so WinSCP uses it too.
This implementation expects that path to gssapi32.dll in registry

XP: C:\Program Files\Kerberos\gssapi32.dll

WinSCP 3.8.2 finds it.

Shall I change anything in Windows XP registry to
make WinSCP 5.1.3 look in C:\Program Files\Kerberos?

Regards
Bernt Jernberg

Hi,

My point is that I haven't used any 64bit stuff (AFAIK) in XP and it still fails.
I just changed from WinSCP 3.8.2 to 5.1.3.

Any ideas?

Regards
Bernt Jernberg

martin wrote:

32bit PuTTY as well as WinSCP needs gssapi32.dll. They look for it using path found at HKLM\SOFTWARE\MIT\Kerberos\InstallDir

Ok.

I tested with Putty 0.58-GSSAPI, WinSCP 3.8.2, KfW in Windows XP, all 32bit. It works.
Then I tested with WinSCP 5.1.3 on the same XP-client. It didn't work.

Regards
Bernt Jernberg

32bit PuTTY as well as WinSCP needs gssapi32.dll. They look for it using path found at HKLM\SOFTWARE\MIT\Kerberos\InstallDir

Hi,

We are migrating from Windows XP to W7 on the client side.

I have started the job to get WinSCP working with GSSAPI
authentication in W7. According to my tests it don't work.

We have successfully been running WinSCP 3.8.2 with GSSAPI
authentication and KfW in XP.

According to my tests running versions 4.x or 5.x don't work
with GSSAPI authentication in neither XP nor W7. To be honest
I don't recall the exact 4.x version I tried but the one I
tested didn't work so I stayed with 3.8.2.

We use 0.58-GSSAPI Putty in XP.

I didn't get the standard Putty working in W7 so I installed
a 64bit version found on the net. KfW Leash didn't work in W7
either so I installed Heimdal Kerberos for Windows.

64 bits Putty together with Network Identity Manager (NIM)
built by secure-endpoints, configured to use an external
GSSAPI64.dll worked as expected with GSSAPI authentication.

WinSCP 5.1.3 can't find the kerberos ticket initialized through
NIM so I thought this was a problem in my setup for W7.

I then tested the portable WinSCP 5.1.3 in XP trying to access
the same ticket initialized through Leash that WinSCP 3.8.2
can use, but to no luck.

5.1.3 always prompts for password. I have tried to configure
5.1.3 the same way as 3.8.2 but that didn't work either.

The server is a Solaris 10 node with revision Generic_142900-11
running OpenSSH 5.5p1:

OpenSSH_5.5p1, OpenSSL 0.9.7d 17 Mar 2004 (+ security fixes for:
CVE-2005-2969 CVE-2006-2937 CVE-2006-2940 CVE-2006-3738
CVE-2006-4339 CVE-2006-4343 CVE-2007-5135 CVE-2007-3108
CVE-2008-5077 CVE-2009-0590)

I include debug-logs from both 3.8.2 and 5.1.3 sessions.
The 3.8.2 session shows a successful login with GSSAPI
authentication and 5.1.3 a failing one.

Have I missed something obvious?

Regards
Bernt Jernberg