search

welaika / docker-wordmove

Docker image to run Wordmove
https://hub.docker.com/r/welaika/wordmove/
16 stars 9 forks source link

Bad owner or permissions on /root/.ssh/config #16

Closed Awea closed 4 years ago

Awea commented 4 years ago

Hi there,

When using this image to use Wordmove I ended having permission error on my SSH key within the container. I use the following command to run Wordmove: docker run --rm -v $HOME/.ssh:/root/.ssh:ro -v $PWD/:/html welaika/wordmove wordmove push -w -e production

In an attemp to fix that, I ended doing something like this:

Dockerfile

FROM welaika/wordmove

COPY entrypoint.sh /bin/entrypoint.sh
RUN chmod +x /bin/entrypoint.sh
ENTRYPOINT ["/bin/entrypoint.sh"]

entrypoint.sh

#!/bin/sh
set -e

# Using `-v $HOME/.ssh:/root/.ssh:ro` produce permissions error while in the container
# to prevent that we ensure that the `-v $HOME/.ssh:/tmp/.ssh:ro` as the correct
# permissions when starting the container - @awea 20200319
# Source: https://nickjanetakis.com/blog/docker-tip-56-volume-mounting-ssh-keys-into-a-docker-container
cp -R /tmp/.ssh /root/.ssh
chmod 700 /root/.ssh
chmod 644 /root/.ssh/id_rsa.pub
chmod 600 /root/.ssh/id_rsa

exec "$@"

I think this may be a problem other will encounter. Should I create a pull-request with something like this?

alessandro-fazzi commented 4 years ago

Hi,

I've just tested it, but I cannot reproduce the problem. File permissions for the mounted volume are the same as on my host machine and ownership is correctly set to root:root.

This is true both on latest and alpine tags.

Are you sure to have correct permissions on your host?

FWIW I have

700 ~/.ssh
600 ~/.ssh/id_rsa.pub
600 ~/.ssh/id_rsa

What's the exact error you are receiving?

Awea commented 4 years ago

Hi @pioneerskies, thanks for answering!

Yes, I have the correct permissions on my host, my public and private key are both 600. Same permissions inside my container.

The exact error I'm receiving is the following:

▬▬ Using Movefile: ./movefile.yml ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

