Authentication Tab

TIS and CryptoCard authentication are simple challenge/response forms of authentication available in SSH protocol version 1 only. You might use them if you were using S/Key one-time passwords, for example, or if you had a physical security token that generated responses to authentication challenges.

With this switch enabled, WinSCP will attempt these forms of authentication if the server is willing to try them. You will be presented with a challenge string (which will be different every time) and must supply the correct response in order to log in. If your server supports this, you should talk to your system administrator about precisely what form these challenges and responses take.1

The SSH-2 equivalent of TIS authentication is called ‘keyboard-interactive’. It is a flexible authentication method using an arbitrary sequence of requests and responses; so it is not only useful for challenge/response mechanisms such as S/Key, but it can also be used for (for example) asking the user for a new password when the old one has expired.1

WinSCP leaves this option enabled by default, but supplies a switch to turn it off in case you should have trouble with it. If your server uses keyboard-interactive authentication to ask for your password only, and you wish to allow WinSCP to reply with password entered on Session tab, tick Respond with password to the first prompt.

The switch tells WinSCP to attempt GSSAPI or SSPI authentication.

The GSSAPI is a generic API for doing client-server authentication. The motivation behind it is that every security system has its own API, and the effort involved with adding different security systems to applications is extremely difficult with the variance between security APIs. However, with a common API, application vendors could use the generic API and it could work with any number of security platforms (Kerberos, Entrust, …).

The SSPI is Microsoft specific (non-standard) implementation of GSSAPI.

To use MIT Kerberos authentication, you need to have MIT Kerberos for Windows installed.

This option allows the SSH server to open forwarded connections back to your local copy of Pageant. If you are not running Pageant, this option will do nothing. Learn more about agent forwarding. 1

This option allows the forwarding of the locally stored Kerberos ticket to a remote server, from which you can authenticate to other servers using this ticket.

The situation where it option is useful is where you do not have KfW on a local machine and are using cross realm where the realm of the server is not in AD. The local machine can be part of a domain, or a stand alone machine. It is proving handy for use from home for example.

When one of more of the realms are not AD, then the Microsoft ksetup command will need to be used to define the realms to the local machine. It can be found on the XP PRO CD under support tools which get installed into C:\Program Files\Support Tools\. There is also a version for W2K.

ksetup /AddKdc <realm> <KdcName>

(Repeat for other KDCs)

ksetup /SetRealmFlags <realm> TCPSupported Delegate

If the realm has the DNS SRV records setup the KdcName is optional at least on XP.

MIT 1.3 KDCs supports TCP. The Delegate flag is needed for servers in the MIT realm as it does not return the OK_TO_DELEGATE flag.