# Issue with new SSH Known Hosts feature – host registered but still not found

**URL:** <https://community.okteto.com/t/issue-with-new-ssh-known-hosts-feature-host-registered-but-still-not-found/1431>\
**Category:** Okteto Self-Hosted\
**Created:** [October 9, 2025, 9:51am UTC](https://community.okteto.com/t/issue-with-new-ssh-known-hosts-feature-host-registered-but-still-not-found/1431 "2025-10-09T09:51:56Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![marticardus](https://sea1.discourse-cdn.com/flex019/user_avatar/community.okteto.com/marticardus/32/611_2.png) [@marticardus](https://community.okteto.com/u/marticardus)\
**Post date:** [October 9, 2025, 9:51am UTC](https://community.okteto.com/t/issue-with-new-ssh-known-hosts-feature-host-registered-but-still-not-found/1431/1 "2025-10-09T09:51:56Z")

</div>

Hi everyone,

I’ve been testing the new [SSH Known Hosts feature](https://www.okteto.com/docs/admin/ssh-known-hosts/), but I’m running into some issues.

Even though I’ve registered my known host according to the documentation, Okteto keeps returning errors saying that the host is not found. I’ve double-checked that the hostname and key are correctly added, but the issue persists.

Additionally, when I try to use ssh-keyscan (as suggested in the docs) to retrieve the host key, it doesn’t seem to work correctly inside my Okteto environment — it either times out or returns an empty response.

Has anyone else experienced this behavior?

Is there something I might be missing in the configuration or in how Okteto validates known hosts?

Any help or clarification from the Okteto team would be greatly appreciated.

Thanks in advance!

Some logs:  
`ssh-keyscan failed after 8 attempts: failed to retrieve the SSH keys from "gitlab.ourdomain.com", please review that the hostname is correct, and that your network configuration permits traffic between Okteto and "gitlab.ourdomain.com": exit status 1error in FinishPipeline: Post "https://okteto.dev.ourdomain.com/graphql": read tcp 10.255.222.9:57900->172.20.237.72:443: read: connection reset by peer`

---

<div class="post-metadata">

**Author:** ![ramiro](https://sea1.discourse-cdn.com/flex019/user_avatar/community.okteto.com/ramiro/32/6_2.png) [@ramiro](https://community.okteto.com/u/ramiro)\
**Post date:** [October 9, 2025, 6:51pm UTC](https://community.okteto.com/t/issue-with-new-ssh-known-hosts-feature-host-registered-but-still-not-found/1431/2 "2025-10-09T18:51:20Z")

</div>

> [@marticardus](#):
>
> failed to retrieve the SSH keys from “[gitlab.ourdomain.com](http://gitlab.ourdomain.com)”, please review that the hostname is correct, and that your network configuration permits traffic between Okteto and “[gitlab.ourdomain.com](http://gitlab.ourdomain.com)”: exit status

Hey @marticardus , based on the error messages, it doesn’t seem like the error is related to KNOWN\_HOSTS but instead to network access between Okteto and Gitlab.

Can you verify that Okteto is able to resolve the DNS and reach out to your Gitlab instance. Other users in the past have had to explicitly open the HTTPS and/or SSH ports on their firewall and gitlab configurations for this to work.

---

<div class="post-metadata">

**Author:** ![marticardus](https://sea1.discourse-cdn.com/flex019/user_avatar/community.okteto.com/marticardus/32/611_2.png) [@marticardus](https://community.okteto.com/u/marticardus)\
**Post date:** [October 10, 2025, 7:13am UTC](https://community.okteto.com/t/issue-with-new-ssh-known-hosts-feature-host-registered-but-still-not-found/1431/3 "2025-10-10T07:13:35Z")

</div>

Hi @ramiro ,

I found this on some pods: (buildkit, registry, installer)

> / # cat /etc/hosts  
> 172.20.237.72 okteto.dev.ourdomain. com  
> 172.20.237.72 registry.dev.ourdomain. com

This causes the error (error in FinishPipeline: Post “https:// oktetodev.ourdomain com/graphql”: read tcp 10.255.222.9:57900-\>172.20.237.72:443: read: connection reset by peer), because is it the internal address of the ingress-nginx service with proxy protocol enabled, if I remove these entries, the service responds correctly.

But I think this were another problem that i need to resolve, maybe in another thread?

The current problem, as I understand it, is that despite having the “Known hosts” configured, it is doing a scan, when it should directly clone the repository.

Kind regards

---

<div class="post-metadata">

**Author:** ![ramiro](https://sea1.discourse-cdn.com/flex019/user_avatar/community.okteto.com/ramiro/32/6_2.png) [@ramiro](https://community.okteto.com/u/ramiro)\
**Post date:** [October 10, 2025, 1:19pm UTC](https://community.okteto.com/t/issue-with-new-ssh-known-hosts-feature-host-registered-but-still-not-found/1431/4 "2025-10-10T13:19:34Z")

</div>

For the known\_hosts issue, can you check on Admin \> Known Hosts if the feature is enabled?

---

<div class="post-metadata">

**Author:** ![marticardus](https://sea1.discourse-cdn.com/flex019/user_avatar/community.okteto.com/marticardus/32/611_2.png) [@marticardus](https://community.okteto.com/u/marticardus)\
**Post date:** [October 10, 2025, 1:31pm UTC](https://community.okteto.com/t/issue-with-new-ssh-known-hosts-feature-host-registered-but-still-not-found/1431/5 "2025-10-10T13:31:20Z")

</div>

Yes, it is

 ![image](https://us1.discourse-cdn.com/flex019/uploads/okteto/original/1X/7d8e4c838d5f9b746d29cddae8e876f9ec249a55.png)

---

<div class="post-metadata">

**Author:** ![ramiro](https://sea1.discourse-cdn.com/flex019/user_avatar/community.okteto.com/ramiro/32/6_2.png) [@ramiro](https://community.okteto.com/u/ramiro)\
**Post date:** [October 10, 2025, 3:42pm UTC](https://community.okteto.com/t/issue-with-new-ssh-known-hosts-feature-host-registered-but-still-not-found/1431/6 "2025-10-10T15:42:25Z")

</div>

Could you share here the full log of the deployment ? Please remove any sensitive information.

---

<div class="post-metadata">

**Author:** ![marticardus](https://sea1.discourse-cdn.com/flex019/user_avatar/community.okteto.com/marticardus/32/611_2.png) [@marticardus](https://community.okteto.com/u/marticardus)\
**Post date:** [October 13, 2025, 7:01am UTC](https://community.okteto.com/t/issue-with-new-ssh-known-hosts-feature-host-registered-but-still-not-found/1431/7 "2025-10-13T07:01:14Z")

</div>

Sure, here is the full log:

`Successfully assigned okteto/installer-c8f3fca8-af41-4464-b843-a164bcb15ac4-4hq57 to ip-10-255-199-115.eu-west-3.compute.internalCreated pod: installer-c8f3fca8-af41-4464-b843-a164bcb15ac4-4hq57Container image "okteto/okteto:3.12.0" already present on machineCreated container: setupStarted container setupContainer image "okteto/pipeline-runner:1.37.1" already present on machineCreated container: installerStarted container installerDeploying Dev Environmentinitialized kubernetes client with InClusterConfigssh-keyscan operation failed (attempt 1/8): failed to retrieve the SSH keys from "gitlab.<domain>.com", please review that the hostname is correct, and that your network configuration permits traffic between Okteto and "gitlab.<domain>.com": exit status 1Retrying ssh-keyscan operation in 1s (attempt 2/8)ssh-keyscan operation failed (attempt 2/8): failed to retrieve the SSH keys from "gitlab.<domain>.com", please review that the hostname is correct, and that your network configuration permits traffic between Okteto and "gitlab.<domain>.com": exit status 1Retrying ssh-keyscan operation in 2s (attempt 3/8)ssh-keyscan operation failed (attempt 3/8): failed to retrieve the SSH keys from "gitlab.<domain>.com", please review that the hostname is correct, and that your network configuration permits traffic between Okteto and "gitlab.<domain>.com": exit status 1Retrying ssh-keyscan operation in 4s (attempt 4/8)ssh-keyscan operation failed (attempt 4/8): failed to retrieve the SSH keys from "gitlab.<domain>.com", please review that the hostname is correct, and that your network configuration permits traffic between Okteto and "gitlab.<domain>.com": exit status 1Retrying ssh-keyscan operation in 8s (attempt 5/8)ssh-keyscan operation failed (attempt 5/8): failed to retrieve the SSH keys from "gitlab.<domain>.com", please review that the hostname is correct, and that your network configuration permits traffic between Okteto and "gitlab.<domain>.com": exit status 1Retrying ssh-keyscan operation in 16s (attempt 6/8)ssh-keyscan operation failed (attempt 6/8): failed to retrieve the SSH keys from "gitlab.<domain>.com", please review that the hostname is correct, and that your network configuration permits traffic between Okteto and "gitlab.<domain>.com": exit status 1Retrying ssh-keyscan operation in 32s (attempt 7/8)ssh-keyscan operation failed (attempt 7/8): failed to retrieve the SSH keys from "gitlab.<domain>.com", please review that the hostname is correct, and that your network configuration permits traffic between Okteto and "gitlab.<domain>.com": exit status 1Retrying ssh-keyscan operation in 1m4s (attempt 8/8)Retrying ssh-keyscan operation in 32s (attempt 7/8)ssh-keyscan operation failed (attempt 7/8): failed to retrieve the SSH keys from "gitlab.<domain>.com", please review that the hostname is correct, and that your network configuration permits traffic between Okteto and "gitlab.<domain>.com": exit status 1Retrying ssh-keyscan operation in 1m4s (attempt 8/8)ssh-keyscan operation failed after 8 attemptsssh-keyscan failed after 8 attempts: failed to retrieve the SSH keys from "gitlab.<domain>.com", please review that the hostname is correct, and that your network configuration permits traffic between Okteto and "gitlab.<domain>.com": exit status 1error in FinishPipeline: Post "https://okteto.dev.<domain>.com/graphql": read tcp 10.255.222.2:53222->172.20.237.72:443: read: connection reset by peerDeploying Dev Environmentinitialized kubernetes client with InClusterConfigssh-keyscan operation failed (attempt 1/8): failed to retrieve the SSH keys from "gitlab.<domain>.com", please review that the hostname is correct, and that your network configuration permits traffic between Okteto and "gitlab.<domain>.com": exit status 1Retrying ssh-keyscan operation in 1s (attempt 2/8)ssh-keyscan operation failed (attempt 2/8): failed to retrieve the SSH keys from "gitlab.<domain>.com", please review that the hostname is correct, and that your network configuration permits traffic between Okteto and "gitlab.<domain>.com": exit status 1Retrying ssh-keyscan operation in 2s (attempt 3/8)ssh-keyscan operation failed (attempt 3/8): failed to retrieve the SSH keys from "gitlab.<domain>.com", please review that the hostname is correct, and that your network configuration permits traffic between Okteto and "gitlab.<domain>.com": exit status 1Retrying ssh-keyscan operation in 4s (attempt 4/8)ssh-keyscan operation failed (attempt 4/8): failed to retrieve the SSH keys from "gitlab.<domain>.com", please review that the hostname is correct, and that your network configuration permits traffic between Okteto and "gitlab.<domain>.com": exit status 1Retrying ssh-keyscan operation in 8s (attempt 5/8)ssh-keyscan operation failed (attempt 5/8): failed to retrieve the SSH keys from "gitlab.<domain>.com", please review that the hostname is correct, and that your network configuration permits traffic between Okteto and "gitlab.<domain>.com": exit status 1Retrying ssh-keyscan operation in 16s (attempt 6/8)ssh-keyscan operation failed (attempt 6/8): failed to retrieve the SSH keys from "gitlab.<domain>.com", please review that the hostname is correct, and that your network configuration permits traffic between Okteto and "gitlab.<domain>.com": exit status 1Retrying ssh-keyscan operation in 32s (attempt 7/8)ssh-keyscan operation failed (attempt 7/8): failed to retrieve the SSH keys from "gitlab.<domain>.com", please review that the hostname is correct, and that your network configuration permits traffic between Okteto and "gitlab.<domain>.com": exit status 1Retrying ssh-keyscan operation in 1m4s (attempt 8/8)ssh-keyscan operation failed after 8 attemptsssh-keyscan failed after 8 attempts: failed to retrieve the SSH keys from "gitlab.<domain>.com", please review that the hostname is correct, and that your network configuration permits traffic between Okteto and "gitlab.<domain>.com": exit status 1error in FinishPipeline: Post "https://okteto.dev.<domain>.com/graphql": read tcp 10.255.222.9:40228->172.20.237.72:443: read: connection reset by peer`

---

<div class="post-metadata">

**Author:** ![ramiro](https://sea1.discourse-cdn.com/flex019/user_avatar/community.okteto.com/ramiro/32/6_2.png) [@ramiro](https://community.okteto.com/u/ramiro)\
**Post date:** [October 13, 2025, 4:33pm UTC](https://community.okteto.com/t/issue-with-new-ssh-known-hosts-feature-host-registered-but-still-not-found/1431/8 "2025-10-13T16:33:42Z")

</div>

Thanks, I’m following up internally to see if this is a bug or known issue. To help us speed out the resolution, [could you share your support bundle](https://www.okteto.com/docs/self-hosted/manage/diagnostics/)?

Also, is there anything unique about your gitlab instance that can help us diagnose this? (e.g. features disabled, custom configurations, etc…).

And what cloud provider/Kubernetes provider/Kubernetes version are you hosting Okteto on?

---

<div class="post-metadata">

**Author:** ![marticardus](https://sea1.discourse-cdn.com/flex019/user_avatar/community.okteto.com/marticardus/32/611_2.png) [@marticardus](https://community.okteto.com/u/marticardus)\
**Post date:** [October 14, 2025, 7:11am UTC](https://community.okteto.com/t/issue-with-new-ssh-known-hosts-feature-host-registered-but-still-not-found/1431/9 "2025-10-14T07:11:56Z")

</div>

Hi @ramiro ,

Here is our support bundle [https://drive.google.com/file/d/1GABWm0ZRKVSwG01ekdNICAV2icV1YySF/view?usp=drive\_link](https://drive.google.com/file/d/1GABWm0ZRKVSwG01ekdNICAV2icV1YySF/view?usp=drive_link)

Our GitLab and Okteto installations are hosted in the same cluster of Kubernetes with EKS version 1.32.

To enable SSH in GitLab, I’ve configured Load Balancer with proxy protocol. All services working on same LB with ingress-nginx

---

<div class="post-metadata">

**Author:** ![ramiro](https://sea1.discourse-cdn.com/flex019/user_avatar/community.okteto.com/ramiro/32/6_2.png) [@ramiro](https://community.okteto.com/u/ramiro)\
**Post date:** [October 14, 2025, 3:51pm UTC](https://community.okteto.com/t/issue-with-new-ssh-known-hosts-feature-host-registered-but-still-not-found/1431/10 "2025-10-14T15:51:08Z")

</div>

Hey,

The team confirmed that this is a bug, they are already working on a fix. We will update this thread when the fix is ready for you to consume it.

Thanks for your patience with this!

---

<div class="post-metadata">

**Author:** ![jLopezbarb](https://sea1.discourse-cdn.com/flex019/user_avatar/community.okteto.com/jlopezbarb/32/48_2.png) [@jLopezbarb](https://community.okteto.com/u/jLopezbarb)\
**Post date:** [October 15, 2025, 3:35pm UTC](https://community.okteto.com/t/issue-with-new-ssh-known-hosts-feature-host-registered-but-still-not-found/1431/11 "2025-10-15T15:35:29Z")

</div>

Hi Martí,  
We’ve identified an issue in the known hosts implementation where the `ssh-keyscan` command was being executed during deployment even when the known hosts file was already enabled, this shouldn’t have happened. The unnecessary execution of `ssh-keyscan` caused the deployment to fail. This behavior has been fixed and available in chart release 1.37.2.

In your case, the `ssh-keyscan` failure appears to be caused by a connection issue. Since `ssh-keyscan` will no longer run in the new version, any connection problems might now appear during the repository clone step instead. Although the fix prevents the `ssh-keyscan` issue, the underlying connectivity problem might still affect the cloning process.

After upgrading to the new release, please:

1. Check if the connection problem persists.
2. Verify your network configuration, particularly:   
• That the target host is reachable from the deployment environment.   
• DNS resolution for the Git server works as expected.   
• Firewall or proxy rules are not blocking outbound SSH traffic.   
• The correct SSH port (usually 22) is open and accessible.

Let us know if the issue continues after upgrading, we’ll be happy to help troubleshoot further.

---

<div class="post-metadata">

**Author:** ![marticardus](https://sea1.discourse-cdn.com/flex019/user_avatar/community.okteto.com/marticardus/32/611_2.png) [@marticardus](https://community.okteto.com/u/marticardus)\
**Post date:** [October 16, 2025, 7:59am UTC](https://community.okteto.com/t/issue-with-new-ssh-known-hosts-feature-host-registered-but-still-not-found/1431/12 "2025-10-16T07:59:52Z")

</div>

Hi,

I believe the issue is caused by our GitLab instance being behind a Load Balancer with the Proxy Protocol enabled (for SSH connections).

This bug seems to be fixed in the latest update, but I think the underlying cause of the problem is still present.

> Deploying Dev Environment  
> initialized kubernetes client with InClusterConfig  
> checkout command: ‘[git clone --depth 1 ssh://git@gitlab.ourdomain.com/repo.git -b pre /okteto/src]’  
> Cloning git repository ‘ssh://git@gitlab.ourdomain.com/repo.git’ branch ‘pre’…Cloning into ‘/okteto/src’…  
> Running okteto pipeline at:
> 
> - Commit: 83c7558852e2e6e257abef581e080fac43d9d78b
> - Message: add missing cache tokens fields  
> okteto information:
> - okteto cli version: v3.12.0  
> executing ‘okteto context’…  
> x Internal server error, please try again  
> exit status 1  
> error in FinishPipeline: Post “https:// okteto.dev.ourdomain .com/graphql”: read tcp 10.255.222.10:35642-\>172.20.237.72:443: read: connection reset by peer

As you can see, it’s trying to connect to the internal ingress service, but it fails because it expects a Proxy-type connection, while only a standard HTTP request is being sent — that’s why the connection doesn’t work.

Kind regards

---

<div class="post-metadata">

**Author:** ![marticardus](https://sea1.discourse-cdn.com/flex019/user_avatar/community.okteto.com/marticardus/32/611_2.png) [@marticardus](https://community.okteto.com/u/marticardus)\
**Post date:** [October 27, 2025, 10:04am UTC](https://community.okteto.com/t/issue-with-new-ssh-known-hosts-feature-host-registered-but-still-not-found/1431/13 "2025-10-27T10:04:26Z")

</div>

This issue has been resolved.

The SSH Known Hosts bug has been fixed in Okteto, and the connectivity problem was solved by configuring the official Okteto ingresses as **ClusterIP** services behind my main ingress controller.

Everything is now working as expected. Thanks to the Okteto team for the quick fix!
