I would like to report bug in latest WinSCP 5.7.4.
Enabling tunnel mode in WinSCP causes GSSAPI authorization to fail. Seems that when Tunnel=1 GSSAPI is auto disabled even if AuthGSSAPI=1 GSSAPIFwdTGT=1 is set. On the other hand AgentFwd=1 works flawless even when Tunnel=1.
Please fix GSSAPI authorization and delegation in tunnel mode.
Please attach a full log file showing the problem (using the latest version of WinSCP).
To generate log file, enable logging, log in to your server and do the operation and only the operation that causes the error. Submit the log with your post as an attachment. Note that passwords and passphrases not stored in the log. You may want to remove other data you consider sensitive though, such as host names, IP addresses, account names or file names (unless they are relevant to the problem). If you do not want to post the log publicly, you can mark the attachment as private.
Here are the winscp logs. It seems that there is no gssapi auth and delegation available during tunnel setup. WinSCP don't even try to use gssapi when setting up a ssh tunnel.
The following plink command works when testing connection to the same host to which winscp fails:
(you just have to enable gssapi auth + gssapi delegation in putty and save settings)
plink.exe -ssh -t -A -P tunnel.port firstname.lastname@example.org ssh -p secret.port email@example.com
I see that winscp works differently from plink. plink setups ssh connection and then execute ssh command on the first host and connect to the second host from the first host. WinSCP setups simple ssh tunnel on the first host and then connect to the localhost socket which is tunneled to the second host via first host tunnel. This might be problematic for gssapi auth and kerberos.
WinSCP needs to somehow pass second host fqdn to gssapi auth lib (needed by kerberos, SPN (Service Principal Name) and such stuff), otherwise the DNS PTR record will be resolved from 127.0.0.1 IP address to find second host fqdn. Ofc PTR resolved from 127.0.0.1 IP won't normally point to second host fqdn so gssapi auth won't work. You need to connect to tunnel at 127.0.0.1 but send second host fqdn to gssapi lib or you need to find some other way to workaround this problem or maybe redesign the whole tunnel functionality when used with gssapi auth.
It would be pity that tunneling in winscp works with agent forwarding but not with gssapi delegation. plink, ssh and many other tools works with both auth methods.
Could I help somehow in implementing this feature?