Error checking tls connection docker - Исправление ошибок и поиск оптимальных решений проблем

After I restarted my windows i cannot connect to docker machine running in Oracle Virtual Box.
When i start Docker QuickStart Terminal every thing looks fine, it’s coming up OK and it gives me this message:

docker is configured to use the default machine with IP 192.168.99.100
For help getting started, check out the docs at https://docs.docker.com

but when i do:

$ docker-machine ls
NAME      ACTIVE   DRIVER       STATE     URL   SWARM   DOCKER   ERRORS
default   -        virtualbox   Timeout

and:

λ docker images
An error occurred trying to connect: Get http://localhost:2375/v1.21/images/json: dial tcp 127.0.0.1:2375: ConnectEx tcp: No connection could be made because the target machine actively refused it.

also when i try to reinitialize my env., i get:

λ docker-machine env default
Error checking TLS connection: Error checking and/or regenerating the certs: There was an error validating certificates for host "192.168.99.100:2376": dial tcp 192.168.99.100:2376: i/o timeout
You can attempt to regenerate them using 'docker-machine regenerate-certs [name]'.
Be advised that this will trigger a Docker daemon restart which will stop running containers.

BTW, Regenerating certs also not helping.
Any idea?

Thanks.

asked Jan 6, 2016 at 19:17

Please try regenerating certificates manually by:

docker-machine --debug regenerate-certs -f default

and check for any errors to fix, then try again:

docker-machine --debug env default

If it’s failing on ssh, copy and paste that command into terminal to see what’s the problem by adding extra -vv.

If you’ve got:

debug1: connect to address 127.0.0.1 port 64368: Connection refused

then your machine isn’t running (check by docker-machine ls), so try:

docker-machine start

Then try to ssh to it via:

docker-machine -D ssh default

answered Mar 11, 2016 at 12:34

kenorbkenorb

149k80 gold badges668 silver badges723 bronze badges

After doing some research I found out that following workaround may solve the issue for now:

Open Network And Sharing Center
Click on Change Adapter Setting
See if you have any enabled adapters such as VPN or VM Ware network adapters.
Try to disable them and try to connect to your container one more time
If it didn’t work while you have other adapters disabled, Restart your PC — in my case this worked for me.

Mogsdad

44k20 gold badges151 silver badges272 bronze badges

answered Jan 7, 2016 at 2:17

HazhirHazhir

7801 gold badge6 silver badges18 bronze badges

What worked for me is this answer from the docker-machine repo:

docker-machine regenerate-certs --client-certs [name]

Basically, what expired is client certificates. The error message I get from docker-machine is similar to yours (i.e., no indication it’s the client certs that need to be regenerated).

answered Sep 7, 2020 at 1:31

munsumunsu

1,84419 silver badges23 bronze badges

I fix it doing this:

Removed all host-only interfaces from my VirtualBox (VirtualBox → Preferences → Network → Host-only networks).
rmdir.exe --ignore-fail-on-non-empty ~/.docker/
docker-machine start
docker-machine env
eval $("C:Program FilesDocker Toolboxdocker-machine.exe" env default) (added also at the end of my .bash_profile).
docker run hello-world ← now working

Inspired in this post.

answered Sep 1, 2016 at 20:46

Pablo BianchiPablo Bianchi

1,6781 gold badge23 silver badges30 bronze badges

Here is what worked for me. The first steps are similar to what Hazhir proposed, then followed by regenerate the certificates.

Open Network And Sharing Center.
Click on Change Adapter Setting.
Disable all active VMWare network adapters. Usually has explanation «VirtualBox Host-Only Ethernet Adapter».
Connect to your container by running docker-machine start.
Run docker-machine env. If you’re like me then you’d get following error:

Error checking TLS connection: Error checking and/or regenerating the
certs: There was an error validating certificates for host
«192.168.99.100:2376»: x509: certificate is valid for 192.168.99.101,
not 192.168.99.100

Which is good. Now all we need to do is to run

docker-machine regenerate-certs -f default

Then test it again with docker-machine env. If you get:

SET DOCKER_TLS_VERIFY=1
SET DOCKER_HOST=tcp://192.168.99.100:2376
SET DOCKER_CERT_PATH=C:UsersJay.dockermachinemachinesdefault
SET DOCKER_MACHINE_NAME=default
REM Run this command to configure your shell:
REM     FOR /f "tokens=*" %i IN ('docker-machine env') DO %i

Then you’re all set. In my case I needed to start my virtual machine by running Docker Quickstart Terminal.

answered Mar 25, 2016 at 16:55

jaycodejaycode

2,9164 gold badges34 silver badges71 bronze badges

I have this problem too. Execute docker-machine regenerate-certs <vm-name> can not solve problem. I search Google the error info and find the solution below.

execute sudo ifconfig vboxnet0 up in terminal.
show docker machine state: docker-machine ls.
now STATE and URL are ok.

But restart the system this problem persists.

GitHub issues link I found is here.

It seems there is a bug in VirtualBox 5.1.24.

answered Jul 27, 2017 at 8:13

invzhiinvzhi

361 silver badge2 bronze badges

Just start the docker machine and then regenerate certificates

docker-machine start <machine-name>

docker-machine regenerate-certs <machine-name>

It works like a charm for me.

answered Mar 12, 2019 at 8:42

Asad ShakeelAsad Shakeel

1,7651 gold badge22 silver badges27 bronze badges

None of the answers here helped me. My problem occurred when I want to activate the shell of my virtual machine with eval $(docker-machine env default).

It was then trying to access the port 2376 which was closed, so I had to enter the shell of the VM through ssh and activate the following UFW rule:

sudo ufw allow 2376

answered Oct 8, 2020 at 19:28

The way I ensure being able to connect to my docker machines is by assigning them a fixed IP (and regenerating the certs only once) (no reboot needed)

After that, docker-machine ls always work.

My current script:
(replace %PRGS%dmlatest by the path where docker-machine.exe is on your machine)
(make sure PATH include the latest /path/to/git/usr/bin, for commands like ssh to be available)

> more dmvbf.bat
@echo off
setlocal enabledelayedexpansion
set machine=%1
if "%machine%" == "" (
        echo dmvbf expects a machine name
        exit /b 1
)
set ipx=%2
if "%ipx%" == "" (
        echo dmvbf x missing ^(for 192.168.x.y^)
        exit /b 2
)
set ipy=%3
if "%ipy%" == "" (
        echo dmvbf y missing ^(for 192.168.x.y^)
        exit /b 3
)

%PRGS%dmlatestdocker-machine.exe ssh %machine% "sudo sh -c 'echo "kill $(more /var/run/udhcpc.eth1.pid)" | sudo tee /var/lib/boot2docker/bootsync.sh >/dev/null'"
%PRGS%dmlatestdocker-machine ssh %machine% "sudo sh -c 'echo "ifconfig eth1 192.168.%ipx%.%ipy% netmask 255.255.255.0 broadcast 192.168.%ipx%.255 up" | sudo tee -a /var/lib/boot2docker/bootsync.sh >/dev/null'"

%PRGS%dmlatestdocker-machine ssh %machine% "sudo chmod 755 /var/lib/boot2docker/bootsync.sh"

%PRGS%dmlatestdocker-machine ssh %machine% "sudo cat /var/run/udhcpc.eth1.pid | xargs sudo kill"

%PRGS%dmlatestdocker-machine ssh %machine% "sudo ifconfig eth1 192.168.%ipx%.%ipy% netmask 255.255.255.0 broadcast 192.168.%ipx%.255 up"

