The cause of the problem might that the remote directory does not exist anymore AND you have set Advanced -> Environment -> SCP/Shell -> Shell: "Default" The failure to set the current directory seems to break the shell auto-detection. So if you set an explicit shell, the problem goes away. Other solutions: – choose an existing directory ( Advanced -> Environment -> Directories -> Remote Directory: ) – re-create the directory in a separate SSH session I believe that he is correct. I think the remote directory no longer exists. So I have specified a directory that I know exists in the Remote Directory setting. But I do not know how to 'set an explicit shell' or to do as the Guest user suggested (change the shell in advanced options to shell (type in)) Changing the SCP/Shell setting from "Default" has only partially solved the problem. Let me describe the issue in more detail: I logged into the same server regularly, then suddenly one day WinSCP would just sit at "Starting the session" and never get any further – I left it for hours to check. And I did so on multiple occasions, just to make sure that it wasn't due to some sort of temporary or intermittent communication failure somewhere on the internet. Note that at this point, if the user chooses to cancel the login process (by clicking on the [X] in the WinSCP login dialog), the status changes to "Cancelling..." and remains in that state for several minutes before WinSCP actually cancels it's attempt. During this time, the user can no longer interact with WinSCP in any way. WinSCP cannot be closed gracefully, and has to be manually terminated. Searching the internet, and even the WinSCP site here, produced no clues as to what might be happening. The log file, while comprehensive, is utterly useless to anyone who isn't a WinSCP expert. I have been searching for a solution to this problem for a long time. Note: I have attached the log file to this reply, selecting the Private file option. Inside the log file, I have also changed server names and addresses and usernames and passwords. Yesterday, I found this post from @AdrianW that recommends changing the Shell/SCP option from "Default" . I tried this, and suddenly WinSCP no longer hangs at "Starting the session" Fantastic! However, the WinSCP still does not complete the login process – it *now* reports "Authentication failed" when it attempting to log in. Note that at this point, WinSCP's login attempt can be cancelled, and it will properly go back to the initial dialog that allows you to choose your connection. Regarding the authentication failure - this cannot be correct, because the credentials have not changed, and I have verified that they work by logging in successfully using PuTTy. To me, it seems that the Shell/SCP option that is being chosen is incompatible with the combination of credentials and login method - and so WinSCP is reporting "Authentication failed" . My question, and possibly the resolution to the entire issue is: if Default cannot be chosen (because it causes WinSCP to hang) and the other 3 options cannot be chosen (because they cause WinSCP to incorrectly report authentication failure) then what other option can be supplied or inserted into the Shell/SCP box? Note: this happens with at least the two previous versions of WinSCP, and also the very latest version (v5.11.3), which I installed today. As you can see from the above Martin, the information is related, and therefore I don't think it should be split into a new thread. Perhaps for you, dealing with a new thread is cleaner and easier. But for users of WinSCP who come here looking for a solution, it can be very frustrating to get half an answer, only to find that they have to look for another thread 'somewhere' that might have the rest of the answer. However, if you insist on a new thread being created, I can do so. Thank you. Your default shell is Windows cmd.exe . Do you have reason to believe that your server does support any bash-like shell? I've never seen "SSH-2.0-MS_1.100" server before. Are you sure you were ever able to use SCP protocol with WinSCP against that server? Did you try SFTP? In general, the log file (and your use of an obscure SSH server) just confirmed that your have a quite specific problem, that is only likely to actually confuse those coming to this thread.

I wasn't aware that it might affect the connection. As far as I know, no changes have been made to the SSH server - otherwise I don't think PuTTy would work.

Something must have changed. Either on server. Or in your WinSCP configuration. Maybe you have used SFTP protocol before. Just try to change the protocol. No other configuration should be needed. That PuTTY works has nothing to do with your problem. PuTTY is not SCP/SFTP client.

MorgueFLB wrote:

Regarding PuTTy, I was highlighting the fact that the server can be accessed via SSH on port XX with the supplied credentials, thereby eliminating those items as possible causes of the problem.

The "server can be accessed via SSH on port XX with the supplied credentials" even with WinSCP. You get a problem only later, when WinSCP tries to talk to the shell. @sloncer : Interactive stuff like sudo (if it prompts for a password) needs to go to .bash_profile . For details, see a similar problem here: Received too large (… B) SFTP packet. Max supported packet size is 102400 B @sridevi : Hard to tell without seeing a log file. Your server or environment probably does not meet WinSCP requirements: https://winscp.net/eng/docs/shell_session Was having this problem too with ADC/NetScaler – even though has worked in the past fine on countless upgrades and worked on another NetScaler fine on the same day. Took a while to figure out – but I had to go into the "Raw Site Settings" in the Advanced drop down while configuring the initial connection. Then Add button -> select Shell from the list, type shell – as the Shell to use (since this is the first command to enter in NetScaler when ssh to the appliance). Hope this helps someone.