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

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

Источник

I have a remote Windows host running a docker instance and the default docker-machine vm. When I SSH into the host and attempt to run any docker-machine commands, i.e.

> eval $(docker-machine env default --shell bash)

docker-machine emits «Error checking TLS connection: Host is not running.»

I searched on StackOverflow and found cases where others regenerated the certs and had success, so I tried this but no luck. I restarted the docker-machine vm and again, no luck.

I can use the docker-machine commands fine if they’re run locally and not over ssh, but I will need to be able to eventually ssh into the host and run the commands. I’m using openssh on cygwin. PATH is set up appropriately, and if I put the output of the env command into my .ssh/environment file I’m even able to run docker commands like docker ps. I just can’t interact with the docker-machine vm.

Auguste

1,9172 gold badges16 silver badges25 bronze badges

asked Jun 20, 2016 at 18:26

Firstly, if you’re using Hyper-V (and possibly in some other configurations) you’ll need to use an elevated shell for docker-machine.

You might be able to follow documentation to allow non-elevated interaction with Hyper-V (I haven’t tested this with docker-machine so YMMV).

One trick that does work is to run docker-machine env VMNAME in your elevated environment to get the general outline. Then look up the MAC address for your VM and hardcode it into a helpful script for yourself. For example; for a machine named «MYMACHINE» with a MAC address 00-15-5D-00-00-01 the following scripts will point docker at the right machine from a non-elevated shell (by resolving the IP from your system’s arp table):

bash:

VM_MACADDR="00-15-5D-00-00-01"
export DOCKER_MACHINE_NAME="MYMACHINE"
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://`arp -a | grep -i $VM_MACADDR | grep -o '[0-9]+.[0-9]+.[0-9]+.[0-9]+'`:2376"
export DOCKER_CERT_PATH="$USERPROFILE.dockermachinemachines$DOCKER_MACHINE_NAME"
export COMPOSE_CONVERT_WINDOWS_PATHS="true"

PowerShell:

$VM_MACADDR="00-15-5D-00-00-01"
$Env:DOCKER_MACHINE_NAME="MYMACHINE"
$Env:DOCKER_TLS_VERIFY = "1"
$Env:DOCKER_HOST = "tcp://$((Get-NetNeighbor -LinkLayerAddress $VM_MACADDR -AddressFamily IPv4 | Select-Object -First 1).IPAddress):2376"
$Env:DOCKER_CERT_PATH = "$env:USERPROFILE.dockermachinemachines$Env:DOCKER_MACHINE_NAME"
$Env:COMPOSE_CONVERT_WINDOWS_PATHS = "true"

answered Jan 13, 2020 at 21:58

Tyler SzaboTyler Szabo

9761 gold badge7 silver badges23 bronze badges

Источник

Содержание

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]

Источник

Содержание

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

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:

docker-machine rm default

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

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:

Источник

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

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.