▬▬ Pulling Uploads ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

   remote | get_directory: [secret] [secret] /wp-content/* readme.html license.txt wp-config.php wp-content/*.sql.gz .htaccess /* /wp-content/uploads/ /wp-content/

    ℹ️  info | rsync --progress -e 'ssh test@[secret]' -rlpt --compress --omit-dir-times --delete --include /wp-content/uploads/ --include /wp-content/ --exclude /wp-content/\* --exclude readme.html --exclude license.txt --exclude wp-config.php --exclude wp-content/\*.sql.gz --exclude .htaccess --exclude /\* :[secret]/ [secret]
Bad owner or permissions on /root/.ssh/config
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: unexplained error (code 255) at io.c(235) [Receiver=3.1.3]
Awea commented 4 years ago

Ahahahah. By just copy/pasting the error I notice that the problem is on my .ssh/config file... :D But my .ssh/config is in permission 600 so it should be ok, right?

alessandro-fazzi commented 4 years ago

Hi @pioneerskies, thanks for answering!

Hey your're welcome.

But my .ssh/config is in permission 600 so it should be ok, right?

AFAIK 644 is the correct one for .ssh/config.

Obviously you are trying with the plain image and no entrypoint, aren't you?

Awea commented 4 years ago

AFAIK 644 is the correct one for .ssh/config.

I try to chmod to 644, same result.

Obviously you are trying with the plain image and no entrypoint, aren't you?

Obviously I am :)

alessandro-fazzi commented 4 years ago

Actually from my man ssh_config

FILES
     ~/.ssh/config
             This is the per-user configuration file.  The format of this file
             is described above.  This file is used by the SSH client.
             Because of the potential for abuse, this file must have strict
             permissions: read/write for the user, and not accessible by oth-
             ers.

BTW you have still to check ownership. Would you mind to take a look at this command

docker run --rm -v $HOME/.ssh:/root/.ssh:ro welaika/wordmove ls -la /root/.ssh

My output (cleaned from sensitive files) is

drwx------ 12 root root   384 Mar 16 18:41 .
drwx------  1 root root  4096 Mar 20 08:47 ..
-rw-------  1 root root  4475 Mar 16 18:41 config
-rw-------  1 root root  1700 Jul 23  2014 id_rsa
-rw-------  1 root root   410 Mar  8  2017 id_rsa.pub
-rw-r--r--  1 root root 60732 Mar 16 19:14 known_hosts

And I can flelessly do something like

docker run --rm -it -v $HOME/.ssh:/root/.ssh:ro welaika/wordmove ssh code

(where code is a host configured in my .ssh/config) and access to remote host using my key.

Keep in mind that ownership/permissions on your .ssh/* files may differ depending on the OS you are working on (MacOS here)

Awea commented 4 years ago

BTW you have still to check ownership. Would you mind to take a look at this command docker run --rm -v $HOME/.ssh:/root/.ssh:ro welaika/wordmove ls -la /root/.ssh

Sure thing: 

drwxr--r-- 2 1000 1000  4096 .
drwx------ 1 root root  4096 ..
-rw------- 1 1000 1000   304 config
-rw------- 1 1000 1000  1679 id_rsa
-rw------- 1 1000 1000   406 id_rsa.pub
-rw-r--r-- 1 1000 1000 10439 known_hosts

The group/ownership inside the container are not root/root, that probably the root of my issue. But I don't get it why this is happening. Anyways this problem as nothing to do with your image but probably with my environment, thanks for your time :3

I'm working on Ubuntu here (permissions are the same on my coworker which is on MacOs).

alessandro-fazzi commented 4 years ago

I have not enough knowledge on the matter to help you consistently. I perceive that it's a more general problem than an image-relate one.

The only thing a can say is: if the image itself could acquire a general behaviour to help facing or consistently workaround such a situation, then I'd be open for discussion and for testing on my environment.

Awea commented 4 years ago

As I understand Docker on MacOS doesn't work the same way as it does on Linux:

So when Docker mount the filesystem in a container on MacOS, I suppose it mount in a VM then mount in a container then by doing that it (probably) changes ownership. On Linux it seems to preserver ownership as it is.

The only thing a can say is: if the image itself could acquire a general behaviour to help facing or consistently workaround such a situation, then I'd be open for discussion and for testing on my environment.

Actually the modification written in the description of this issue works on both MacOS and Linux, so it can be a starting point ^^

alessandro-fazzi commented 4 years ago

I'm thinking about it and exploring solutions. Sparse thoughts:

I'll try to think more about it. The goal from my perspective is obviously to improve leaving the image completely open to customization.

alessandro-fazzi commented 4 years ago

Hello @Awea ,

I've adapted your work to be more adherent to my vision of a generalist and agnostic image.

I'd like to invite you to read my PR (linked above). If you mind you can pull this repo, checkout the alpine_mount_ssh branch, follow the instruction in the README - just to check that it is clear - and try to build your own image locally, e.g.:

docker build --rm -t welaika/wordmove:alpine_test "."

Let me know if you don't mind to or if you don't have the time to. It's absolutely ok, but I'll organize myself differently 😄

Thanks in advance.

alessandro-fazzi commented 4 years ago

Obviously if the PR will work as expected, it will be ported to the :php7 tag.

Awea commented 4 years ago

Yo @pioneerskies,

Thanks for your work :ok_hand:

I've juste tested your alpine_mount_ssh branch within the project I'm working on, everything works just fine and the instruction are clear enough :)

alessandro-fazzi commented 4 years ago

This is an awesome news.

I think I'll port it to the other tag, merge both and push them to DockerHub this afternoon :)

Thank you for helping out with testing: it's really precious.

Awea commented 4 years ago

Thank you for helping out with testing: it's really precious.

@pioneerskies It's the least I can do :)

alessandro-fazzi commented 4 years ago

Ok, builds are - slowly - running on DockerHub, so they'll be public ASAP.

I'm going to close the issue. Thanks again :)