For instance:

dmvbf default 99 100
docker-machine regenerate-certs -f default

That will assign 192.168.99.100 to the docker machine ‘default‘, and regenerate the certs once.
Then each time docker-machine ls is called, it will display the same IP for ‘default‘.

answered Mar 21, 2016 at 11:41

VonCVonC

1.2m508 gold badges4248 silver badges5069 bronze badges

Try this way/workaround:

firstly make sure there are ca.pem, cert.pem, key.pem, ca-key.pem under $yourhome/.docker/machine/certs/ folder , for these lost four *.pem files, you can copy them from other places or maybe create them yourselves ( these four pem files are surely not correct at the beginning )
make sure the env set correctly in bash_profile, like:
export DOCKER_HOST=tcp://192.168.99.100:2376
export DOCKER_MACHINE_NAME=default
export DOCKER_TLS_VERIFY=1
export DOCKER_CERT_PATH=/Users/johnwang/.docker/machine/machines/default
rerun the cmd: docker-machine regenerate-certs default (maybe before run this, you need reopen the docker terminal)
Tried on docker toolbox on mac, and it works.
Finally some logs of the result:
Error checking TLS connection: Error checking and/or regenerating the certs: There was an error validating certificates for host «192.168.99.100:2376»: x509: certificate signed by unknown authority
You can attempt to regenerate them using ‘docker-machine regenerate-certs [name]’.
Be advised that this will trigger a Docker daemon restart which might stop running containers.
…
…
johns-MacBook-Pro:certs johnwang$ docker-machine regenerate-certs default
Regenerate TLS machine certs? Warning: this is irreversible. (y/n): y
Regenerating TLS certificates
Waiting for SSH to be available…
Detecting the provisioner…
Copying certs to the local machine directory…
Copying certs to the remote machine…
Setting Docker configuration on the remote daemon…
johns-MacBook-Pro:certs johnwang$ docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS
default — virtualbox Running tcp://192.168.99.100:2376 v17.03.1-ce

Hope it helps
also see my response here:https://github.com/docker/machine/issues/2808

answered Apr 7, 2017 at 7:17

In my case it was my FortiClient that caused the issue. After disabling it docker-machine env default worked fine again. I suggest you to check if there’s any anti-virus program running in your system.

answered May 24, 2017 at 15:46

GusterGuster

1,6041 gold badge16 silver badges18 bronze badges

for me, running

docker-machine --debug regenerate-certs -f name_of_your_vm

worked just fine.

docker-machine version 0.16.1
virtualBox 6.0

also docker was configured to use the default machine with IP 192.168.99.100

answered Mar 7, 2019 at 15:28

aureliusaurelius

3,8866 gold badges40 silver badges73 bronze badges

I had the same error. I fixed it by open tcp port 2376 in network firewall.

answered Nov 26, 2019 at 0:13

The solution for my problem is taken from here:
https://github.com/docker/machine/issues/3845#issuecomment-271935924

Quote:

If you install docker-machine first time then you do not have in that
host a self-signed CA that will be used to generate your client
certificate and as many server certificates as machines you generate
later on. That CA is generated when you try to create a machine if
that CA is not yet created. So if you try to generate several servers
in parallel (by means of an script), then you’ll generate as many
self-signed (root) CA as docker createcommands, all of them being
written in the same location that seems to be messing up the
environment e.g. spreading out different ca.pem to the remote machines
that do match the final version, causing the cert.pem (host identity)
to be signed by a former ca.pem which no longer exist… or whatever
other abnormal situation.

To fix it, first of all you’ll need to delete your existing
self-signed CA. This can be done by removing the folder
~/.docker/machine/certs (NOTE: Note this will force the creation of a
new self-signed CA for docker-machine to use and will yield your
existing machines to fail connecting to the daemon). This will make
your docker-machine to generate valid certificates again. Then, for my
use case I am creating the first machine in foreground and all the
rest of them are done in parallel. That will cause the creation of one
root self-signed CA in isolation and then will be used for further
docker-machine create commands. It worked like a charm!

The reason why I was able to ssh to the host is because there are a
different pair of keys for sshing generate per host that was not
bitten by this.

To sum up, this is what I ended up doing:

