I've built GlassFish 4.1 docker container via Dockerfile, details here
http://bderzhavets.blogspot.com/2015/01/dockerfile-for-glassfish-41.html
Glassfish itself work fine , however
*** Running /etc/my_init.d/00_regen_ssh_host_keys.sh...
No SSH host key available. Generating one...
Creating SSH2 RSA key; this may take some time ...
Creating SSH2 DSA key; this may take some time ...
Creating SSH2 ECDSA key; this may take some time ...
Creating SSH2 ED25519 key; this may take some time ...
invoke-rc.d: policy-rc.d denied execution of restart.
Attempt to ssh
ssh -v root#localhost -p 49160
OpenSSH_6.4, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Local version string SSH-2.0-OpenSSH_6.4
. . . . . . . .
ssh_exchange_identification: Connection closed by remote host
I don't know how to fix problem , showing up in log and affecting ssh connectivity.
Docker philosophy is to have one service per container. Some base images make it difficult to start services, which you have probably experienced. I would recommend to reconsider you approach and ask yourself why do you need the ssh daemon? Maybe you just want to use docker exec ? Or maybe you would be better off by building a VM box with vagrant, stuffed with several services for you needs?
Due to image phusion/baseimage doesn't provide ready to go sshd daemon per https://github.com/phusion/baseimage-docker I tried workaround mentioned here https://github.com/phusion/baseimage-docker#login_ssh and got:-
[root#junolxc ~]# docker run -d -p 49160:22 -p 49161:4848 -p 49162:8080 -p 49163:8181 boris/docker-glassfish41 --enable-insecure-key
693176ea6596bf33b880dc0f58250f47fe2e35ed95f44fcd80a62eeaa3fe17a4
2015/01/08 12:26:32 Error response from daemon: Cannot start container 693176ea6596bf33b880dc0f58250f47fe2e35ed95f44fcd80a62eeaa3fe17a4: exec: "--enable-insecure-key": executable file not found in $PATH
I just hacked system via adding to Dockerfile :-
RUN echo "/usr/sbin/sshd > log &" >> /etc/my_init.d/00_regen_ssh_host_keys.sh
Another option not to touch 00_regen_ssh_host_keys.sh.
Create in building folder script 01_sshd_start.sh
#!/bin/bash
/usr/sbin/sshd > log &
and insert in Dockerfile:-
ADD 01_sshd_start.sh /etc/my_init.d/
I believe would port 22 be already busy by system service "sshd" running the last hack wouldn't help me much. However, it did. I state that that system by some reasons doesn't start SSHD provided as is.
Related
I've wanted to connect my share hosting with ssh. So I generate an ssh key in the ssh action of cpanel and authorized it. Then I've downloaded the private key and drop it in the ./ssh folder of my MacBook.I've used this code to connect my host.
ssh -p 2083 username#host IP
but I got this error:
kex_exchange_identification: Connection closed by remote host
How can I solve my problem?
I run into a similar case with a small computer I have in my desk. What I did to debug the issue was to run sshd -t, which runs the sshd daemon in debug mode. This command reported that the permissions of my keys were invalid. All I had to do then was to go in the folder where the keys are stored and issue chmod 0600 <your_ssh_keys>.
Maybe the action you run generated things with the wrong permissions too.
I got this error when using docker command with remote host
docker -H ssh://user#server compose up
after some digging i found on my remote server in auth logs (/var/log/auth.log) this:
Aug 8 14:51:46 user sshd[1341]: error: beginning MaxStartups throttling
Aug 8 14:51:46 user sshd[1341]: drop connection #10 from [some_ip]:32992 on [some_ip]:22 past MaxStartups
This lead me to change MaxStartups settings in /etc/ssh/sshd_config. After restarting ssh service everything worked like a charm.
I had same problem and it was happend as I use ProxyCommand in ssh config file. In my case the Host was not defined correctly which then caused the same error!
I'm trying to create a node on a remote host(I've already created a domain).
I'm running the command:
asadmin -p <port_number> create-node-ssh --nodehost <remote_hostname> --installdir <glassfish_installed_dir_path> <node_name>
and getting the following error everytime:
remote failure: Warning: some parameters appear to be invalid.
SSH node not created. To force creation of the node with these parameters rerun the command using the --force option.
Could not connect to host <hostname> using SSH.
There was a problem while connecting to <hostname>:22
Key exchange was not finished, connection is closed.
Command create-node-ssh failed.
From the error it seems that there is some connection problem. But I can ssh to the target server and I'm using the same key_pair.
After searching for some solution (link1, link2) I found that trying to login through ssh without password could solve this.
But no luck. Now I can ssh to & from the target server without password as well. But this issue is still there.
What should I check for, in order to resolve this ?
Let me know if I'm missing out anything.
Can you try to start sshd daemon in debug mode to a different port at the remote node host:
sudo sshd -D -d -e -p 23
and try create-node-ssh command against that ssh port?:
asadmin -p <port_number> create-node-ssh --nodehost <remote_hostname> --installdir <glassfish_installed_dir_path> --sshport 23 <node_name>
I had an issue regarding glassfish ssh exchange keys because of ssh newer versions deprecating older algorithms:
Unable to negotiate with X.X.X.X port XXXXX: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth]
My solution was to add legacy keys to /etc/ssh/sshd_config:
KexAlgorithms +diffie-hellman-group1-sha1
Ciphers +aes128-cbc
Even if this is not your case, sshd debug will surelly give you more information.
After following instructions both online and in a couple of books, I am unsure of why this is happening. I have a feeling there is a missing setting, but here is the setup:
I am attempting to use the command:
ansible all -u $USER -m ping -vvvv
Obviously using the -vvvv for debugging, but not much output aside from the fact it says it's attempting to connect. I get the following error:
S4 | FAILED => FAILED: Authentication failed.
S4 stands for switch 4, a Cisco switch I am attempting to automate configuration and show commands on. I know 100% the password I set in the host_vars file is correct, as it works when I use it from a standard SSH client.
Here are my non-default config settings in the ansible.cfg file:
[defaults]
transport=paramiko
hostfile = ./myhosts
host_key_checking=False
timeout = 5
My myhosts file:
[cisco-switches]
S4
And my host_vars file for S4:
ansible_ssh_host: 192.168.1.12
ansible_ssh_pass: password
My current version is 1.9.1, running on a Centos VM. I do have an ACL applied on the management interface of the switch, but it allows remote connections from this particular IP.
Please advise.
Since you are using ansible to automate commands in a Cisco switch, I guess you want to perform the SSH connection to the switch without been prompted for password or been requested to press [Y/N] to confirm the connection.
To do that I recommend to configure the Cisco IOS SSH Server on the switch to perform RSA-Based user authentication.
First of all you need to generate RSA key pair on your Linux box:
ssh-keygen -t rsa -b 1024
Note: You can use 2048 instead 1024 but consider that some IOS versions will accept maximum 254 characters for ssh public key.
At switch side:
conf t
ip ssh pubkey-chain
username test
key-string
Copy the entire public key as appears in the cat id_rsa.pub
including the ssh-rsa and username#hostname.
Please note that some IOS versions will accept
maximum 254 characters.
You can paste multiple lines.
exit
exit
If you need that 'test' user can execute privileged IOS commands:
username test privilege 15 secret _TEXT_CLEAR_PASSWORD_
Then, test your connection from your Linux box in order to add the switch to known_hosts file. This will only happen one time for each switch/host not found in the known_hosts file:
ssh test#10.0.0.1
The authenticity of host '10.0.0.1 (10.0.0.1)' can't be established.
RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:d6:4b:d1:67.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.0.1' (RSA) to the list of known hosts.
ciscoswitch#
ciscoswitch#exit
Finally test the connection using ansible over SSH and raw module, for example:
ansible inventory -m raw -a "show env all" -u test
I hope you find it useful.
I am using Docker on Mac OS X with Docker Machine (with the default boot2docker machine), and I use docker-compose to setup my development environment.
Let's say that one of the containers is called "stack". Now what I want to do is call:
docker-composer run stack ssh user#stackoverflow.com
My public key (which has been added to stackoverflow.com and which will be used to authenticate me) is located on the host machine. I want this key to be available to the Docker Machine container so that I will be able to authenticate myself against stackoverflow using that key from within the container. Preferably without physically copying my key to Docker Machine.
Is there any way to do this? Also, if my key is password protected, is there any way to unlock it once so after every injection I will not have to manually enter the password?
You can add this to your docker-compose.yml (assuming your user inside container is root):
volumes:
- ~/.ssh:/root/.ssh
Also you can check for more advanced solution with ssh agent (I did not tried it myself)
WARNING: This feature seems to have limited support in Docker Compose and is more designed for Docker Swarm.
(I haven't checked to make sure, but) My current impression is that:
In Docker Compose secrets are just bind mount volumes, so there's no additional security compared to volumes
Ability to change secrets permissions with Linux host may be limited
See answer comments for more details.
Docker has a feature called secrets, which can be helpful here. To use it one could add the following code to docker-compose.yml:
---
version: '3.1' # Note the minimum file version for this feature to work
services:
stack:
...
secrets:
- host_ssh_key
secrets:
host_ssh_key:
file: ~/.ssh/id_rsa
Then the new secret file can be accessed in Dockerfile like this:
RUN mkdir ~/.ssh && ln -s /run/secrets/host_ssh_key ~/.ssh/id_rsa
Secret files won't be copied into container:
When you grant a newly-created or running service access to a secret, the decrypted secret is mounted into the container in an in-memory filesystem
For more details please refer to:
https://docs.docker.com/engine/swarm/secrets/
https://docs.docker.com/compose/compose-file/compose-file-v3/#secrets
If you're using OS X and encrypted keys this is going to be PITA. Here are the steps I went through figuring this out.
Straightforward approach
One might think that there’s no problem. Just mount your ssh folder:
...
volumes:
- ~/.ssh:/root/.ssh:ro
...
This should be working, right?
User problem
Next thing we’ll notice is that we’re using the wrong user id. Fine, we’ll write a script to copy and change the owner of ssh keys. We’ll also set ssh user in config so that ssh server knows who’s connecting.
...
volumes:
- ~/.ssh:/root/.ssh-keys:ro
command: sh -c ‘./.ssh-keys.sh && ...’
environment:
SSH_USER: $USER
...
# ssh-keys.sh
mkdir -p ~/.ssh
cp -r /root/.ssh-keys/* ~/.ssh/
chown -R $(id -u):$(id -g) ~/.ssh
cat <<EOF >> ~/.ssh/config
User $SSH_USER
EOF
SSH key passphrase problem
In our company we protect SSH keys using a passphrase. That wouldn’t work in docker since it’s impractical to enter a passphrase each time we start a container.
We could remove a passphrase (see example below), but there’s a security concern.
openssl rsa -in id_rsa -out id_rsa2
# enter passphrase
# replace passphrase-encrypted key with plaintext key:
mv id_rsa2 id_rsa
SSH agent solution
You may have noticed that locally you don’t need to enter a passphrase each time you need ssh access. Why is that?
That’s what SSH agent is for. SSH agent is basically a server which listens to a special file, unix socket, called “ssh auth sock”. You can see its location on your system:
echo $SSH_AUTH_SOCK
# /run/user/1000/keyring-AvTfL3/ssh
SSH client communicates with SSH agent through this file so that you’d enter passphrase only once. Once it’s unencrypted, SSH agent will store it in memory and send to SSH client on request.
Can we use that in Docker? Sure, just mount that special file and specify a corresponding environment variable:
environment:
SSH_AUTH_SOCK: $SSH_AUTH_SOCK
...
volumes:
- $SSH_AUTH_SOCK:$SSH_AUTH_SOCK
We don’t even need to copy keys in this case.
To confirm that keys are available we can use ssh-add utility:
if [ -z "$SSH_AUTH_SOCK" ]; then
echo "No ssh agent detected"
else
echo $SSH_AUTH_SOCK
ssh-add -l
fi
The problem of unix socket mount support in Docker for Mac
Unfortunately for OS X users, Docker for Mac has a number of shortcomings, one of which is its inability to share Unix sockets between Mac and Linux. There’s an open issue in D4M Github. As of February 2019 it’s still open.
So, is that a dead end? No, there is a hacky workaround.
SSH agent forwarding solution
Luckily, this issue isn’t new. Long before Docker there was a way to use local ssh keys within a remote ssh session. This is called ssh agent forwarding. The idea is simple: you connect to a remote server through ssh and you can use all the same remote servers there, thus sharing your keys.
With Docker for Mac we can use a smart trick: share ssh agent to the docker virtual machine using TCP ssh connection, and mount that file from virtual machine to another container where we need that SSH connection. Here’s a picture to demonstrate the solution:
First, we create an ssh session to the ssh server inside a container inside a linux VM through a TCP port. We use a real ssh auth sock here.
Next, ssh server forwards our ssh keys to ssh agent on that container. SSH agent has a Unix socket which uses a location mounted to Linux VM. I.e. Unix socket works in Linux. Non-working Unix socket file in Mac has no effect.
After that we create our useful container with an SSH client. We share the Unix socket file which our local SSH session uses.
There’s a bunch of scripts that simplifies that process:
https://github.com/avsm/docker-ssh-agent-forward
Conclusion
Getting SSH to work in Docker could’ve been easier. But it can be done. And it’ll likely to be improved in the future. At least Docker developers are aware of this issue. And even solved it for Dockerfiles with build time secrets. And there's a suggestion how to support Unix domain sockets.
You can forward SSH agent:
something:
container_name: something
volumes:
- $SSH_AUTH_SOCK:/ssh-agent # Forward local machine SSH key to docker
environment:
SSH_AUTH_SOCK: /ssh-agent
You can use multi stage build to build containers This is the approach you can take :-
Stage 1 building an image with ssh
FROM ubuntu as sshImage
LABEL stage=sshImage
ARG SSH_PRIVATE_KEY
WORKDIR /root/temp
RUN apt-get update && \
apt-get install -y git npm
RUN mkdir /root/.ssh/ &&\
echo "${SSH_PRIVATE_KEY}" > /root/.ssh/id_rsa &&\
chmod 600 /root/.ssh/id_rsa &&\
touch /root/.ssh/known_hosts &&\
ssh-keyscan github.com >> /root/.ssh/known_hosts
COPY package*.json ./
RUN npm install
RUN cp -R node_modules prod_node_modules
Stage 2: build your container
FROM node:10-alpine
RUN mkdir -p /usr/app
WORKDIR /usr/app
COPY ./ ./
COPY --from=sshImage /root/temp/prod_node_modules ./node_modules
EXPOSE 3006
CMD ["npm", "run", "dev"]
add env attribute in your compose file:
environment:
- SSH_PRIVATE_KEY=${SSH_PRIVATE_KEY}
then pass args from build script like this:
docker-compose build --build-arg SSH_PRIVATE_KEY="$(cat ~/.ssh/id_rsa)"
And remove the intermediate container it for security. This Will help you cheers.
Docker for Mac now supports mounting the ssh agent socket on macOS.
I'm having issues using ssh to log in to a VM created from a custom image.
I followed the steps for creating an image from an existing GCE instance.
I have successfully created the image, uploaded it to Google Cloud Storage and added it as an image to my project, yet when I try to connect to the new image, I get a "Connection Refused".
I can see other applications running on other ports for the new image, so it seems to be just ssh that is affected.
The steps I did are below:
...create an image from existing GCE instance (one I can log into fine via ssh)..then:
gcutil --project="river-ex-217" addimage example2 http://storage.googleapis.com/example-image/f41aca6887c339afb0.image.tar.gz
gcutil --project="river-ex-217" addinstance --image=example2 --machinetype=n1-standard-1 anothervm
gcutil --service_version="v1" --project="river-ex-217" ssh --zone="europe-west1-a" "anothervm"
Which outputs:
INFO: Running command line: ssh -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o StrictHostKeyChecking=no -i /Users/mark1/.ssh/google_compute_engine -A -p 22 mark1#23.251.133.2 --
ssh: connect to host 23.251.133.2 port 22: Connection refused
I've tried deleting the sshKeys metadata as suggested in another SO answer, and reconnecting which did this:
INFO: Updated project with new ssh key. It can take several minutes for the instance to pick up the key.
INFO: Waiting 120 seconds before attempting to connect.
INFO: Running command line: ssh -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o StrictHostKeyChecking=no -i /Users/mark1/.ssh/google_compute_engine -A -p 22 mark1#23.251.133.2 --
ssh: connect to host 23.251.133.2 port 22: Connection refused
I then try for the first instance in another zone, it works fine with the new key:
gcutil --service_version="v1" --project="river-ex-217" ssh --zone="europe-west1-b" "image1"
Both instances are running on the same "default" network with port 22 running, and ssh works for the first instance the image is created from.
I tried nc command from the other instance and my local machine, it shows no output:
nc 23.251.133.2 22
...whilst the original VM's ip shows this output:
nc 192.157.29.255 22
SSH-2.0-OpenSSH_6.0p1 Debian-4
I've tried remaking the image again and re-adding the instance, no difference.
I've tried logging in to the first instance, and switching user to one on that machine (which should be the same as the second machine?), and ssh from there.
WARNING: You don't have an ssh key for Google Compute Engine. Creating one now...
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
INFO: Updated project with new ssh key. It can take several minutes for the instance to pick up the key.
INFO: Waiting 300 seconds before attempting to connect.
INFO: Running command line: ssh -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o StrictHostKeyChecking=no -i /home/mark/.ssh/google_compute_engine -A -p 22 mark#23.251.133.2 -- --zone=europe-west1-a
ssh: connect to host 23.251.133.2 port 22: Connection refused
I'm out of ideas, any help greatly appreciated :) The maddening thiing is I can see the new VM is live with the application ready, I just need to add a few files to it and set up some cronjobs. I guess I could do this pre-image making, but I would like to be able to log in at a later date and modify it, without needing to take 1hr to create images and launch new instances every time.
Yours faithfully,
Mark
This question appears to be about how to debug SSH connectivity problems with images, so here is my answer to that.
It appears that your instance may not be running the SSH server properly. There may be something amiss with the prepared image.
Possibly useful debugging questions to ask yourself:
Did you use gcimagebundle to bundle up the image or did it manually? Consider using the tool to make sure there isn't something you missed.
Did you change anything about the ssh server configuration before bundling the image?
When the instance is booting, check it's console output for ssh messages - it should mention regenerating the keys, starting sshd daemon and listening on port 22. If it does not or complains about something related to ssh, you should follow up on that.
You covered these, but for sake of completeness, these should also be checked:
Can you otherwise reach the VM after it comes up? Does it respond on webserver ports (if any) or respond to ping?
Double check that the network you VM is on allows SSH (port 22) access from the host you are connecting from.
You can compare your ssh setup to that of a working image:
Create a new disk (disk-mine-1) from your image.
Create a new disk (disk-upstream-1) from any working boot image, for example the debian wheezy one.
Attach both of these to a VM you can access (either on console or from cli).
SSH into the VM.
Mount both of the images (sudo mkdir /mnt/{mine,upstream} && sudo mount /dev/sdb1 /mnt/mine && sudo mount /dev/sdc1 /mnt/upstream). Note that whether your image is sdb or sdc depends on the order you attached the images!
Look for differences between the ssh config (diff -waur /mnt/{mine,upstream}/etc/ssh). There should not be any unless you specifically need them.
Also check if your image has proper /mnt/mine/etc/init.d/{ssh,generate-ssh-hostkeys} scripts. They should also be linked from /mnt/mine/etc/rc{S,2}.d (S10generate-ssh-hostkeys and S02ssh respectively).