GitLab-CI: can't deploy using lftp any more

Question

I have a problem with my deploy script in GitLab CI which used to work for the last two years. Since a week or so, the auto-verification of the root ECDSA is not working (I'm using lftp to deploy some files) .

This is how the output of the pipeline used to looked like.

$ lftp -u $FTP_USERNAME,$FTP_PASSWORD -p 22 sftp://my.ftp.server -e "debug; set sftp:auto-confirm yes; mirror --reverse --verbose --delete public/ mount/; bye"
---- Running connect program (ssh -a -x -s -l ftp_products -p 22 my.ftp.server sftp)
---> sending a packet, length=5, type=1(INIT), id=0
<--- The authenticity of host 'my.ftp.server (xxx.xxx.xxx.xxx)' can't be established.
<--- ECDSA key fingerprint is SHA256:Z2s4NdXMJ04EfN3jm4xZ/ZwJE4E6Lj/HP8oHWzIod4M.
<--- Are you sure you want to continue connecting (yes/no)? yes

Note that ssh asks for confirmation whether or not to continue, which is confirmed with yes by the command line option sftp:auto-confirm yes . The pipeline continues as intended.

Since last week, I get this as output from my deploy script:

$ lftp -u $FTP_USERNAME,$FTP_PASSWORD -p 22 sftp://my.ftp.server -e "debug; set sftp:auto-confirm yes; mirror --reverse --verbose --delete public/ mount/; bye"
---- Running connect program (ssh -a -x -s -l ftp_products -p 22 my.ftp.server sftp)
---> sending a packet, length=5, type=1(INIT), id=0
The authenticity of host 'my.ftp.server (xxx.xxx.xxx.xxx)' can't be established.
<--- ECDSA key fingerprint is SHA256:Z2s4NdXMJ04EfN3jm4xZ/ZwJE4E6Lj/HP8oHWzIod4M.
**** Timeout - reconnecting
---- Disconnecting
---- Running connect program (ssh -a -x -s -l ftp_products -p 22 my.ftp.server sftp)
---> sending a packet, length=5, type=1(INIT), id=0
The authenticity of host 'my.ftp.server (xxx.xxx.xxx.xxx)' can't be established.
<--- ECDSA key fingerprint is SHA256:Z2s4NdXMJ04EfN3jm4xZ/ZwJE4E6Lj/HP8oHWzIod4M.
**** Timeout - reconnecting
---- Disconnecting

Note, that ssh isn't even prompting for yes|no , so the command-line option to confirm the fingerprint automatically has no effect.

Has anyone faced this problem before and has a solution?

Answer 1

I started experiencing the same issue while using node docker image in my GitLab CI, which uses Debian under the hood. I was just using node meaning that in fact it was node:latest , that would most likely use the newest Debian version.

I found the following bug report on Debian website mentioning that there is a problem with lftp and Debian Bullseye version, where that SSH prompt is in fact not displaying. Debian Buster worked just fine.

I switched the image to node:bullseye and this problem persisted. Then I changed the image to the older node:buster and the problem was gone.

I would suggest investigating your image to determine what OS is it based on. If that is Debian as well, try playing around with versions. Hopefully that will get fixed soon.