How to access root folder inside a Docker container

Question

I am new to docker, and am attempting to build an image that involves performing an npm install. Some of our the dependencies are coming from private repos we have, and I am hitting an SSH related issue:

I realised I was not supplying any form of SSH details to my file, and came across various posts online about how to do this using args into the docker build command.

So taken from here, I have added the following to my dockerfile before the npm install command gets run:

ARG ssh_prv_key
ARG ssh_pub_key

RUN apt-get update && \
    apt-get install -y \
        git \
        openssh-server \
        libmysqlclient-dev

# Authorize SSH Host
RUN mkdir -p /root/.ssh && \
    chmod 0700 /root/.ssh && \
    ssh-keyscan github.com > /root/.ssh/known_hosts

# Add the keys and set permissions
RUN echo "$ssh_prv_key" > /root/.ssh/id_rsa && \
    echo "$ssh_pub_key" > /root/.ssh/id_rsa.pub && \
    chmod 600 /root/.ssh/id_rsa && \
    chmod 600 /root/.ssh/id_rsa.pub

So running the docker build command again with the correct args supplied, I do see further activity in the console that suggests my SSH key is being utilised:

But as you can see I am getting no hostkey alg messages and I still getting the same 'Host key verification failed' error. I was wondering if I could view the log file it references in the error:

Do I need to get the image running in order to be able to connect to it and browse the 'root' folder?

I hope I have made sense, please be gentle I am a docker noob!

Thanks

Answer 1

The lines that start with —-> in the docker build output are valid Docker image IDs. You can pick any of these and docker run them:

docker run --rm -it 59c45dac474a sh

If a step is actually failing, one useful debugging trick is to launch the image built in the step before it and run the command by hand.

Remember that anyone who has your image can do this; the way you’ve built it, if you ever push your image to any repository, your ssh private key is there for the taking, and you should probably consider it compromised. That’s doubly true since it will also be there in plain text in docker history output.