Can no longer connect to production server with SFTP after update to 7.7.7

[G240WIl]

After updating to 7.7.7 can no longer connect to one of our production servers on for one site with sftp. Was fine right before update. Can connect to a different project/ server/website via ftp.

cd `/var/www/vhosts/iseinc.com/httpdocs/' [sh: line 1: ssh: command not
---- Running connect program (ssh -a -x -v -s -l user -p 1022 xxx.xxx.xxx.xxx sftp)
---> sending a packet, length=5, type=1(INIT), id=0
<--- sh: line 1: ssh: command not found
**** Peer closed connection
---- Disconnecting
cd: Fatal error: max-retries exceeded (sh: line 1: ssh: command not found)

(above is the result in Target — Test Connection

Checked the SFTP connection with dreamweaver and confirmed all settings were correct.

IP address for sftp removed for security but was confirmed to be correct. Test in target and attempts at opening remote has same result. Did receive a couple of errors while running the software that had to ignore. Never had issues before connecting. Any help would be greatly appreciated.

Note I updated AP connect (2) files as requested with project updater… I chose to not update the same files while I tried the second site and the second site connected fine.

[George]

What OS are you on?

[G240WIl]

Hi. Web server is Nginx windows 11 on the local I have set as php as server type in Wappler. The one that works is likely apache.

[George]

Well make sure the system ssh is available on your path. It is in the OpenSSL folder of windows, so make sure it available.

[G240WIl]

Are you talking about local or remote?

[George]

Local on your windows development pc

[franse]

@George I can confirm this is a new bug, can't upload a file using sftp

Something has changed

Start upload for app/api/-------
Uploading restart.txt to restart the NodeJS server ...
cd: Fatal error: max-retries exceeded (sh: line 1: ssh: command not found)

On terminal:

E:\xampp\htdocs\projectname>ssh -V
OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2

[franse]

Some other info:

E:\xampp\htdocs\projectname>where ssh
C:\Windows\System32\OpenSSH\ssh.exe

E:\xampp\htdocs\projectname>where sh
C:\Users\Fran\AppData\Local\Wappler\resources\app\Shared\DMXzone\dmxAppCreator\UI\bin\win64\usr\bin\sh.exe

Checking NodeJS installation and version...

v22.13.1

NodeJS is correctly installed.
Check completed successfully...

[tehowden]

Hi

have a similar problem with deploying to docker (hetzner) from windows 11 and Wappler 7.7.7 it worked before updating to 7.7.7.

Her is the error message and ssh is working from terminal.

unable to get image 'modul5__mod5_prod-web': error during connect: Get "http://docker.example.com/v1.51/images/modul5__mod5_prod-web/json": exec: "ssh": executable file not found in %PATH%
Error
Error Launching Services!

[Journeyman]

Windows 11pro and it's a nodejs app

[raymantle]

Same issue with Windows 11 Pro and ASP.NET Server model.

cd: Fatal error: max-retries exceeded (sh: line 1: ssh: command not found)

[Teodor]

Fixed in Wappler 7.7.8

[G240WIl]

Still having issues. Spent 6 hours and many long AI discussions and determined still seems to be a bug. Note server requires user/password as the authenication in SFTP on a custom port 1022. Here are additional details of what we did to determine:

SFTP Connection Issue – Wappler 7.7.7 / 7.7.8 (Windows, Password Authentication)

I am still unable to connect to my SFTP server using Wappler 7.7.8 with username/password authentication, although the same configuration works correctly in other clients and from the Windows command line.

Environment:

• Windows (using built-in OpenSSH_for_Windows_9.5)

• Remote server: OpenSSH_9.9

• SFTP over port 1022

• Authentication method: password only (no SSH key support on server)

Current Behavior in Wappler:
Wappler now successfully initiates the SSH connection and completes the handshake. The log shows:

• Host key verification succeeds

• Key exchange completes successfully

• MAC negotiation completes successfully (after adjustment noted below)

• Server responds with:

  Authentications that can continue: publickey,password
  Next authentication method: password
  

At this point, Wappler prompts for a password, but after entering it, the connection does not proceed. Instead, it eventually times out with:

Timeout - reconnecting

There is no indication that the password was accepted or rejected by the server. It appears that the password is not being successfully passed to the underlying SSH process.

Troubleshooting Performed:

Initially (in version 7.7.7), Wappler could not connect at all. After upgrading to 7.7.8, the connection now reaches the authentication stage, so that portion appears improved.

During testing, I encountered a “Corrupted MAC on input / message authentication code incorrect” error. This was resolved by forcing the MAC algorithm to hmac-sha2-256 in the SSH config. After doing this, SSH communication proceeded normally.

I verified that OpenSSH on Windows works correctly by connecting from the command line using:

sftp -o MACs=hmac-sha2-256 -P 1022 user@host

This prompts for a password and connects successfully.

I also confirmed that the exact same credentials and server settings work in Dreamweaver without any issues.

Additionally:

• The SSH config file is being read and applied (confirmed by log output)

• Authentication proceeds to the password stage correctly

• No SSH keys are being used (intentionally password-only setup)

Conclusion:

At this point, all underlying components are working correctly:

• The server is reachable and functioning

• Credentials are valid

• Windows OpenSSH works correctly

• MAC negotiation issues have been resolved

The remaining issue appears to be within Wappler’s SFTP implementation on Windows. Specifically, Wappler reaches the password authentication stage but does not successfully pass the entered password to the SSH process, resulting in a timeout rather than a success or failure response.

This appears to be a regression introduced in 7.7.7 and only partially addressed in 7.7.8, where connection setup was fixed but password authentication handling still fails.

---

If needed, I can provide full logs, but the key point is that authentication reaches “Next authentication method: password” and then stalls with a timeout.