In the dockerfile, the ssh keys are generated in the CMD statement of the dockerfile.
At the moment you are using the CMD command to initialize the running container:
# This is ugly, but its the only thing I found which works. This generates a new ED25519 & RSA host key each time the container is run.
CMD /usr/bin/ssh-keygen -t rsa -b 4096 -f /home/ssh-mitm/etc/ssh_host_rsa_key -N ''; /usr/bin/ssh-keygen -t ed25519 -f /home/ssh-mitm/etc/ssh_host_ed25519_key -N ''; echo; /home/ssh-mitm/bin/sshd_mitm -D -f /home/ssh-mitm/etc/sshd_config
Using CMD in a dockerfile to initialize the container after building the image is not recommended. For example, when starting the container with a different command, the container is not fully working.
By switching to ENTRYPOINT, you can define a different CMD, which will be executed from the entrypoint script.
Using an entrypoint script allows more control in the initialization step.
This pull request only creates new keys, when a new container is started. If an existing container is restarted, existing keys will not be overridden.
Using the same keys after a container restart avoids the problem with changing fingerprints. Clients which has already a stored fingerprint from ssh-mitm will not complain about a different fingerprint.
In the dockerfile, the ssh keys are generated in the CMD statement of the dockerfile.
At the moment you are using the CMD command to initialize the running container:
Using CMD in a dockerfile to initialize the container after building the image is not recommended. For example, when starting the container with a different command, the container is not fully working.
By switching to ENTRYPOINT, you can define a different CMD, which will be executed from the entrypoint script. Using an entrypoint script allows more control in the initialization step.
This pull request only creates new keys, when a new container is started. If an existing container is restarted, existing keys will not be overridden.
Using the same keys after a container restart avoids the problem with changing fingerprints. Clients which has already a stored fingerprint from ssh-mitm will not complain about a different fingerprint.
I have created a pull request for this issue: #37