Spring Cloud Config strictHostKeyChecking and ignoreLocalSshSettings are not working in spring cloud config server

We are running the spring config server on Eks pods. Service needs to clone the git repo during startup using SSH. We have the key pair generated, and it works fine locally on a VM, i.e outside the cloud environment, but breaks inside the k8s pod. After investing, we found the issue is that the config server looks for .ssh/known_hosts and the server key for validation. We have since run in pods that obviously cannot be set up as .ssh/know_hosts. We tried using the property below to ignore these checks, but the config server doesn't respect this property.

//application.yml
type: git
cloneOnStart: true
uri: ssh://git@*******.com/xx/yyy.git
skipSslValidation: true
ignoreLocalSshSettings: true
strictHostKeyChecking: false
privateKey: |
-----BEGIN RSA PRIVATE KEY-----
*****************
*****************
-----END RSA PRIVATE KEY-----

// exception
Exception:
Caused by org.eclipse.jgit.api.errors.TransportException: ssh://git@****.com/xx/yyy.git: Server key did not validate
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:249)
....
....
at org.springframework.cloud.config.server.environment.JGitEnvironnmentRepository.cloneToBaseDir(JGitEnvironmentRepository.java:659)
...
...
Caused by org.eclipse.jgit.api.errors.TransportException: ssh://git@****.com/xx/yyy.git: Server key did not validate
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:249)
at org.eclipse.jgit.transport.sshd.SshdSessionFactory.getSession(SshdSessionFactory.java:267) 

Comment From: ryanjbaxter

Does it work if you do not use cloneOnStart? Can you provide the complete application.yaml?

Comment From: himnay

Hi Ryan, There is nothing wrong with the property setup or hierarchy. As I told you, it works perfectly when you have a .ssh/known_hosts and sshkey domain and validation key. I have alternately put this code to make it work on the eks pod, i.e. I need to make sure SshSessionFactory uses PropertyBasedSshSessionFactory instead of SshdSessionFactory explicitly. This behaviour is a bug or needs to be documented.

    @Bean
    public SshSessionFactory sshSessionFactory() {
        Map<String, JGitEnvironmentProperties> sshKeysByHostName = new HashMap<>();
        JGitEnvironmentProperties gitProperties = new JGitEnvironmentProperties();
        gitProperties.setUri("ssh://git@git.your-repo.com/xx/yyy.git");
        gitProperties.setPrivateKey(
            "-----BEGIN RSA PRIVATE KEY-----\n"
            + "MIIEowIBAAKCAQEA... (your private key content here) ...\n"
            + "-----END RSA PRIVATE KEY-----\n"
        );
        gitProperties.setStrictHostKeyChecking(false);


        sshKeysByHostName.put("git.your-repo.com", gitProperties);
        PropertyBasedSshSessionFactory factory = new PropertyBasedSshSessionFactory(sshKeysByHostName);
        SshSessionFactory.setInstance(factory);

        return factory;
    }

Comment From: ryanjbaxter

But you seem to be saying that the configuration to used PropertyBasedSshSessionFactory works fine unless you are running the application on Kubernetes, so I am trying to understand the cause of that. To me it seems like something might be wrong with the configuration when running on Kubernetes.

Comment From: himnay

PropertyBasedSshSessionFactory is never getting used(no matter its in or out of the k8s pod) without explicitly creating and setting it in SshSessionFactory. At present, current behaviours use only SshdSessionFactory. The spring configuration server uses properties to initiate its internal beans but only uses SshdSessionFactory.

Comment From: ryanjbaxter

Can you provide a complete, minimal, verifiable sample that reproduces the problem? It should be available as a GitHub (or similar) project or attached to this issue as a zip file.

Comment From: spring-cloud-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: spring-cloud-issues

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.