There's no problem with the account on the server - I can connect to the same server using the same version of Tectia client through sshg3, scpg3, etc on Windows XP and Vista. It's just Windows 7. And I can connect through the Tectia Windows UI on Windows 7 - it's just the command line tools that don't work.

Also, the server is NOT running Tectia Server - it's running the standard RedHat ssh daemon. With the maximum level of logging on the most I get is this:

Are you able to connect to this server from the same Windows 7 host using a terminal connection (i.e using sshg3)?

If you are still not able to login, could it be that the password for this account is expired?
Check if you're able to login from another host which was working before.

If still not working, checking syslog on the server for Tectia Server audit messages could give some clue as to what is happening here.

If running an OpenSSH you can try starting the server with debug mode on another port to get more information as to why the connection is failing:

As root, on the server run the following:

sshd -p 2222 -d

This should start the OpenSSH server in debug mode on port 2222 and print verbose messages to standard error. Then try connecting to the server on that port (using verbose mode on the client) and check the server messages:

There's no problem with the account on the server - I can connect to the same server using the same version of Tectia client through sshg3, scpg3, etc on Windows XP and Vista. It's just Windows 7. And I can connect through the Tectia Windows UI on Windows 7 - it's just the command line tools that don't work.

This is really strange. Can you try starting the OpenSSH server in debug mode and connecting to that? (See my updated answer above)
I'm still inclined to blame the server here.
Are you also using the same authentication method (password) from the other windows clients? or could it be that they are using public-key?

OK, so after another round of Windows 7 updates and a couple of reboots, it is now working. I have no idea what the problem was or why that has resolved it as the updates installed appear to have nothing to do with networking. Perhaps there was some network stack corruption which the update process has sorted out. Who knows?

As I cannot now reproduce the issue, I can't give you any more information. I guess it's just "one of those Windows things". If it comes back, I'll let you know.

In any case, thanks for your help and thanks for looking into the issue.