Hello,
We are having an issue with Make.com attempting to SFTP to our SFTP server. Some up-front information:
- Authentication is via user/pass (not key)
- The SFTP server works fine for other (non-Make.com) users
- Using the credentials works fine for other SFTP methods (command line, Filezilla, etc…)
- The error/issue happens with Make.com post authentication which means
— Ciphers/key exchange is fine
— Authentication is fine
— The SFTP server is up and “working” in Make’s eyes
The error within Make.com is “Unable to start subsystem: sftp”. The logs from Make shows:
DEBUG SFTP: Outbound: Sending CHANNEL_OPEN (r:0, session)
DEBUG SFTP: Inbound: GLOBAL_REQUEST (hostkeys-00@openssh.com)
DEBUG SFTP: Outbound: Sending GLOBAL_REQUEST (hostkeys-prove-00@openssh.com)
DEBUG SFTP: Inbound: CHANNEL_OPEN_CONFIRMATION (r:0, s:0)
DEBUG SFTP: Outbound: Sending CHANNEL_REQUEST (r:0, subsystem: sftp)
DEBUG SFTP: Socket ended
DEBUG SFTP: Socket closed
Module(4) [id=1] has NOT written data because of the ERROR: Unable to start subsystem: sftp { error: undefined }
MANAGING to PROCESS data in the module [id='1',name='sftp:ActionReaddir_1'] ended because of the ERROR: [Unable to start subsystem: sftp]
On the SFTP server, it shows (edited for brevity…):
debug1: userauth-request for user XXXXXXX service ssh-connection method password [preauth]
debug2: input_userauth_request: try method password [preauth]
debug1: PAM: password authentication accepted for XXXXXXXXX
pam_unix(systemd-user:session): session opened for user XXXXXXXX by (uid=0)
debug3: mm_request_receive entering
debug3: monitor_read: checking request 6
debug3: mm_answer_sign
fatal: mm_answer_sign: bad data length: 124, hostkey proof len 352
pam_unix(sshd:session): session closed for user XXXXXXXXXXX
The only time I’ve seen this sort of error is when the SFTP user/client has a previous SSH host key that does not match with the current SSH host key. Is there any way to either
A) Accept the new SSH Host Key
or
B) Delete out the current SSH Host Key that Make.com has stored (so it will, hopefully be forced to do A)
or
C) Some sort of disable for StrictHostKeyChecking
To be clear, this doesn’t appear to be a Host Key Mismatch error (as I’ve seen posted before) as it has already agreed upon the type of the key and that leaves a different error like “no matching host key type found”
Update after spending some more time (still an issue but feel more confident in what is going on)
This is the most important part
DEBUG SFTP: Inbound: GLOBAL_REQUEST (hostkeys-00@openssh.com)
DEBUG SFTP: Outbound: Sending GLOBAL_REQUEST (hostkeys-prove-00@openssh.com)
And more specifically mailto:hostkeys-00@openssh.com and mailto:hostkeys-prove-00@openssh.com
You can get a run down of what that means here from the horses mouth but basically its the server sending the host key(s) to the client and the client sending its host key back.
Now, if a key has changed since you’ve connected, you have to remove it from your known_hosts file (wherever and however that is stored) and then accept the new one (or have StrictHostKeyChecking disabled). Since there isn’t that step here between the Inbound and Outbound requests regarding @openssh.com, I’m assuming Make is just sending back the (out of date) key it has in known_hosts (which fails).