iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
The safe fix is to verify the GitLab server’s current SSH host-key fingerprint, then either restore the original host key or remove only the confirmed stale entry from known_hosts. Do not bypass the warning with StrictHostKeyChecking=no or accept a replacement key before you know why it changed. A changed key can indicate a rebuild or migration, but it can also indicate that DNS, a load balancer, or an attacker is sending you to the wrong server.
What “host key verification failed” means
SSH performs two separate checks when you connect to GitLab. First, it verifies the identity of the server. Only after that does it authenticate your GitLab account with your user key. The server identity is represented by one or more SSH host keys. Your SSH client compares the key offered by the hostname with records in your user ~/.ssh/known_hosts file and, on some systems, a system-wide file such as /etc/ssh/ssh_known_hosts.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsThe connection stops when the key is missing, cannot be trusted, or differs from the key already recorded. A missing key normally produces an authenticity prompt. A mismatch produces the more serious REMOTE HOST IDENTIFICATION HAS CHANGED! warning and often ends with Host key verification failed.
GitLab Support describes this behavior accurately: “The error is a security feature, not a bug.” SSH is preventing you from sending credentials or Git data to a server whose identity is not established.
#1 Best Overall
- POWERFUL SECURITY KEY: The Security Key C NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key C NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key C NFC via USB-C and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
A legitimate change can follow a GitLab server rebuild, migration, reinstallation, hostname reuse, replacement of a load balancer, or a change in the machine that answers a DNS name. An unexpected change can instead mean stale DNS, a wrong hostname, an incorrectly configured VPN, or a man-in-the-middle attack. The repair depends on which of those situations is true.
First, establish which GitLab server you meant to reach
Do not edit known_hosts until you know the exact destination. A repository URL contains a host and a path; host-key verification concerns only the host. For example, in git@gitlab.example.com:platform/api.git, the host is gitlab.example.com and the repository path is platform/api.git.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- Check the spelling and capitalization of the hostname in your Git remote:
git remote -v. - Confirm whether the server is GitLab.com, a Self-Managed instance, a Dedicated instance, or a private deployment reached through a VPN.
- Resolve the name from the affected server and compare the result with the address supplied by the GitLab administrator. A stale resolver or split-horizon DNS can send different networks to different machines.
- Check that the required VPN, bastion, proxy, or firewall route is active. A failed route can make an administrator accidentally test a different service at the same name.
- If a load balancer is in front of GitLab, determine whether all backends are supposed to present the same host key. A single unprepared backend can cause intermittent warnings.
Never treat a familiar hostname as proof of identity. The fingerprint, obtained through an independent trusted channel, is the evidence you need.
Inspect the key and compare its fingerprint safely
Run a diagnostic connection
From the server that is failing, run a verbose test against the exact host:
ssh -Tvvv git@gitlab.example.comReplace the example hostname with yours. The output shows which configuration files were read, which address was contacted, the host-key algorithm offered, and the SHA256 fingerprint that SSH is evaluating. Do not answer an authenticity prompt merely because the command printed a key; record the fingerprint first.
Rank #2
- POWERFUL SECURITY KEY: The YubiKey 5C NFC is the most versatile physical passkey, protecting your digital life from phishing attacks. It ensures only you can access your accounts
- WORKS WITH 1000+ ACCOUNTS: Compatible with popular accounts like Google, Microsoft, and Apple. A single YubiKey 5C NFC secures 100+ of your favorite accounts, including email, password managers, and more
- FAST & CONVENIENT LOGIN: Plug in your YubiKey 5C NFC via USB and tap it, or tap it against your phone (NFC), to authenticate. No batteries, no internet connection, and no extra fees required
- MOST SECURE PASSKEY: Supports FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP/HOTP, Smart card (PIV), and OpenPGP. That means it’s versatile, working almost anywhere you need it
- PRIMARY & SPARE KEYS: Just like having a spare house key, we recommend buying two YubiKeys - one for daily use and one as a spare. That way you’ll never get locked out of your accounts
If your GitLab SSH service uses a nonstandard port, include it explicitly:
ssh -p 2222 -Tvvv git@gitlab.example.comThe port is part of the destination. A key for gitlab.example.com on one port is not automatically proof for the same name on another service.
Find an authoritative expected fingerprint
- For GitLab.com, use GitLab’s published SSH host-key fingerprint page and compare the SHA256 value and algorithm with the value shown by your client.
- For Self-Managed or Dedicated GitLab, open the instance’s
/help/instance_configuration#ssh-host-keys-fingerprintspage if it is available, or obtain the fingerprint from the GitLab administrator through a channel that does not depend on the suspect SSH connection. - For a private deployment that is temporarily unreachable, ask the administrator to calculate the fingerprint directly on the GitLab host and send it through your organization’s authenticated change-management or messaging system.
A fingerprint copied from the same potentially compromised server, or from an unverified ticket, does not independently establish identity. Compare the complete SHA256 fingerprint, not a shortened prefix.
Choose the correct repair
| Situation | Safest action | Why |
|---|---|---|
| The key matches the authoritative fingerprint, but your client has no record | Add the verified key through the normal SSH authenticity prompt or a reviewed known_hosts entry. |
The server is known; the client is simply learning its identity. |
| The GitLab server was rebuilt but its original host keys are available | Restore the original /etc/ssh/ssh_host_* keys on the replacement and restart sshd. |
Existing clients continue to recognize the same server identity. |
| The server was intentionally rebuilt and a new key was approved | Remove only the old entry with ssh-keygen -R, then verify the new fingerprint before accepting it. |
Clients can learn the replacement without disabling verification. |
| The key changed unexpectedly or cannot be independently verified | Stop and investigate DNS, routing, the load balancer, and the server. | Replacing the record could conceal interception or a wrong destination. |
| Only a CI runner fails | Install a pre-vetted file-type SSH_KNOWN_HOSTS variable in the job. |
Ephemeral runners do not reliably retain a user’s interactive known_hosts. |
Repair a server that was legitimately rebuilt
The best migration preserves the old host identity. Before the original machine is decommissioned, copy its SSH host keys through a protected administrative channel. GitLab Support recommends restoring the original /etc/ssh/ssh_host_* files on the replacement, correcting ownership and permissions, and restarting the SSH daemon.
- On the replacement host, stop or isolate SSH if your change procedure requires it. Keep an administrative console or out-of-band session available so a permissions mistake does not lock you out.
- Copy the original host-key files into
/etc/ssh/. Include the private key files and their matching public files; do not generate a new pair over the originals. - Set ownership to the SSH service’s expected owner, normally
root:root, and protect private keys. A typical Linux layout uses mode600for private host keys and644for their.pubfiles. Follow your distribution’s SSH hardening policy if it differs. - Validate the daemon configuration before restarting it:
sshd -t- Restart the SSH service using the service name on your operating system:
sudo systemctl restart sshdSome distributions call the unit ssh rather than sshd. Confirm the unit name in your operating system documentation or service listing instead of repeatedly restarting an unknown unit.
Rank #3
- POWERFUL SECURITY KEY: The YubiKey 5 NFC is the most versatile physical passkey, protecting your digital life from phishing attacks. It ensures only you can access your accounts
- WORKS WITH 1000+ ACCOUNTS: Compatible with popular accounts like Google, Microsoft, and Apple. A single YubiKey 5 NFC secures 100+ of your favorite accounts, including email, password managers, and more
- FAST & CONVENIENT LOGIN: Plug in your YubiKey 5 NFC via USB and tap it, or tap it against your phone (NFC), to authenticate. No batteries, no internet connection, and no extra fees required
- MOST SECURE PASSKEY: Supports FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP/HOTP, Smart card (PIV), and OpenPGP. That means it’s versatile, working almost anywhere you need it
- PRIMARY & SPARE KEYS: Just like having a spare house key, we recommend buying two YubiKeys - one for daily use and one as a spare. That way you’ll never get locked out of your accounts
After the restart, calculate the host-key fingerprint on the replacement and compare it with the administrator’s record. Then test from an affected client. If the fingerprint is unchanged, clients should not need any known_hosts edits.
Remove a stale entry when a new key is approved
Use this procedure only after the new fingerprint has been independently verified and the change is intentional.
- Back up your current file:
cp ~/.ssh/known_hosts ~/.ssh/known_hosts.backup- Remove entries for the exact hostname:
ssh-keygen -R gitlab.example.comUse the real hostname, not a repository path. If you connect on a nonstandard port, remove the host-and-port form as well, for example:
ssh-keygen -R '[gitlab.example.com]:2222'- Reconnect:
ssh -T git@gitlab.example.com- When SSH displays the new fingerprint, compare it again with the approved value. Answer
yesonly when they match.
ssh-keygen -R handles hashed hostnames and removes matching keys without requiring you to edit unrelated records by hand. Do not delete the entire known_hosts file: that weakens verification for every other server you use and can hide unrelated compromises.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →If the entry exists in a system-wide known-hosts file, a user-level removal may not be enough. An administrator must update the relevant system file after completing the same fingerprint verification.
Rank #4
- POWERFUL SECURITY KEY: The Security Key NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key NFC via USB-A and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
Confirm host verification before debugging account authentication
Once the key is accepted, run:
ssh -T git@gitlab.example.comA successful GitLab SSH test normally returns a GitLab welcome message rather than an interactive shell. At that point, host verification is complete. A subsequent Permission denied (publickey) is a different problem and should not be “fixed” by changing host keys.
When the next error is Permission denied (publickey)
- Confirm that the public key corresponding to the intended private key is added to the correct GitLab account.
- Check which key SSH is selecting with
ssh -Tv git@gitlab.example.com. - List keys loaded in your agent with
ssh-add -l; load the intended key withssh-add ~/.ssh/id_ed25519when appropriate. - Inspect local permissions. Your private key should not be readable by other users; SSH commonly rejects keys with overly broad permissions.
- Review host-specific rules in
~/.ssh/config, includingIdentityFile,IdentitiesOnly, aliases, and port settings.
Keeping these phases separate prevents an account-key change from prompting you to erase a valid server identity.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Configure GitLab CI/CD and deployment runners safely
CI jobs often run on clean, short-lived machines with no interactive opportunity to verify a host. If a job must SSH to a private server or GitLab instance, collect that destination’s host key from a trusted network, ideally from the private server or another controlled administrative system. Review the resulting key independently before putting it into CI.
Recommended Free Tools
- Run
ssh-keyscanfrom the trusted network for the exact hostname and port. Treat its output as untrusted until an administrator compares the fingerprint with the expected value. - In GitLab project or group settings, create a file-type CI/CD variable named
SSH_KNOWN_HOSTS. Paste the reviewed, completeknown_hostslines into the variable and protect or restrict it according to the environments that may deploy. - Copy the variable into the runner’s SSH directory before any Git or deployment command:
before_script:
- mkdir -p ~/.ssh
- cp "$SSH_KNOWN_HOSTS" ~/.ssh/known_hosts
- chmod 644 ~/.ssh/known_hostsGitLab explicitly warns against running ssh-keyscan directly inside the CI job. If an attacker can influence the network at job time, the job could record the attacker’s key and then trust it. A pre-vetted variable makes an unexpected host-key change fail loudly instead of silently accepting whatever key the runner sees.
Rotate the variable through the same change process used for the server’s host keys. During a planned migration, update the variable only after the replacement fingerprint has been verified, and coordinate the change so jobs do not alternate unpredictably between old and new backends.
Best Value
- The information below is per-pack only
- POWERFUL SECURITY KEY: The Security Key C NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key C NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key C NFC via USB-C and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
Self-Managed and Helm-specific checks
When the instance fingerprint page cannot show host keys
If /help/instance_configuration reports that SSH host keys are unavailable, inspect /etc/ssh directly on the GitLab host. Confirm that the expected ssh_host_* files exist, that the SSH daemon is using them, and that the service can read them. Do not publish private host-key files; only the public key material or its fingerprint should leave the host.
Helm chart deployments
In a Helm-based GitLab deployment, the webservice component may not automatically have access to the host keys. Set this value in values.yaml:
webservice:
sshHostKeys:
mount: trueApply the chart change using your normal deployment process, then verify that the webservice can read the mounted keys and that the fingerprint it presents matches the value published for the instance. Review the rendered configuration and pod logs if the mount is not present; a values-file indentation error can leave the setting disabled.
Troubleshoot recurring or intermittent warnings
| Symptom | Likely cause | What to check |
|---|---|---|
| The warning appears immediately after a rebuild | The replacement generated new host keys. | Compare the new fingerprint with the approved change record; restore the old keys if continuity is required. |
| Different clients see different fingerprints | Split DNS, stale caching, multiple load-balancer backends, or inconsistent host keys. | Resolve the hostname from each network, inspect every backend, and ensure the service presents one approved identity. |
| The warning occurs only through a VPN | The VPN routes the name to a private address or alternate GitLab instance. | Compare DNS answers, routes, and the fingerprint inside and outside the VPN. |
ssh-keygen -R reports no matching entry |
The key may be hashed, stored with a port, or present in a system-wide file. | Use ssh-keygen -F gitlab.example.com, check the bracketed port form, and ask an administrator to inspect system-wide files. |
| The key is accepted but Git operations still fail | Host verification succeeded; account authentication, authorization, or repository access is failing. | Run the ssh -T test, inspect the selected identity, and verify project permissions. |
| A CI job fails after a planned migration | The runner’s SSH_KNOWN_HOSTS variable still contains the old key. |
Update the reviewed file variable and confirm that the job copies it before connecting. |
Prevent the next host-key incident
- Record each GitLab SSH host-key fingerprint in your infrastructure inventory, including the algorithm, hostname, port, environment, and date verified.
- Back up host keys securely before rebuilding or migrating a GitLab server. Treat private host keys as secrets with tightly limited access.
- Make host-key changes part of the change request. Include the old fingerprint, new fingerprint, reason, affected clients, and rollback plan.
- Keep DNS, load-balancer, VPN, and GitLab migrations coordinated. A correct key on one backend does not fix an inconsistent pool.
- For automation, distribute reviewed
known_hostsdata rather than discovering keys during a job. - Never solve an unknown mismatch by disabling strict host-key checking globally. That removes the protection that detected the problem.
Bottom line
Verify first, edit second: identify the exact GitLab host, compare the presented SHA256 fingerprint with an authoritative value, preserve the original host keys when a rebuild allows it, or remove only the confirmed stale entry with ssh-keygen -R. Once the server identity is trusted, troubleshoot account keys separately. For CI, install a reviewed SSH_KNOWN_HOSTS file instead of running ssh-keyscan at job time.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
