CODEWITHSUNDEEP
gitlabcontinuous-integrationgitlab-cisftp
Sim Son
Sim Son

Reputation: 308

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

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?

Upvotes: 3

Views: 895

Answers (3)

Matthias G&#252;nter
Matthias G&#252;nter

Reputation: 637

I have checked the man page of lftp and found the option sftp:connect-program:

the program to use for connecting to remote server. It should support -l' option for user name, -p' for port number. Default is ssh -a -x'. For private key authentica‐ tion add -i' option with the key file.

Instead of this:

lftp -c "set sftp:auto-confirm yes; open ...

We could use this:

lftp -c "set sftp:connect-program 'ssh -a -x -o StrictHostKeyChecking=no'; open

Upvotes: 0

Philip
Philip

Reputation: 23

If you're referring to this bug in Debian Bullseye then one workaround is to set this in /etc/ssh/ssh_config or ~/.ssh/config:

StrictHostKeyChecking accept-new

Upvotes: 0

Dandry
Dandry

Reputation: 515

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.

Upvotes: 1

Related Questions