Learn how to fix the “SSH from GitLab-CI Docker Fails on SSH2 MSG KEX ECDH REPLY ” error. Our Docker Support team is here to assist you with any questions or concerns you may have.

SSH2 MSG KEX ECDH REPLY Error | Resolved

When working with GitLab CI/CD, establishing an SSH connection from a Docker container can sometimes lead to this error:

SSH2_MSG_KEX_ECDH_REPLY failed

This error alerts us to compatibility issues between the SSH client in the GitLab Docker runner and the target SSH server. It often involves misconfigured SSH keys, disabled key exchange algorithms, or network connectivity problems.

Today, we will examine the causes and potential solutions to address the problem.

About the Error

When running SSH commands from a GitLab CI/CD pipeline (especially using Docker executors), we may encounter a connection failure with the `SSH2_MSG_KEX_ECDH_REPLY` error. This is commonly caused by:

• SSH algorithm mismatch between client and server.
• SSH key issues in the pipeline.
• Missing pseudo-terminal (PTY) support inside the container.
• Network restrictions or firewall rules blocking port 22.
• GitLab CI runner is not configured for SSH access properly.

If you’re working with Docker-based apps and notice Apache or FastCGI behaving unexpectedly, our guide on Docker Apache FastCGI issues might be helpful as well.

Solution 1: Specify the SSH Key Exchange Algorithm

In some environments, like older servers, some key exchange algorithms are not supported by default. One way to resolve this is to define the algorithm when connecting:

ssh -o KexAlgorithms=ecdh-sha2-nistp521 user@192.168.1.100Copy Code

This command forces the SSH client to use the `ecdh-sha2-nistp521` algorithm, which may match what the server supports and avoid handshake failures like SSH2 MSG KEX ECDH REPLY.

Solution 2: PTY and Docker Limitations

When running SSH from within a Docker container—such as in GitLab CI—there’s no terminal (TTY) by default. If the SSH server requests interactive input during the handshake, the client fails.

This is seen when using:

docker-compose exec -TCopy Code

The `-T` flag disables TTY allocation. Without a TTY, OpenSSH cannot perform keyboard-interactive authentication, leading to connection errors.

On a local Ubuntu terminal (with a TTY), the same SSH command may work perfectly.

Encountering unexpected behavior in Docker containers? You may also want to review this article on container configuration errors.

Solution 3: Use a GitLab Self-Hosted Runner

We can set up a self-hosted GitLab shell runner directly on our staging server. With this setup, the GitLab CI/CD pipeline can push updates or deploy code without needing to SSH from another machine.

1. First, install a shell runner on the target machine.
2. Then, define a GitLab CI job that uses this specific runner.
3. Let the runner handle all Git operations locally.

Alternatively, GitLab also supports an SSH executor, which lets the runner SSH into remote servers. While this approach also works, it requires more setup and configuration.

Curious about more advanced Docker tools? Our guide on Docker Buildx dives into efficient multi-architecture builds.

Solution 4: Debugging Network Issues

Sometimes, the problem is due to a basic network connectivity issue between the GitLab runner and the target host.

From the host running the GitLab runner, run:

telnet 192.168.100.201 22Copy Code

Or:

nc -zv 192.168.100.201 22Copy Code

Then, on the target server (`192.168.100.201`), check if the SSH service is up and listening:

ps aux | grep sshd
netstat -plant | grep :22Copy Code

We can also test SSH connectivity locally on the server with:

telnet localhost 22Copy Code

This can help us verify if firewalls, Docker networking, or host restrictions are causing the failure.

Also, if you’ve seen the “connect ENOENT” Docker error recently, our deep dive into this common issue may offer additional clarity.

[Need assistance with a different issue? Our team is available 24/7.]

Conclusion

The SSH2 MSG KEX ECDH REPLY error in GitLab CI/CD is usually due to SSH configuration mismatches, unsupported key exchange algorithms, or network-level restrictions.

In brief, our Support Experts demonstrated how to fix the “SSH from GitLab-CI Docker Fails on SSH2_MSG_KEX_ECDH_REPLY” error.