Find out what is the command that docker-machine is running. I was using it with gitlab-runner, So I had to run gitlab-runner in debug mode to see what command was it running on docker-machine.
then stop gitlab-runner: gitlab-runner stop
then delete the certificate: rm -rf ~/.docker/machine/certs
then run a single command (from step #1) to re-create the certs (remember — the reason this didn’t work is because it was trying to create it multiple times)
then rerun gitlab-runner: gitlab-runner start

Worked for me!

answered Jun 3, 2021 at 6:43

For reader using `brew` in 2021, after your somehow upgrade `virtualbox` cask

System Preferences… > Security & Privacy > (Unlock with finger) Allow.
<<Your Computer Should Restart>>.
docker-machine restart default. Done

answered Jul 21, 2021 at 7:04

VimNingVimNing

1,7814 gold badges27 silver badges56 bronze badges

Источник

I was running windows 10 home edition.
And I was trying to run latest version of Docker Toolbox but hit with error message «This compute doesn’t have VT-x/AMD-V enabled, enabling it in the BIOS is mandatory».
So before I enabled the virtualization in BIOS,

1> I removed my existing ‘default’ virtual machine with below command.
docker-machine rm default

Rebooted my laptop and enabled the Virtualization in BIOS Setup. (I am using HP iCore 5, x64 bit machine)

2> Created the new default vm with below command
docker-machine create default —driver virtualbox
*output
Running pre-create checks…
Creating machine…
(default) Copying C:Usershp.dockermachinecacheboot2docker.iso to C:Usershp.dockermachinemachinesdefaultboot2docker.iso…
(default) Creating VirtualBox VM…
(default) Creating SSH key…
(default) Starting the VM…
(default) Check network to re-create if needed…
(default) Windows might ask for the permission to configure a dhcp server. Sometimes, such confirmation window is minimized in the taskbar.
(default) Waiting for an IP…
Waiting for machine to be running, this may take a few minutes…
Detecting operating system of created instance…
Waiting for SSH to be available…
Detecting the provisioner…
Provisioning with boot2docker…
Copying certs to the local machine directory…
Copying certs to the remote machine…
Setting Docker configuration on the remote daemon…
Checking connection to Docker…
Docker is up and running!
To see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine env default

3> But when I run the below command, I still had the error.
docker version
Client:
Version: 19.03.1
API version: 1.40
Go version: go1.12.7
Git commit: 74b1e89e8a
Built: Wed Jul 31 15:18:18 2019
OS/Arch: windows/amd64
Experimental: false

error during connect: Get http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.40/version: open //./pipe/docker_engine: The system cannot find the file specified. In the default daemon configuration on Windows, the docker client must be run elevated to connect. This error may also indicate that the docker daemon is not running

So to overcome the above error

4> docker-machine env default
SET DOCKER_TLS_VERIFY=1
SET DOCKER_HOST=tcp://192.168.99.100:2376
SET DOCKER_CERT_PATH=C:Usershp.dockermachinemachinesdefault
SET DOCKER_MACHINE_NAME=default
SET COMPOSE_CONVERT_WINDOWS_PATHS=true
REM Run this command to configure your shell:
REM @for /f «tokens=*» %i IN (‘docker-machine env default’) DO @%i

5> So to configure the Shell run the below command and this successfully setup the Docker Daemon.
@for /f «tokens=*» %i IN (‘docker-machine env default’) DO @%i

6> Verify the docker client and server
docker version
Client:
Version: 19.03.1
API version: 1.40
Go version: go1.12.7
Git commit: 74b1e89e8a
Built: Wed Jul 31 15:18:18 2019
OS/Arch: windows/amd64
Experimental: false

Server: Docker Engine — Community
Engine:
Version: 19.03.5
API version: 1.40 (minimum version 1.12)
Go version: go1.12.12
Git commit: 633a0ea838
Built: Wed Nov 13 07:28:45 2019
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: v1.2.10
GitCommit: b34a5c8af56e510852c35414db4c1f4fa6172339
runc:
Version: 1.0.0-rc8+dev
GitCommit: 3e425f80a8c931f88e6d94a8c831b9d5aa481657
docker-init:
Version: 0.18.0
GitCommit: fec3683

Источник

Содержание

Coding Question
Monday, March 28, 2016
Error checking TLS connection: Error checking and/or regenerating the certs
5 Answers
Answers 1
Answers 2
Answers 3
Answers 4
Answers 5
Подключения TLS могут завершаться сбоем или тайм-аутом при соединении или попытке возобновления
Проблемы
Причина
Дальнейшие действия
Дополнительные сведения для администраторов
Затронутые обновления
OpenVPN TLS key negotiation failed

Coding Question

Monday, March 28, 2016

Error checking TLS connection: Error checking and/or regenerating the certs

After I restarted my windows i cannot connect to docker machine running in Oracle Virtual Box. When i start Docker QuickStart Terminal every thing looks fine, it’s coming up OK and it gives me this message:

also when i try to reinitialize my env., i get:

BTW, Regenerating certs also not helping. Any idea?

5 Answers

Answers 1

After doing some research I found out that following workaround may solve the issue for now:

Open Network And Sharing Center
Click on Change Adapter Setting
See if you have any enabled adapters such as VPN or VM Ware network adapters.
Try to disable them and try to connect to your container one more time
If it didn’t work while you have other adapters disabled, Restart your PC — in my case this worked for me.

I’ll try to find a permanent solution, any idea appreciated.

Thanks in advance.

Answers 2

Please try regenerating certificates manually by:

and check for any errors to fix, then try again:

If it’s failing on ssh, copy and paste that command into terminal to see what’s the problem by adding extra -vv .

debug1: connect to address 127.0.0.1 port 64368: Connection refused

then your machine isn’t running (check by docker-machine ls ), so try:

Then try to ssh to it via:

Answers 3

The way I ensure being able to connect to my docker machines is by assigning them a fixed IP (and regenerating the certs only once) (no reboot needed)

After that, docker-machine ls always work.

My current script:
(replace %PRGS%dmlatest by the path where docker-machine.exe is on your machine)
(make sure PATH include the latest /path/to/git/usr/bin, for commands like ssh to be available)

That will assign 192.168.99.100 to the docker machine ‘ default ‘, and regenerate the certs once.
Then each time docker-machine ls is called, it will display the same IP for ‘ default ‘.

Answers 4

I am having a similar problem. Any direction would help. The «docker-machine -D ssh default» Allows me to login and work the container. but it still bugs me as to why do I see this error?

Copying certs to the local machine directory. Copying certs to the remote machine. Setting Docker configuration on the remote daemon.

This machine has been allocated an IP address, but Docker Machine could not reach it successfully.

SSH for the machine should still work, but connecting to exposed ports, such as the Docker daemon port (usually :2376), may not work properly.

You may need to add the route manually, or use another related workaround.

This could be due to a VPN, proxy, or host file configuration issue.

You also might want to clear any VirtualBox host only interfaces you are not using. Checking connection to Docker. Error creating machine: Error checking the host: Error checking and/or regenerating the certs: There was an error validating certificates for host «192.168.99.100:2376»: dial tcp 192.168.99.100:2376: i/o timeout You can attempt to regenerate them using ‘docker-machine regenerate-certs [name]’. Be advised that this will trigger a Docker daemon restart which will stop running containers.

Error checking TLS connection: Error checking and/or regenerating the certs: There was an error validating certificates for host «192.168.99.100:2376»: dial tcp 192.168.99.100:2376: i/o timeout You can attempt to regenerate them using ‘docker-machine regenerate-certs [name]’. Be advised that this will trigger a Docker daemon restart which will stop running containers.

docker is configured to use the default machine with IP 192.168.99.100 For help getting started, check out the docs at https://docs.docker.com

$ docker-machine ls NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS default virtualbox Timeout
$docker-machine -D ssh default Docker Machine Version: 0.6.0, build e27fb87 Found binary path at /usr/local/bin/docker-machine Launching plugin server for driver virtualbox Plugin server listening at address 127.0.0.1:50515 () Calling .GetVersion . .

$docker-machine regenerate-certs -f default Regenerating TLS certificates Waiting for SSH to be available. Detecting the provisioner. Copying certs to the local machine directory. Copying certs to the remote machine. Setting Docker configuration on the remote daemon.

This machine has been allocated an IP address, but Docker Machine could not reach it successfully.

SSH for the machine should still work, but connecting to exposed ports, such as the Docker daemon port (usually :2376), may not work properly.

You may need to add the route manually, or use another related workaround.

This could be due to a VPN, proxy, or host file configuration issue.

You also might want to clear any VirtualBox host only interfaces you are not using. $

Answers 5

Here is what worked for me. The first steps are similar to what Hazhir proposed, then followed by regenerate the certificates.

Open Network And Sharing Center.
Click on Change Adapter Setting.
Disable all active VMWare network adapters. Usually has explanation «VirtualBox Host-Only Ethernet Adapter».
Connect to your container by running docker-machine start .
Run docker-machine env . If you’re like me then you’d get following error:

Error checking TLS connection: Error checking and/or regenerating the certs: There was an error validating certificates for host «192.168.99.100:2376»: x509: certificate is valid for 192.168.99.101, not 192.168.99.100

Which is good. Now all we need to do is to run

Then test it again with docker-machine env . If you get:

Then you’re all set. In my case I needed to start my virtual machine by running Docker Quickstart Terminal.

Источник

Подключения TLS могут завершаться сбоем или тайм-аутом при соединении или попытке возобновления

Проблемы

При попытке соединения может происходить сбой или тайм-аут TLS. Вы также можете получить одну или несколько из указанных ниже ошибок.

«Запрос прерван: не удалось создать безопасный канал SSL/TLS»

Ошибка, зарегистрированная в журнале системных событий для события SCHANNEL 36887 с кодом предупреждения 20 и описанием, «С удаленной конечной точки получено оповещение о неустранимой ошибке. Определенный в протоколе TLS код оповещения о неустранимой ошибке: 20».

Причина

В связи с принудительным применением CVE-2019-1318 из соображений безопасности все обновления для поддерживаемых версий Windows, выпущенные 8 октября 2019 г. или позже, применяют Extended Master Secret (EMS) для возобновления, как определено в RFC 7627. При подключении к сторонним устройствам и ОС, которые не соответствуют требованиям, могут возникать проблемы и сбои.

Дальнейшие действия

После полного обновления соединения между двумя устройствами под управлением любой поддерживаемой версии Windows не должны иметь этой ошибки. Для этой ошибки обновление Windows не требуется. Эти изменения необходимы для устранения неполадок безопасности и соответствия требованиям безопасности.

Все сторонние операционные системы, устройства и службы, которые не поддерживают возобновление EMS, могут проявлять проблемы, связанные с подключениями TLS. Обратитесь к администратору, изготовителю или поставщику услуг за обновлениями, которые полностью поддерживают возобновление EMS, как определено в RFC 7627.

Примечание. Корпорация Майкрософт не рекомендует отключать EMS. Если служба EMS была явным образом отключена ранее, ее можно снова включить, задав следующие значения в разделе реестра:

На сервере TLS — DisableServerExtendedMasterSecret: 0
На клиенте TLS — DisableClientExtendedMasterSecret: 0

Дополнительные сведения для администраторов

1. На устройстве с Windows, которое пытается установить TLS-подключение к устройству, которое не поддерживает Extended Master Secret (EMS), при согласовании комплектов шифров TLS_DHE_* может иногда возникать сбой, приблизительно в 1 попытке из 256. Чтобы устранить эту ошибку, реализуйте одно из следующих решений, указанных в порядке предпочтения.

Включите поддержку расширений Extend Master Secret (EMS) при выполнении TLS-подключений как в клиентской, так и в серверной операционной системе.

Для операционных систем, которые не поддерживают EMS, удалите комплекты шифров TLS_DHE_* из списка комплектов шифров в ОС клиентского устройства TLS. Инструкции о том, как это сделать в Windows, см в разделе Определение приоритета для комплектов шифров Schannel.

2. Операционные системы, которые отправляют сообщения запроса сертификата только в режиме полного подтверждения после возобновления, не соответствуют стандарту RFC 2246 (TLS 1.0) или RFC 5246 (TLS 1.2) и приводят к сбою каждого подключения. Возобновление не гарантируется в соответствии со спецификацией RFC, но оно может быть использовано по усмотрению клиента и сервера TLS. При возникновении этой проблемы необходимо обратиться к производителю или поставщику услуг за обновлениями, которые соответствуют стандартам RFC.

3. FTP-серверы или клиенты, не совместимые с RFC 2246 (TLS 1.0) и RFC 5246 (TLS 1.2), могут не передавать файлы при возобновлении или сокращенном подтверждении, и это приведет к сбою каждого подключения. При возникновении этой проблемы необходимо обратиться к производителю или поставщику услуг за обновлениями, которые соответствуют стандартам RFC.

Затронутые обновления

Эта проблема может возникать для любого последнего накопительного обновления (LCU) или ежемесячных накопительных пакетов, выпущенных 8 октября 2019 года или позже, для затронутых платформ:

KB4517389 LCU для Windows 10, версия 1903.

KB4519338 LCU для Windows 10 версии 1809 и Windows Server 2019.

KB4520008 LCU для Windows 10, версия 1803.

KB4520004 LCU для Windows 10, версия 1709.

KB4520010 LCU для Windows 10, версия 1703.

KB4519998 LCU для Windows 10 версии 1607 и Windows Server 2016.

KB4520011 LCU для Windows 10, версия 1507.

KB4520005 Ежемесячный накопительный пакет для Windows 8.1 и Windows Server 2012 R2.

KB4520007 Ежемесячный накопительный пакет обновления для Windows Server 2012.

KB4519976 Ежемесячный накопительный пакет для Windows 7 SP1 и Windows Server 2008 R2 SP1.

KB4520002 Ежемесячный накопительный пакет обновления для Windows Server 2008 SP2

Эта проблема может возникать для следующих обновлений системы безопасности, выпущенных 8 октября 2019 года, для затронутых платформ:

KB4519990 Обновление для системы безопасности для Windows 8.1 и Windows Server 2012 R2.

KB4519985 Обновление для системы безопасности для Windows Server 2012 и Windows Embedded 8 Standard.

KB4520003 Обновление для системы безопасности для Windows 7 SP1 и Windows Server 2008 R2 SP1

KB4520009 Обновление для системы безопасности Windows Server 2008 SP2

Источник

OpenVPN TLS key negotiation failed

Проблема с OpenVPN, не удается подключиться, выдает ошибку TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

Команда nc -z -v -u 1194 выдает Connection to 1194 port [udp/openvpn] succeeded!

В /etc/default/ufw поставил DEFAULT_FORWARD_POLICY=»ACCEPT»

В /etc/ufw/before.rules добавил

ip_forward включил командой sysctl -w net.ipv4.ip_forward=1

Сам OpenVPN сервер работает, с самого сервера пингуется, но с клиентской машины не подключается.

Показывай конфиг. А ещё почитай, как оформлять сообщения

port 1194
proto udp4
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn/ipp.txt
keepalive 10 120
tls-auth ta.key 0
cipher AES-256-CBC
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
verb 3
explicit-exit-notify 1

client
dev tun
proto udp4
remote 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert m.romanov.crt
key m.romanov.key
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
verb 3

На клиенте в типовой конфигурации nat/POSTROUTING не нужен

10.8.0.0/8 — правда что ли? Может всё же /16 ?

tcpdump в руки и смотреть трафик

маску исправил
при вводе команды sudo tcpdump -i tun0 вообще никакого трафика нет

Добавь вывод логов ( log , если ничего не путаю) как на сервере, так и на клиенте

А что с настройкой аутентификации тлс ключа на сервере/клиенте? Настраивалось?

Сгенерировал ключ, добавил ссылку на него в конфиг сервера, скопировал его в архив клиента и в конфиге клиета тоже прописал ссылку на него.

Лог сервера и клиента закинь плиз

Думается мне, что ты напутал кому какой ключ закинуть. Есть конечно опция в опенвпн, включение которой решит проблему. Но так делать нельзя.

2021-09-14 16:06:17.577274 MANAGEMENT: CMD ‘hold release’
2021-09-14 16:06:17.577398 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
2021-09-14 16:06:17.587378 Outgoing Control Channel Authentication: Using 160 bit message hash ‘SHA1’ for HMAC authentication
2021-09-14 16:06:17.587401 Incoming Control Channel Authentication: Using 160 bit message hash ‘SHA1’ for HMAC authentication
2021-09-14 16:06:17.588225 TCP/UDP: Preserving recently used remote address: [AF_INET]:1194
2021-09-14 16:06:17.588283 Socket Buffers: R=[786896->786896] S=[9216->9216]
2021-09-14 16:06:17.588298 UDPv4 link local: (not bound)
2021-09-14 16:06:17.588310 UDPv4 link remote: [AF_INET]:1194
2021-09-14 16:06:17.588358 MANAGEMENT: >STATE:1631624777,WAIT.
2021-09-14 16:07:17.945518 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2021-09-14 16:07:17.945629 TLS Error: TLS handshake failed
2021-09-14 16:07:17.946528 SIGUSR1[soft,tls-error] received, process restarting
2021-09-14 16:07:17.946767 MANAGEMENT: >STATE:1631624837,RECONNECTING,tls-error.

Tue Sep 14 16:26:28 2021 us=28209 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 19 2021
Tue Sep 14 16:26:28 2021 us=28263 library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10
Tue Sep 14 16:26:28 2021 us=29086 PKCS#11: pkcs11_initialize — entered
Tue Sep 14 16:26:28 2021 us=29205 PKCS#11: pkcs11_initialize — return 0-‘CKR_OK’
Tue Sep 14 16:26:28 2021 us=38450 Diffie-Hellman initialized with 2048 bit key
Tue Sep 14 16:26:28 2021 us=39103 PRNG init md=SHA1 size=36
Tue Sep 14 16:26:28 2021 us=39238 Outgoing Control Channel Authentication: Using 160 bit message hash ‘SHA1’ for HMAC authentication
Tue Sep 14 16:26:28 2021 us=39258 Outgoing Control Channel Authentication: HMAC KEY: 0fc45afa 55a73232 65bd4bfb 81290e1d 3151819d
Tue Sep 14 16:26:28 2021 us=39269 Outgoing Control Channel Authentication: HMAC size=20 block_size=20
Tue Sep 14 16:26:28 2021 us=39282 Incoming Control Channel Authentication: Using 160 bit message hash ‘SHA1’ for HMAC authentication
Tue Sep 14 16:26:28 2021 us=39299 Incoming Control Channel Authentication: HMAC KEY: 3c546ee3 a63a358c b29fe550 29d0315b ce5842ee
Tue Sep 14 16:26:28 2021 us=39312 Incoming Control Channel Authentication: HMAC size=20 block_size=20
Tue Sep 14 16:26:28 2021 us=39327 crypto_adjust_frame_parameters: Adjusting frame parameters for crypto by 28 bytes
Tue Sep 14 16:26:28 2021 us=39359 TLS-Auth MTU parms [ L:1621 D:1184 EF:66 EB:0 ET:0 EL:3 ]
Tue Sep 14 16:26:28 2021 us=39373 MTU DYNAMIC mtu=1450, flags=2, 1621 -> 1450
Tue Sep 14 16:26:28 2021 us=42251 ROUTE_GATEWAY 10.0.0.1
Tue Sep 14 16:26:28 2021 us=44507 TUN/TAP device tun0 opened
Tue Sep 14 16:26:28 2021 us=45831 TUN/TAP TX queue length set to 100
Tue Sep 14 16:26:28 2021 us=45931 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Tue Sep 14 16:26:28 2021 us=45957 /sbin/ip link set dev tun0 up mtu 1500
Tue Sep 14 16:26:28 2021 us=61732 /sbin/ip addr add dev tun0 local 10.8.0.1 peer 10.8.0.2
Tue Sep 14 16:26:28 2021 us=65209 /sbin/ip route add 10.8.0.0/24 via 10.8.0.2
Tue Sep 14 16:26:28 2021 us=69537 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ]
Tue Sep 14 16:26:28 2021 us=69631 Socket Buffers: R=[212992->212992] S=[212992->212992]
Tue Sep 14 16:26:28 2021 us=69681 UDPv4 link local (bound): [AF_INET][undef]:1194
Tue Sep 14 16:26:28 2021 us=69696 UDPv4 link remote: [AF_UNSPEC]
Tue Sep 14 16:26:28 2021 us=69724 MULTI: multi_init called, r=256 v=256
Tue Sep 14 16:26:28 2021 us=69774 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0
Tue Sep 14 16:26:28 2021 us=69817 IFCONFIG POOL LIST
Tue Sep 14 16:26:28 2021 us=69869 PO_INIT maxevents=4 flags=0x00000002
Tue Sep 14 16:26:28 2021 us=71700 Initialization Sequence Completed
Tue Sep 14 16:26:28 2021 us=71756 SCHEDULE: schedule_find_least NULL
Tue Sep 14 16:26:28 2021 us=71774 PO_CTL rwflags=0x0001 ev=6 arg=0x560340717198
Tue Sep 14 16:26:28 2021 us=71787 PO_CTL rwflags=0x0001 ev=5 arg=0x560340717068
Tue Sep 14 16:26:28 2021 us=71806 I/O WAIT TR|Tw|SR|Sw [10/0]
Tue Sep 14 16:26:28 2021 us=71829 PO_WAIT[1,0] fd=5 rev=0x00000001 rwflags=0x0001 arg=0x560340717068
Tue Sep 14 16:26:28 2021 us=71843 event_wait returned 1
Tue Sep 14 16:26:28 2021 us=71856 I/O WAIT status=0x0004
Tue Sep 14 16:26:28 2021 us=71999 read from TUN/TAP returned 48
Tue Sep 14 16:26:28 2021 us=72028 SCHEDULE: schedule_find_least NULL
Tue Sep 14 16:26:28 2021 us=72042 PO_CTL rwflags=0x0001 ev=6 arg=0x560340717198
Tue Sep 14 16:26:28 2021 us=72055 PO_CTL rwflags=0x0001 ev=5 arg=0x560340717068
Tue Sep 14 16:26:28 2021 us=72071 I/O WAIT TR|Tw|SR|Sw [10/0]
Tue Sep 14 16:26:32 2021 us=191847 PO_WAIT[1,0] fd=5 rev=0x00000001 rwflags=0x0001 arg=0x560340717068
Tue Sep 14 16:26:32 2021 us=191943 event_wait returned 1
Tue Sep 14 16:26:32 2021 us=191960 I/O WAIT status=0x0004
Tue Sep 14 16:26:32 2021 us=191989 MULTI: REAP range 0 -> 16
Tue Sep 14 16:26:32 2021 us=192016 read from TUN/TAP returned 48
Tue Sep 14 16:26:32 2021 us=192055 SCHEDULE: schedule_find_least NULL
Tue Sep 14 16:26:32 2021 us=192069 PO_CTL rwflags=0x0001 ev=6 arg=0x560340717198
Tue Sep 14 16:26:32 2021 us=192080 PO_CTL rwflags=0x0001 ev=5 arg=0x560340717068
Tue Sep 14 16:26:32 2021 us=192107 I/O WAIT TR|Tw|SR|Sw [10/0]

