I have docker-engine installed on a linux VM on my company data center. I installed docker-machine on my windows. I want to manage this docker-engine through my windows machine. I want to add this host and for that I executed the following command:
docker-machine create -d generic --generic-ip-address 10.51.227.5 --generic-ssh-port 22 --generic-ssh-user root compute
But I am getting the following error after waiting for couple of minutes
Running pre-create checks...
Creating machine...
(compute) No SSH key specified. Connecting to this machine now and in the future will require the ssh agent to contain the appropriate key.
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Error creating machine: Error detecting OS: Too many retries waiting for SSH to be available. Last error: Maximum number of retries (60) exceeded
I don't know what I am doing wrong.
Try using native SSH
Unfortunately, this can happen for multiple reasons, but since you say you're running on Windows, I have a guess. Try using the native SSH client - that is, the Go library that ships with Docker, rather than ssh.exe. To do so, pass the --native-ssh argument to docker-machine:
docker-machine --native-ssh create --driver generic --generic-ip-address example.com ExampleMachine
Examining debug output
You can examine various debugging messages by passing the --debug argument. When I did that, and did not specify the --native-ssh argument, I got lots of error messages:
> docker-machine create --driver generic --generic-ip-address example.com ExampleMachine
<...snip...>
Waiting for SSH to be available...
Getting to WaitForSSH function...
(apsylania) Calling .GetSSHHostname
(apsylania) Calling .GetSSHPort
(apsylania) Calling .GetSSHKeyPath
(apsylania) Calling .GetSSHKeyPath
(apsylania) Calling .GetSSHUsername
Using SSH client type: external
&{[-F /dev/null -o PasswordAuthentication=no -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o LogLevel=quiet -o ConnectionAttempts=3 -o ConnectTimeout=10 -o ControlMaster=no -o ControlPath=none root#example.com -o IdentitiesOnly=yes -i C:\Users\MyAccount\.docker\machine\machines\ExampleMachine\id_rsa -p 22] C:\Program Files\OpenSSH-Win64\ssh.exe <nil>}
About to run SSH command:
exit 0
SSH cmd err, output: exit status 255:
Error getting ssh command 'exit 0' : ssh command error:
command : exit 0
err : exit status 255
output :
Getting to WaitForSSH function...
<...snip...>
My guess, after trying to pass --generic-ssh-key with backslashes on Windows and having it produce an error, was that Docker (still) isn't quite as polished on Windows as it could be, and I wondered if there was something buggy about the way it calls out to an external SSH client. Since using the native Go SSH client worked for me, I think that my guess was correct, at least for my case.
Related
I'm using SSH to pass a command to a remote machine. The command is to update my Plex Media Server, so in long form it is:
ssh myhost $PATHTOPLEXSCANNER -c 3 -s
The "-c 3 -s" are arguments that the Plex Media Scanner needs. I can't leave the -c out.
When I run this in a script, I get an error: "Unknown cipher type '3'". I know this is because SSH is interpreting the -c part of the argument as a cipher specification.
If I type this command in at the prompt, it runs fine.
If I run the exact same command in a script, I receive the cipher error.
How can I pass the "-c 3 -s" arguments to the remote machine?
The full command is:
ssh myhost '/Applications/Plex\ Media\ Server.app/Contents/MacOS/Plex\ Media\ Scanner' -c 3 -s
you can wrapped it with double quote.
ssh myhost "$PATHTOPLEXSCANNER -c 3 -s"
When trying to run the command ssh user#ip 'command', I keep receiving this error: can't get tty settingscan't set orig mode. I have tried googling this and searching here but have not found anything referring to this message. I am trying to automate connecting to a Cisco wireless access point (2800 model) using Golang to run a command then exit, but this message pops up each time. I can log in normally using ssh user#ap_ip, but using the shorthand ssh user#ap_ip 'command' or trying the equivalent in Golang gives the error message above. Anyone know what's going on?
ssh without explicit command given will allocate a terminal while ssh with a command given will by default not. It looks like the command you execute needs a terminal. In this case use the -t option, i.e. ssh -t user#ip command. From the documentation:
-t Force pseudo-terminal allocation. This can be used to execute
arbitrary screen-based programs on a remote machine, which can be
very useful, e.g. when implementing menu services. Multiple -t
options force tty allocation, even if ssh has no local tty.
I am well aware of the -q option of ssh to perform the quiet mode as the man page says
-q Quiet mode. Causes most warning and diagnostic messages to be suppressed.
Somehow can I achieve something like this with ssh-copy-id? I want to ignore the input_userauth_banner
No. ssh-copy-id requires LogLevel=INFO to get some information from the ssh process. But that does not need to be passed to the user. You should be able to run ssh-copy-id silently using
ssh-copy-id -o LogLevel=QUIET server
I welcome rephrasing of my question, because I'm not sure exactly what the problem is called.
I am trying to run a shell script via SSH using a command of the following form:
ssh -o StrictHostKeyChecking=no lxplus0035 "cd ~/test; bash script1.sh"
When I do this, the complex script script1.sh breaks with many syntax errors, operand errors and other errors. An example is as follows:
stty: standard input: Invalid argument
The script works fine when run directly, not via SSH, in the local system and in the remote system (when connected in an SSH session). Why might executing the script via SSH cause these problems?
The stty problem is not related to your environment, it's a result of the SSH command not allocating you a TTY (What is Pseudo TTY-Allocation? (SSH and Github)). Adding -t argument for ssh should fix it.
Further information:
http://go2linux.garron.me/linux/2010/11/ssh-t-open-pseudo-tty-run-commands-remote-server-809/
http://capistranorb.com/documentation/faq/why-does-something-work-in-my-ssh-session-but-not-in-capistrano/
I'm using Vagrant 1.6.3 with phusion/baseimage as the docker provider to get going with Docker. But I have been running into this error:
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
ssh -i
/tmp/key_e8ffa02d35af2bec7aab60fe7e9df4db_0c30703c7b7126cdf4832a41b85627e5
-o Compression=yes -o ConnectTimeout=5 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -p22 root#172.17.0.2 'sudo -E -H bash -l'
Stdout from the command:
boot2docker: 0.8.0
VAGRANT FENCE: 1402443935 41755
Reading package lists...
Building dependency tree...
Reading state information...
Stderr from the command:
Warning: Permanently added '172.17.0.2' (ECDSA) to the list of known hosts.
stdin: is not a tty
VAGRANT FENCE: 1402443935 88439
modprobe: ERROR: ../libkmod/libkmod.c:556 kmod_search_moddep() could not open moddep file '/lib/modules/3.13.3-tinycore64/modules.dep.bin'
E: Unable to locate package linux-image-extra-3.13.3-tinycore64
E: Couldn't find any package by regex 'linux-image-extra-3.13.3-tinycore64'
Can anyone help me out? Thanks.
It seems like the problem is, that you're doing ssh to this server for the first time and ssh asks you to confirm the server's key. But since this is run from a script, the user doesn't answer it and ssh return an error code.
Option 1. I haven't used vagrant, so I'm not sure if you can ssh to this host interactively to add the key.
Option 2. Add the key manually. Usually the known_hosts file is hashed so it's not very easy to work with it can be a bit hard. You'll have to use ssh-keyscan and ssh-keygen to find the right keys. Here is a small tutorial, you can google for more.
Option 3. Use something like
yes "yes" | ssh ...
to automatically accept the offered key
Option 4. Do not require the key, like this
ssh -oStrictHostKeyChecking=no ...
P.S. I haven't tested these, so some may not work, sorry.
P.P.S. Options 3 and 4 have security problems. Options 1 and 2 are better, but still may pose security issues if you don't verify the keys.