I've used KiTTY with zmodem for many years to quickly inject or fetch files from remote SSH hosts. There was simply no quicker way to get this job done until the zmodem code got broken, abandonned and finally removed following the KiTTY v0.71 release. The last known KiTTY version with working zmodem transfer is v0.70.0.10, available here, which lacks some compatibility bugfixes with recent Windows versions and some security fixes.

Since then I had to launch WinSCP using SHIFT + F3 which would connect to the remote host I had connected to using KiTTY. However, by default WinSCP connects to the home directory of the user. So with each WinSCP session I'd have to navigate to my current directory on my own, this can be a major hassle depending on the complexity of the directory structure. Furthermore, unlike using rz.exe and sz.exe (with lrzsz installed on the host), which easily uploads/downloads files through intermediate hosts, a launched WinSCP session will only connect to the original bastion host and not to the final destination host that I have proxied to.

I looked into the KiTTY source, realized that KiTTY is listening to some control characters to interact with WinSCP and hacked something together. While testing, I realized that tmux and screen are not passing these through. After digging through tmux and screen sources, I found out about their similar, but still different device control string approaches which would allow this to work.

The following script, when executed on the remote host through a KiTTY ssh connection, will check if the user is likely running tmux or screen and will then launch a WinSCP session to the FQDN hostname of the host. It will use the current SSH username and auto-navigate to the present working directory. This will even work if you have used an intermediate host to proxy yourself to a destination host if both hosts use the same SSH port. You will always connect to the host where this script is being executed.

You will need this script on all hosts you are connecting to. I save this script at /usr/local/bin/winscp:

#!/bin/bash
if [ -n "$STY" ]; # we're in a local screen session
then
  printf '\eP\e\e]0;__wt:%s:%s:%s\a\e\\' "$(hostname -f)" "$USER" "$PWD"
elif [[ $TERM = screen* ]] || [ -n "$TMUX" ]; # either connected remotely while in tmux/screen or locally in tmux
then
  printf '\ePtmux;\e\e]0;__wt:%s:%s:%s\a\e\\' "$(hostname -f)" "$USER" "$PWD"
else
  printf '\e]0;__wt:%s:%s:%s\a\e\\' "$(hostname -f)" "$USER" "$PWD"
fi

Now, when I am in a remote session, I will simply type the command winscp and WinSCP opens right where I want it to be.

• If you are the kind of person who uses tmux inside tmux, then you need to alter the script accordingly. Be creative and let me know in the comments if you run into any issues. I also have a movie recommendation for you.
• In the case that the DNS servers used by your client are unable to resolve “hostname -f” of the remote SSH host, you may try to replace it with “hostname -I” inside the above script, which would pass an IP address instead of a FQDN hostname.
• When using GNU screen and running the script on a remote host, it will display “tmux;” which is a cosmetical nuisance that can be safely ignored. The script will work just fine. This happens because there is no way to detect on a remote host if either tmux or screen is used locally. Unlike screen, tmux requires “tmux;” to be part of the otherwise identical device control string to allow outputting directly to the host terminal without interpretation.
• When using screen or tmux with $TERM other than screen* and running this script on a remote host, then you're out of luck. On a remote host, there is no way to guess you're actually in a tmux or screen session other than checking for $TERM. Unless you pass along something custom during SSH connect, which is out of the scope of this document.

• The script and documentation has been contributed to KiTTY for inclusion on their wiki. I send thanks to the especially helpful channel #screen on Freenode who took the time to discuss the case, test and fix bad style in the script. They wish tmux would use their own TERM variable (so it would be possible to detect if tmux or screen is used from within a remote host) or simply allow DCS the same way like screen.
• SuperPutty by Jim Radford is a local terminal multiplexer for PuTTY and KiTTY. It is highly configurable, and I can only advise to go through all options so that you explore its full potential. The latest dev builds for Windows are made available here.
• SecureCRT by Van Dyke Software is a commercial alternative to KiTTY that supports z-modem. SecureCRT comes with its own session management, terminal multiplexing, file transfer solution, it can be themed and the software is outstandingly well supported.