Источник

Typically, the QuickStart works out-of-the-box, but some scenarios can cause problems.

Example errors

You might get errors when attempting to connect to a machine (such as with docker-machine env default) or pull an image from Docker Hub (as with docker run hello-world).

The errors you get might be specific to certificates, like this:

  Error checking TLS connection: Error checking and/or regenerating the certs: There was an error validating certificates for host "192.168.99.100:2376": dial tcp 192.168.99.100:2376: i/o timeout

Others will explicitly suggest regenerating certificates:

  Error checking TLS connection: Error checking and/or regenerating the certs: There was an error validating certificates for host "192.168.99.100:2376": x509: certificate is valid for 192.168.99.101, not 192.168.99.100
  You can attempt to regenerate them using 'docker-machine regenerate-certs [name]'.
  Be advised that this will trigger a Docker daemon restart which will stop running containers.

Or, indicate a network timeout, like this:

  bash-3.2$ docker run hello-world
  Unable to find image 'hello-world:latest' locally
  Pulling repository docker.io/library/hello-world
  Network timed out while trying to connect to https://index.docker.io/v1/repositories/library/hello-world/images. You may want to check your internet connection or if you are behind a proxy.
  bash-3.2$

Solutions

Here are some quick solutions to help get back on track. These examples assume the Docker host is a machine called default.

