StrictHostKeyChecking=no, is a no-no
ambis opened this issue · comments
While in the past I have struggled with StrictHostKeyChecking being on (needing to remember to ssh-login once to backup target manually via exec before backups work), I think it is a silly thing to turn off by DEFAULT.
My current solution is to prepare the host-mounted volumes with Ansible so that there is a ready-made known_hosts-file in place when I run backuppc.
Another issue (something which I more or less do understand) is the automatic generation of an ssh-key for the backuppc user. I use ED25519 ssh keys. A new installation will not work agaist fail2ban-enabled backup target because when backuppc offers both RSA and ED25519 keys, it will get banned because the (generated) RSA key fails and leaves a trace of failure in the logs for fail2ban.
Now I have to manually extend the image to a) turn StrictHostKeyChecking back on (boohoo), and make sure there are no id_rsa* in place.
I love your backuppc image and I thank you for it, but please, leave these type of options behind an ENV option to turn them on. Or at least give us an opt-out ENV.
After some reasearch, looks like StrictHostKeyChecking=no still writes the known_hosts entries and presumably fails if the host no longer matches if the host key changes on the host. Still not sure if I like it being off by default.
Well, as it turned out, the solution was quite simple. I'll put this in place with Ansible. I could also turn StrictHostKeyChecking back on. The main problem is still that these kind of options are changed without really telling about them. Thus #2! 😄
#/home/backuppc/.ssh/config
Host *
IdentitiesOnly yes
IdentityFile ~/.ssh/id_ed25519
Hello,
I am quite surprised by your remarks about strict host checking and backuppc client key generation because theses features are present since a while, the creation of the docker for the keys, and one year for the strict host.
Anyway, I am always willing to improve my Docker usefulness. As everyone, I started this Docker for my own usage, as this kind of Docker was missing. And of course as soon as I share it with community, more wider kinds of usages appear, and I want to follow them as most as I can.
For the changelog, I agree that the release post in GitHub is not sufficient, and a changelog file is a universal approach, a non-tied Github one. I will do that.
Next post we will discuss about the evolutions needed, and the errors you got because they seems to be regressions, and regressions bother me a lot, in particular for a long term system like a backup tool is.
So, let's start with StrictHostKeyChecking. I think it is really relevant to set it to 'off'. As a consequence, any ssh to an host which is not in the know_hosts will be automatically accepted without asking manual intervention by a user, an its public key will be added to the known_hosts.
But it does not mean that host checking is disabled! If it happens for any reason that a host already present in the known_hosts expose a different public key, ssh connection will be refused. This security of ssh protocol is fundamental, you cannot disable it without some really hacky configuration. You would need, after setting StrictHostKeyChecking to off, to force the ssh client to use /dev/null as the known host, and I think you cannot even do it for any user, but manually for each user.
So basically this configuration in my Docker consists in replacing a manual intervention (accepting a public key on first ssh), by another manual intervention (adding an host to the backuppc configuration). It is equally "not secured" to my mind.
After that, if you use effectively some orchestrations on your machines, I could consider to add an environment variable to enable strict host checking, but I think it should stay disabled by default, for the more common case where no orchestration is done on /home/backuppc.
@adferrand Yeah, sounds good to me.
I got all my issues resolved via the backuppc user's ssh config file (above). Now I'm only hoping for that changelog so one can prepare for any significant changes when any are released. And you already commented on that and that is great 👍
And once again, thank you for this wonderful Docker Image! Wouldn't want to do a single new host install of bpc now that running this is so easy... 😍