1

UPDATE Feb 2022: this issue may have been fixed in more recent versions. See comments on the accepted solution.

Summary:

An existing connection to a remote database in Navicat was working using a domain name for the SSH > Host field. After building a new remote server and pointing the domain at the new IP address (and setting up the database and users, as well as adding your public RSA key to the new server), Navicat doesn't trust the key hash from the server. Replacing the entries in ~/.ssh/known_hosts doesn't help.

Steps to reproduce:

  • point the domain for a remote database at a new IP address
  • add your RSA public key to the authorized keys on the remote server
  • add the remote database and users on the remote server
  • in Terminal, ssh into the new remote server using the domain, and follow the prompts to add the new server to the known_hosts file
  • in Navicat (specifically Navicat Essentials for PostGreSQL, but this issue will apply to any app in the Navicat suite on Mac) edit an existing connection to the remote server
  • on the SSH tab in the "Edit Connection..." window, click 'Test Connection'

Expected:

  • Navicat uses the updated ~/.ssh/known_hosts file to authorize connection to the remote server

Actual:

  • Navicat fails to connect

Error:

The server key has changed. Either you are under attack or the administrator changed the key.
New server key hash:...

Question:

How to get Navicat to accept the new known_hosts data and authorize the connection?

Rick Gladwin
  • 4,225
  • 1
  • 17
  • 21

1 Answers1

2

Problem:

Navicat uses a different known_hosts file than the operating system does. So updating ~/.ssh/known_hosts doesn't affect the Navicat connection to the remote server.

Solution:

  1. Optional workaround:
    • in Navicat, edit the database connection
    • on the SSH tab, change the Host field from a domain to the new IP address
  2. Fix:
    • in Terminal, run sudo find ~ -name known_hosts
    • the results will include something like (using Navicat Essentials for PostgreSQL as an example): /Users/<user>/Library/Containers/com.prect.NavicatEssentialsForPostgreSQL12/Data/.ssh/known_hosts
    • edit that file and remove the line starting with the domain for your remote server
    • return to Navicat and click Test Connection again. The connection should work.
    • If you see the error: Access denied for 'publickey'. Authentication that can continue: publickey,password (101203) or similar, check the Authentication Method selection and, if you're using 'Public Key' or 'Password and Public Key', click the 'Private Key' file navigator and re-select one of the private keys matching a public key that you've added to the remote server.
Rick Gladwin
  • 4,225
  • 1
  • 17
  • 21
  • 1
    In Navicat for MySql (and probably in all newer versions) it uses the `known_hosts` located at `~/.ssh`. Removing the line from there will do the work. – Ricardo Martins Jan 18 '22 at 03:38
  • @RicardoMartins ah that's good news. They must have fixed that in a more recent version. – Rick Gladwin Feb 02 '22 at 16:53
  • I tried the solution using `~/.ssh/known_hosts` when the issue came up again in Navicat Essentials for MySQL 15.0.35 and it didn't work – still needed to update Navicat's known_hosts file under `~/Library/Containers/...` Maybe the 'Essentials' versions don't use the user's known_hosts file? – Rick Gladwin Mar 23 '23 at 17:37