Regenerate certificates

Some errors explicitly tell you to regenerate certificates. You might also try this for other errors that are certificate and /or connectivity related.

  $ docker-machine regenerate-certs default
    Regenerate TLS machine certs?  Warning: this is irreversible. (y/n): y
    Regenerating TLS certificates

Restart the Docker host

$ docker-machine restart default

After the machine starts, set the environment variables for the command window.

$ eval $(docker-machine env default)

Run docker-machine ls to verify that the machine is running and that this command window is configured to talk to it, as indicated by an asterisk for the active machine (*).

$ docker-machine ls
NAME             ACTIVE   DRIVER         STATE     URL                         SWARM   DOCKER    ERRORS
default          *        virtualbox     Running   tcp://192.168.99.101:2376           v1.10.1

Stop the machine, remove it, and create a new one.

$ docker-machine stop default
  Stopping "default"...
  Machine "default" was stopped.

$ docker-machine rm default
  About to remove default
  Are you sure? (y/n): y
  Successfully removed default

You can use the command docker-machine create command with the virtualbox driver to create a new machine called default (or any name you want for the machine).

$ docker-machine create --driver virtualbox default
  Running pre-create checks...
  (default) Default Boot2Docker ISO is out-of-date, downloading the latest release...
  (default) Latest release for github.com/boot2docker/boot2docker is v1.10.1
  (default) Downloading
  ...
  Docker is up and running!
  To see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine env default

Set the environment variables for the command window.

$ eval $(docker-machine env default)

Run docker-machine ls to verify that the new machine is running and that this command window is configured to talk to it, as indicated by an asterisk for the active machine (*).

## HTTP proxies and connectivity errors

A special brand of connectivity errors can be caused by HTTP proxy. If you install Docker Toolbox on a system using a virtual private network (VPN) that uses an HTTP proxy (such as a corporate network), you might encounter errors when the client attempts to connect to the server.

Here are examples of this type of error:

  $ docker run hello-world
  An error occurred trying to connect: Post https://192.168.99.100:2376/v1.20/containers/create: Forbidden

  $ docker run ubuntu echo "hi"
  An error occurred trying to connect: Post https://192.168.99.100:2376/v1.20/containers/create: Forbidden

Configuring HTTP proxy settings on Docker machines

When Toolbox creates virtual machines (VMs) it runs start.sh, where it gets values for HTTP_PROXY, HTTPS_PROXY and NO_PROXY, and passes them as create options to create the default machine.

You can reconfigure HTTP proxy settings for private networks on already-created Docker machines (e.g., default), then change the configuration when you are using the same system on a different network.

Alternatively, you can modify proxy settings on your machine(s) manually through the configuration file at /var/lib/boot2docker/profile inside the VM, or configure proxy settings as a part of a docker-machine create command.

Both solutions are described below.

Update /var/lib/boot2docker/profile on the Docker machine

One way to solve this problem is to update the file /var/lib/boot2docker/profile on an existing machine to specify the proxy settings you want.

This file lives on the VM itself, so you have to ssh into the machine, then edit and save the file there.

You can add your machine addresses as values for a NO_PROXY setting, and also specify proxy servers that you know about and you want to use. Typically setting your Docker machine URLs to NO_PROXY solves this type of connectivity problem, so that example is shown here.

Use ssh to log in to the virtual machine (e.g., default).

 $ docker-machine ssh default
 docker@default:~$ sudo vi /var/lib/boot2docker/profile

Add a NO_PROXY setting to the end of the file similar to the example below.

 # replace with your office's proxy environment
 export "HTTP_PROXY=http://PROXY:PORT"
 export "HTTPS_PROXY=http://PROXY:PORT"
 # you can add more no_proxy with your environment.
 export "NO_PROXY=192.168.99.*,*.local,169.254/16,*.example.com,192.168.59.*"

Restart Docker.

After you modify the profile on your VM, restart Docker and log out of the machine.
```
 docker@default:~$ sudo /etc/init.d/docker restart
 docker@default:~$ exit
```

Re-try Docker commands. Both Docker and Kitematic should run properly now.

When you move to a different network (for example, leave the office’s corporate network and return home), remove or comment out these proxy settings in /var/lib/boot2docker/profile and restart Docker.

Create machines manually using –engine env to specify proxy settings

Rather than reconfigure automatically-created machines, you can delete them and create your default machine and others manually with the docker-machine create command, using the --engine env flag to specify the proxy settings you want.

Here is an example of creating a default machine with proxies set to http://example.com:8080 and https://example.com:8080, and a N0_PROXY setting for the server example2.com.

docker-machine create -d virtualbox 
--engine-env HTTP_PROXY=http://example.com:8080 
--engine-env HTTPS_PROXY=https://example.com:8080 
--engine-env NO_PROXY=example2.com 
default

To learn more about using docker-machine create, see the create command in the Docker Machine reference.

Источник

Error getting IP address: ssh command error: command : ip addr show err : exit status 255 #887

Comments

dimascool08 commented May 2, 2020

Error checking TLS connection: ssh command error:
command : ip addr show
err : exit status 255
output :
Error checking TLS connection: ssh command error:
command : ip addr show
err : exit status 255
output :

Error getting IP address: ssh command error:
command : ip addr show
err : exit status 255
output :
docker is configured to use the default machine with IP
For help getting started, check out the docs at https://docs.docker.com

Start interactive shell

The text was updated successfully, but these errors were encountered:

yosef-elementryx commented Jun 23, 2020

docker-machine rm default

purplezimmermann commented Oct 1, 2020

I just found a less destructive solution to the same problem on my Windows 10 machine, and an interesting reason

There are two OpenSSH clients installed in my system: The standalone Windows release and the MSYS2 package. Depending on the one that is used to create the Docker machine, the other does not work to access it afterwards, bailing out with exactly the same error as described above, most probably due to different key files used (I haven’t checked that detail yet)

So I just had to make sure that in all my shells and shell session configurations the same SSH client comes first in %PATH% and the problem was gone

Due to the often many duplications of Unix tools like OpenSSH coming as dependencies or bundled with other ported Unix applications to Windows, and ending up wildly in %PATH% , that mess could very likely be the actual reason for this issue on other Windows machines as well

Источник

RHEL 7.2 provisioning fails on cloud drivers #3180

Comments

ahmetb commented Mar 11, 2016

It all started a couple of months ago when we first noticed some connectivity issues to port 2376 in Azure on redhat enterprise linux images –and this was outside docker-machine. However I can clearly reproduce this error on Google Compute Engine as well and since it is an already released driver I will be providing repro for it.

GCE repro steps

This will fail trying to ssh Error running SSH command: exit status 127 . Here is the debug output: https://gist.github.com/ahmetalpbalkan/7776a1fb01e36681797d

When I go to VM I can see docker running just fine:

and it works just fine:

Azure repro steps

Weird enough, Azure does fail just a bit differently, but again, Docker is installed and running on port :2376 but this time, I cannot reach out to this machine using env .

Findings so far

It doesn’t happen on Ubuntu, CoreOS, CentOS; so it may be just RHEL.
It’s not just Azure, it happens on GCE too, just manifests itself differently.
Apps running on other ports (e.g. port 80) work just fine. There’s something about :2376.
This is not just docker-machine issue. We can repro this in azure-docker-extension as well.
azure: telnet ip 2376 works but docker client doesn’t (it hangs).

The text was updated successfully, but these errors were encountered:

Источник

Error checking TLS connection: Error checking and/or regenerating the certs

After I restarted my windows i cannot connect to docker machine running in Oracle Virtual Box. When i start Docker QuickStart Terminal every thing looks fine, it’s coming up OK and it gives me this message:

also when i try to reinitialize my env., i get:

BTW, Regenerating certs also not helping. Any idea?

16 Answers 16

Please try regenerating certificates manually by:

and check for any errors to fix, then try again:

If it’s failing on ssh, copy and paste that command into terminal to see what’s the problem by adding extra -vv .

debug1: connect to address 127.0.0.1 port 64368: Connection refused

then your machine isn’t running (check by docker-machine ls ), so try:

Then try to ssh to it via:

After doing some research I found out that following workaround may solve the issue for now:

Open Network And Sharing Center

Click on Change Adapter Setting

See if you have any enabled adapters such as VPN or VM Ware network adapters.

Try to disable them and try to connect to your container one more time

If it didn’t work while you have other adapters disabled, Restart your PC — in my case this worked for me.

What worked for me is this answer from the docker-machine repo:

