Docker Community Forums

Share and learn in the Docker community.

Install SSH service in CentOS container[running container]

Hi all,

I have a running CentOS container. I installed OpenSSH server and client there. When I try to start the SSH service via

systemctl start sshd - command,

I got this error “System has not been booted with systemd as init system (PID 1). Can’t operate.
Failed to connect to bus: Host is down”.

When I try to start the SSH service via

service sshd start - command,

I got this error “Redirecting to /bin/systemctl start sshd.service
System has not been booted with systemd as init system (PID 1). Can’t operate.
Failed to connect to bus: Host is down
”.

So, can we install SSH server in running container?

Thanks in advance.

Regards,
Khopi

It depends on the image.

In case of Ubuntu 20.04 it works using service sshd start to start the daemon.
In case of centos, the service command is redirected to systemctl so you can’t start it that way. The service command is just a command to help you start the daemon, but you can start it directly. To start it in the foreground, you can do this:

ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ''
ssh-keygen -t rsa -f /etc/ssh/ssh_host_dsa_key -N ''
ssh-keygen -t rsa -f /etc/ssh/ssh_host_ed25519_key -N ''
/usr/bin/sshd

If you don’t want to start it in the foreground, you can use supervisor as a process manager which does not require to run as PID 1.

If you don’t want to use such “big” software to just test something, you can run the SSHD like this:

nohup /usr/sbin/sshd &
# press enter

Hi @rimelek,

Thank you for your reply. Yeah this container doesn’t have systemd daemon. So, I found “centos/systemd” docker image. Here I can use systemctl command without any issue.

Then I could login with
docker exec -it <container_id> bash

So, the PID 1 will be use - /usr/lib/systemd/systemd

Regards,
Khopi

I thought you needed it in an existing container. If you can create an other, I would not use systemd just for running SSH daemon. The best solution depends on your exact case but usually the best one is not systemd. If it works for you, you can use it. I just wanted to note this for future readers.

Hi,

Thank you, but why systemd is not a best option? Can you explain more? It will be helpful.

Because systemd is not for containers. Recently it got more support for containers because people wanted to test their installation process in a container before doing it on the host or they had a special case where they could not rewrite their software in time which was depending on systemd.

Systemd is a process manager which is closely dependent on the Linux kernel and the configuration could be different in each environment.
The image you found works really well except on MacOS with the ARM cpu (I don’t know if it works with amd64).

Even if it works perfectly, you won’t see the log messages on the containers’ standard output. This is similar to how supervisor works because they are for running multiple services in one container which we usually try to avoid, but supervisor does not depend on the kernel.

According to the description on Docker Hub, the container created from centos/systemd image requires privileged mode. It is not completely true, although almost every tutorial say it is. See my tutorial:

You could think you could use the --privileged parameter to have more permissions but it is not so easy despite the fact that many tutorial say it is. It could restart your GUI in case you are working on a desktop machine.

It took months for me to realize why I could not run systemd containers on my Desktop machine to test my Ansible playbooks. Then I removed the privileged flag and added

  --tmpfs /run \
  --tmpfs /run/lock \
  --e container docker

The “container” variable is set in the Dockerfile in your case. Fedora container also required --tmpfs /tmp.

These were just some potential issues I have met. Always try to avoid using the privileged mode. In case of SSH you would run a “Secure SHell” in a privileged (insecure) container. I would not usually run SSH in a container either. You could have your reason so this is why I did not start with this statement.

Wow, thank you for the great explanation :+1: