signet/sshd repository overview

⁠Build the image

docker build -t signet/sshd:1.0.0-rc01 .

⁠Special Notes

• IT IS NOT ADVISABLE: to bind the host port of your container to port 22, for example: -p 22:8022. This can potentially, and most likely will, conflict with SSH access to the host running the container. Additionally, the container will not likely start since sshd, on most hosts, is already running on port 22. If sshd is already bound to port 22, then it will not allow the container to bind to port 22; neither do you want it to unless you have made provisions to run sshd on a different port than the default 22.

• Since sshd is a generic service as opposed to an application, there is no application version tag associated with this container as is our standard.

  Typical application tag: signet/app:<APPVERS>_<RELVERSION>-rc01 Service/Utility tag: signet/svc:<RELVERSION>-rc01

⁠Run the container

docker run \
-e PUBLIC_KEY="ssh-rsa AABAB...xYZ [email protected]" \
-v /mnt/somenfsmount/someapphome:/target/someapphome \
-p 8022:8022 \
-d signet/sshd:1.0.0-rc01

⁠Background

The purpose of this container is to be able to serve as a medium for mass transport of files between disconnected container networks. Specifically the use case this container serves to solve; is to be able to rsync data from PROD back to the corresponding offline environments. Being able to accomplish this allows us to easily refresh our DEV/Lab instances with PROD data. Given that this is a container ecosystem, it only makes sense to utilize containers to perform the task.

The benefits of using containers to do this is that we can design lightweight bundles of functionality that spin up to perform a specific task and then spin down when complete. This optimizes compute utilization and provides a standardized workflow of automation that can easily be adjusted and re-used to acommodate ever-changing needs.

The role that this container serves is to allow another container SSH access while mounting the target file systems in read-write for syncronization.

⁠Environment Variables

⁠PUBLIC_KEY

This variable requires a double quoted string containing the contents of the typical id_rsa.pub file in a RSA key pair. This can usually be obtained by "cat'ing" the file.

cat ~/.ssh/id_rsa.pub

ssh-rsa AABBA...
...
...XyZ [email protected]

For example, pass it to the container like so:

-e PUBLIC_KEY="ssh-rsa AABAB...xYZ [email protected]"

⁠Key pairs and unprivileged accounts

In this instance you should not typically use your local key pair although you could if you wanted or needed to. In our case, we are providing a shared key pair that we use for automation tasks. This container takes that public key and places it in an unprivileged account's authorized_keys file.

The account is named "onek" because the uid is 1000 and the gid is also 1000. The first account and/or group created on a RHEL instance is 1000. When we create a user account inside a container image, it is always the first one unless in the container image we have created one previously. With all of our application containers, we try to use unprivileged accounts to run the applications. Well, when we do so, they are also created with the uid of 1000 and gid 1000. Which means that when we spin up this container, the "onek" user should have the same permissions that the application does on the NFS volumes. This is ideal given that we want to write the files into the application home directories.