Basically, what expired is client certificates. The error message I get from docker-machine is similar to yours (i.e., no indication it’s the client certs that need to be regenerated).

I fix it doing this:

Removed all host-only interfaces from my VirtualBox (VirtualBox → Preferences → Network → Host-only networks).
rmdir.exe —ignore-fail-on-non-empty

/.docker/

docker-machine start

docker-machine env

eval $(«C:Program FilesDocker Toolboxdocker-machine.exe» env default) (added also at the end of my .bash_profile ).

docker run hello-world ← now working

Here is what worked for me. The first steps are similar to what Hazhir proposed, then followed by regenerate the certificates.

Open Network And Sharing Center.
Click on Change Adapter Setting.
Disable all active VMWare network adapters. Usually has explanation «VirtualBox Host-Only Ethernet Adapter».
Connect to your container by running docker-machine start .
Run docker-machine env . If you’re like me then you’d get following error:

Error checking TLS connection: Error checking and/or regenerating the certs: There was an error validating certificates for host «192.168.99.100:2376»: x509: certificate is valid for 192.168.99.101, not 192.168.99.100

Which is good. Now all we need to do is to run

Then test it again with docker-machine env . If you get:

Then you’re all set. In my case I needed to start my virtual machine by running Docker Quickstart Terminal.

I have this problem too. Execute docker-machine regenerate-certs can not solve problem. I search Google the error info and find the solution below.

execute sudo ifconfig vboxnet0 up in terminal.
show docker machine state: docker-machine ls .
now STATE and URL are ok.

But restart the system this problem persists.

GitHub issues link I found is here.

It seems there is a bug in VirtualBox 5.1.24.

Just start the docker machine and then regenerate certificates

It works like a charm for me.

None of the answers here helped me. My problem occurred when I want to activate the shell of my virtual machine with eval $(docker-machine env default).

It was then trying to access the port 2376 which was closed, so I had to enter the shell of the VM through ssh and activate the following UFW rule:

The way I ensure being able to connect to my docker machines is by assigning them a fixed IP (and regenerating the certs only once) (no reboot needed)

After that, docker-machine ls always work.

My current script:
(replace %PRGS%dmlatest by the path where docker-machine.exe is on your machine)
(make sure PATH include the latest /path/to/git/usr/bin, for commands like ssh to be available)

That will assign 192.168.99.100 to the docker machine ‘ default ‘, and regenerate the certs once.
Then each time docker-machine ls is called, it will display the same IP for ‘ default ‘.

Try this way/workaround:

firstly make sure there are ca.pem, cert.pem, key.pem, ca-key.pem under $yourhome/.docker/machine/certs/ folder , for these lost four *.pem files, you can copy them from other places or maybe create them yourselves ( these four pem files are surely not correct at the beginning )
make sure the env set correctly in bash_profile, like: export DOCKER_HOST=tcp://192.168.99.100:2376 export DOCKER_MACHINE_NAME=default export DOCKER_TLS_VERIFY=1 export DOCKER_CERT_PATH=/Users/johnwang/.docker/machine/machines/default
rerun the cmd: docker-machine regenerate-certs default (maybe before run this, you need reopen the docker terminal) Tried on docker toolbox on mac, and it works.
Finally some logs of the result: Error checking TLS connection: Error checking and/or regenerating the certs: There was an error validating certificates for host «192.168.99.100:2376»: x509: certificate signed by unknown authority You can attempt to regenerate them using ‘docker-machine regenerate-certs [name]’. Be advised that this will trigger a Docker daemon restart which might stop running containers. . . johns-MacBook-Pro:certs johnwang$ docker-machine regenerate-certs default Regenerate TLS machine certs? Warning: this is irreversible. (y/n): y Regenerating TLS certificates Waiting for SSH to be available. Detecting the provisioner. Copying certs to the local machine directory. Copying certs to the remote machine. Setting Docker configuration on the remote daemon. johns-MacBook-Pro:certs johnwang$ docker-machine ls NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS default — virtualbox Running tcp://192.168.99.100:2376 v17.03.1-ce

In my case it was my FortiClient that caused the issue. After disabling it docker-machine env default worked fine again. I suggest you to check if there’s any anti-virus program running in your system.

worked just fine.

also docker was configured to use the default machine with IP 192.168.99.100

I had the same error. I fixed it by open tcp port 2376 in network firewall.

If you install docker-machine first time then you do not have in that host a self-signed CA that will be used to generate your client certificate and as many server certificates as machines you generate later on. That CA is generated when you try to create a machine if that CA is not yet created. So if you try to generate several servers in parallel (by means of an script), then you’ll generate as many self-signed (root) CA as docker createcommands, all of them being written in the same location that seems to be messing up the environment e.g. spreading out different ca.pem to the remote machines that do match the final version, causing the cert.pem (host identity) to be signed by a former ca.pem which no longer exist… or whatever other abnormal situation.

To fix it, first of all you’ll need to delete your existing self-signed CA. This can be done by removing the folder

/.docker/machine/certs (NOTE: Note this will force the creation of a new self-signed CA for docker-machine to use and will yield your existing machines to fail connecting to the daemon). This will make your docker-machine to generate valid certificates again. Then, for my use case I am creating the first machine in foreground and all the rest of them are done in parallel. That will cause the creation of one root self-signed CA in isolation and then will be used for further docker-machine create commands. It worked like a charm!

The reason why I was able to ssh to the host is because there are a different pair of keys for sshing generate per host that was not bitten by this.

To sum up, this is what I ended up doing:

Find out what is the command that docker-machine is running. I was using it with gitlab-runner, So I had to run gitlab-runner in debug mode to see what command was it running on docker-machine.

then stop gitlab-runner: gitlab-runner stop

then delete the certificate: rm -rf

