3

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?

Sim Son
  • 310
  • 1
  • 10

2 Answers2

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.

Dandry
  • 495
  • 12
  • 26
0

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
Philip
  • 23
  • 1
  • 4