Thanks for your reply Pontus.
lsftp typically runs lshg -G <whatever you send to lsftp before --> to set up a connection, so you might want to try to see if that works. You might also try pre-establishing a gateway (with lsh -G -N -B hostname or something like that) or using another program for transport (setting LSFTP_RSH to your lsh).
I think the problem you describe could occur if there's no gateway available and lshg doesn't find you lsh to fall back on (lsh not in PATH).
This did help me to further isolate the problem. When I set LSFTP_RSH to lsh (thus avoiding lshg) all is well. So I tried running lshg -G from the command line - tracing the process shows that it checks for the existance of a gateway and on failing to find one it execs lsh. All seems to go fine for a while - things continue as for a regular lsh session - on the server I even see successful auth logged by lshd. But in the end, I see this...
Assertion failed: NULL == sys->files[fd][ev].f && "multiple handlers registered for a file event", file sys.c, line 109
And then I get a core file from lsh :-/ I see that sys.c is a part of liboop - I am using version 1.0. Line 109 is a part of the sys_on_fd function.
I can work around this issue now, so thanks for pointing me in the right direction. Perhaps my observations will be helpful to you and Niels. If there are any other tests I can run that would help you to understand what is happening please let me know.
It's still possible that this is unique to my install, but I have spent much of the day building and rebuilding with all different types of options - is there anyone else on the list using lsh-2.0 on Solaris 9?