then run a single command (from step #1) to re-create the certs (remember — the reason this didn’t work is because it was trying to create it multiple times)

then rerun gitlab-runner: gitlab-runner start

Источник

Докер «ждет IP» при запуске или создании новой машины

Я изо всех сил пытался решить эту проблему в течение нескольких дней.

Попытка реализовать настройку WSL и VirtualBox в Windows 10 Pro. Причины не имеют отношения к проблеме, но использование Hyper-V не вариант. Попытка реализовать в соответствии с:

Будь я использую Docker Toolbox или просто Docker docker-machine , результаты неизменно одинаковы. «Запуск от имени администратора» просто создает виртуальные машины под учетной записью администратора, чего я тоже не хочу. Пробовал rm и воссоздал виртуальные машины несколько десятков раз.

В основном, создавая новую машину или пытаясь запустить ее, я получаю эту ошибку:

Ошибка создания машины: ошибка в драйвере при создании машины: слишком много попыток в ожидании доступности SSH. Последняя ошибка: превышено максимальное количество повторов (60)

Это все еще создает машину, но state timeout :

Я делаю docker-machine env default и получаю следующее:

Виртуальная машина обнаруживается в VirtualBox и имеет тот же сетевой адаптер, что и другие мои рабочие виртуальные машины (в том смысле, что они могут подключаться к Интернету) за исключением «Адаптера 2». Это не на других моих виртуальных машинах:

Docker VM имеет следующее в терминале:

Кроме того, я прошел через следующие предложения, и ничто не решило проблему. Решения обычно включают воссоздание виртуальной машины.

Кроме того, мой хост находится в сети 192.168.1.x.

ОБНОВЛЕНИЕ:

VBoxManager.exe и docker-machine.exe находятся в одном каталоге.

1 ответ 1

TL; DR «Ожидание IP» отображается, когда docker-machine хочет подключить гостевую машину с хоста. Возможные причины: в брандмауэре заблокирована только хост-сеть, отключен DHCP, неправильная настройка IPv4 и т.д.

Intel VT-x включен в BIOS
Windows 10 64 бит с последней версией Ubuntu (или другого дистрибутива GNU/Linux), установленной в WSL
64-разрядная версия VirtualBox и Hyper-V отключены
Docker Machine 64 бит для Windows (имя файла docker-machine-Windows-x86_64.exe)
Предварительные знания о сети и док-машине

VirualBox Guest (также хост Docker): облегченный образ GNU/Linux для boot2docker для Docker
VirtualBox Host: Windows 10 64 бит
Docker Client: docker-ce в Ubuntu WSL
Используемый диапазон IPv4 в интерфейсе Host-Only: от 192.168.99.0 до 192.168.99.255, т. Е. 192.168.99.0/24 с включенным DHCP. Вы можете изменить это как хотите, но DHCP важен для Docker Machine

Я перешел по ссылке на статью, приведенную в вопросе. Установите клиент docker-ce в Ubuntu WSL с помощью следующих команд:

Теперь вернитесь к хост-машине Windows 10. Выполните эти шаги соответственно:

Загрузите Docker Machine 64 bit для Windows. Скопируйте файл docker-machine-Windows-x86_64.exe в папку установки VirtualBox или добавьте переменную среды VBOX_INSTALL_PATH чтобы исполняемый файл докера мог найти VBoxManage.exe .

Добавьте виртуальный интерфейс только для хоста из окна VirtualBox Manager. Затем настройте все необходимые конфигурации IPv4 в этом окне или через панель управления сетью ncpa.cpl . Можно использовать любые частные адреса IPv4 . Вот скриншоты:

В панели управления сетью:

В окне VirtualBox Manager:

Источник

Содержание

Error getting IP address: ssh command error: command : ip addr show err : exit status 255 #887
Comments
dimascool08 commented May 2, 2020
yosef-elementryx commented Jun 23, 2020
purplezimmermann commented Oct 1, 2020
RHEL 7.2 provisioning fails on cloud drivers #3180
Comments
ahmetb commented Mar 11, 2016
GCE repro steps
Azure repro steps
Findings so far
docker-machine env fails to check certs, fails to generate certs #2808
Comments
robbles commented Jan 11, 2016
nathanleclaire commented Jan 11, 2016
robbles commented Jan 12, 2016
dirn commented Jan 14, 2016
alexcouper commented Mar 4, 2016
zhen6939 commented Apr 8, 2016
Environment
How my issue arose
What’s my issue
What I think about this issue:
adanselm commented Jul 4, 2016
Coding Question
Monday, March 28, 2016
Error checking TLS connection: Error checking and/or regenerating the certs
5 Answers
Answers 1
Answers 2
Answers 3
Answers 4
Answers 5
No connection to Docker deamon on OS X Docker Toolbox #3163
Comments
franz-josef-kaiser commented Mar 8, 2016
franz-josef-kaiser commented Mar 9, 2016
nathanleclaire commented Mar 10, 2016
franz-josef-kaiser commented Mar 10, 2016
nathanleclaire commented Mar 10, 2016
franz-josef-kaiser commented Mar 10, 2016
nathanleclaire commented Mar 10, 2016

Error getting IP address: ssh command error: command : ip addr show err : exit status 255 #887

Start interactive shell

The text was updated successfully, but these errors were encountered:

docker-machine rm default

I just found a less destructive solution to the same problem on my Windows 10 machine, and an interesting reason

So I just had to make sure that in all my shells and shell session configurations the same SSH client comes first in %PATH% and the problem was gone

Источник

RHEL 7.2 provisioning fails on cloud drivers #3180

GCE repro steps

This will fail trying to ssh Error running SSH command: exit status 127 . Here is the debug output: https://gist.github.com/ahmetalpbalkan/7776a1fb01e36681797d

When I go to VM I can see docker running just fine:

and it works just fine:

Azure repro steps

Weird enough, Azure does fail just a bit differently, but again, Docker is installed and running on port :2376 but this time, I cannot reach out to this machine using env .

Findings so far

It doesn’t happen on Ubuntu, CoreOS, CentOS; so it may be just RHEL.
It’s not just Azure, it happens on GCE too, just manifests itself differently.
Apps running on other ports (e.g. port 80) work just fine. There’s something about :2376.
This is not just docker-machine issue. We can repro this in azure-docker-extension as well.
azure: telnet ip 2376 works but docker client doesn’t (it hangs).

The text was updated successfully, but these errors were encountered:

Источник

docker-machine env fails to check certs, fails to generate certs #2808

On OSX 10.9.5, docker-machine 0.5.3 and 0.5.6.

./docker-machine env dev gives the following error:

Running docker-machine regenerate-certs dev results in:

I tried copying the new certs over manually from

/.docker/machine/certs , but it didn’t fix the initial problem. My guess is that it has nothing to do with the certs being missing on the remote machine, but I don’t know how to troubleshoot past this point.

The text was updated successfully, but these errors were encountered:

Did the create fail in the first place? env and regenerate-certs won’t be much help if create did not return successfully.

@nathanleclaire this is a machine that was created successfully and has been working without any problems for a month or more. I updated docker-machine and ran into this issue.

I’m also having the same issue.

The machine was created a while ago, but I haven’t used it in months. It starts just fine. I can ssh into it ( docker-machine ssh [name] ). Most commands seem to work.

docker-machine config and docker-machine env fail checking the certs. docker-machine regenerate-certs fails with no such file or directory .

I’m also having this issue after upgrading docker toolbox to 1.10.2.

OSX: 10.11.1
docker-machine: 0.6.0
virtualbox: 5.0.14

Have any of you that have had this issue found a way around it?

I’m having the same symptoms:

I have the same issue and also notice that the issue is similar with #1159

But the issue’s still there.

Environment

Mac OS 10.11.3
Docker version 1.10.3, build 20f81dd
docker-machine version 0.6.0, build e27fb87

How my issue arose

Docker worked fine before I upgrade homebrew. Homebrew reminds me to link docker

After running the command upon, I got this message:

then, I ran this commend:

What’s my issue

When I wanna regenerate-certs, got this error message:

What I think about this issue:

Since certs can’t be copied to the local machine directory, I think that specifying the machine dir or copying the certs manually would fix the issue.

Unfortunately, I don’t know how to fix exactly. 😢

If anyone knows how to fix, please pin here, thanks.

I’m having exactly the same issue as @robbles
A machine that has been running for months. I can still ssh on it, but can’t rebuild the docker-compose conf now that I have changes to apply, because of the failing certs.
I upgraded the docker daemon on the server but with no impact on this issue.

Источник

Coding Question

Monday, March 28, 2016

Error checking TLS connection: Error checking and/or regenerating the certs

After I restarted my windows i cannot connect to docker machine running in Oracle Virtual Box. When i start Docker QuickStart Terminal every thing looks fine, it’s coming up OK and it gives me this message:

also when i try to reinitialize my env., i get:

BTW, Regenerating certs also not helping. Any idea?

5 Answers

Answers 1

After doing some research I found out that following workaround may solve the issue for now:

Open Network And Sharing Center
Click on Change Adapter Setting
See if you have any enabled adapters such as VPN or VM Ware network adapters.
Try to disable them and try to connect to your container one more time
If it didn’t work while you have other adapters disabled, Restart your PC — in my case this worked for me.