Net::SSH::AuthenticationFailed when pulling db about wordmove HOT 13 OPEN

@martin-josef as far as your report is a really complete one, it's hard to track it down as a bug.

It's not reproducible, as you reported. What we probably have is a behavior in Wordmove that your current hosting provider dislikes.

I can't elaborate a solution but I have a previous experience to share; Wordmove has a somewhat defective behavior when working w/ DB: it makes a lot of subsequent connections. Sometimes hosting providers set a throttle limit in order to protect themselves from ddos-like attempts and this limit could happen to resolve into a refute to auth the user.

One desperate try to do in order to verify this assumption is to add these configs to the specific host into your ssh config

Host example.com
  ControlMaster auto
  ControlPath /tmp/master-%r@%h:%p
  [...]

then in one terminal open an SSH connection to the host and in another terminal run wordmove pull -e production -d. This way you should force SSH client to reuse a single connection through a local socket (don't know if it's actually a socket, but at least it has a similar concept).

Is this a fix? It is not for sure. It's more of a troubleshooting/possible workaround/reproduction path, but that's all I have on the table.

from wordmove.

It is much appreciated, thanks! I will continue debugging the situation soon, right now I manually dump / pull / search-replace. I will report back if I find anything.

from wordmove.

I'm also experiencing this issue.

from wordmove.

I couldn't solve it myself and don't have to pull / push from that host anymore, so I sadly won't be of any help.

from wordmove.

I'll let you know if I solve - I think it might be related to php 8.1 but honestly I don't know why.

from wordmove.

I only experienced this issue with one host, all my digitalocean droplets etc. are unaffected.

from wordmove.

If you take a litle bit of attencion you can see wordmove is not getting your env variables, to fix it you can do something like:

local:
vhost: "http://localhost:<%= ENV['LOCAL_SERVER_PORT'] %>"
wordpress_path: "/var/www/html/"
database: # does not change this value, wordmove does not get ENV variables for this.
name: "wordpress"
user: "wordpress"
password: "wordpress"
host: "database"
mysqldump_options: "--hex-blob -no-tablespace" # add -- -no-tablespace to prevent permission denied error with mysqldump

Also for for integer does not add "" cause gonna be detected as string.

from wordmove.

Running into a similar issue and I think it's related to the current incompatibility of net-ssh 6.x.x and OpenSSL 3.x.x which ships by default with Ubuntu 22. Supposedly net-ssh 7.x.x should fix this, but I don't know how to go about fixing that here in Wordmove. (See net-ssh/net-ssh#874 for reference)

from wordmove.

mysql -e'QUIT'

In him case he is using bad configuration in movefile.yml, look at: mysql -e'QUIT'. Movefile is not reading env file '<%= ENV['PROD_DB_NAME'] %>' etc.. the solution is was i suggested. There is not another solution.

from wordmove.

mysql -e'QUIT'

In him case he is using bad configuration in movefile.yml, look at: mysql -e'QUIT'. Movefile is not reading env file '<%= ENV['PROD_DB_NAME'] %>' etc.. the solution is was i suggested. There is not another solution.

mysql -e'QUIT' is not a command from the OP, but a command wordmove doctor uses to test connection to DB. If a bug in reading from ENV exists, it should exist only when running doctor command.

from wordmove.

Running into a similar issue and I think it's related to the current incompatibility of net-ssh 6.x.x and OpenSSL 3.x.x which ships by default with Ubuntu 22. Supposedly net-ssh 7.x.x should fix this, but I don't know how to go about fixing that here in Wordmove. (See net-ssh/net-ssh#874 for reference)

@harnerdesigns does «similar» means only database related operations are failing?

from wordmove.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from wordmove.

@alessandro-fazzi sorry for the late as hell response, but yes, DB operations are the only one failing.

Running wordmove push -e production --all runs through everything fine and then fails on the DB push.

from wordmove.