Resolve host key generation issue #11

Closed
opened 2020-06-26 08:41:20 +00:00 by decentral1se · 3 comments
Owner

Everytime the container goes up and down, the SSH host keys are regenerated and it gives a spooky error message. We need to make those persistent somehow. Needs to be investigated. We currently use the internal Gitea ssh server, so maybe it is just another configuration switch.

Everytime the container goes up and down, the SSH host keys are regenerated and it gives a spooky error message. We need to make those persistent somehow. Needs to be investigated. We currently use the internal Gitea ssh server, so maybe it is just another configuration switch.
Owner

We could store host keys in docker secret, maybe, which would solve the problem of securely persisting them across reboots -- you got any ideas how we easily mount a secret at a custom location (i.e. str8 into /etc/ssh/.., or edit the SSH config to get the host key from /run/secrets/..?

We could store host keys in `docker secret`, maybe, which would solve the problem of securely persisting them across reboots -- you got any ideas how we easily mount a secret at a custom location (i.e. str8 into `/etc/ssh/..`, or edit the SSH config to get the host key from `/run/secrets/..`?
Author
Owner

That sounds good but I think the problem needs investigating first. There are some keys stored on the volume but I think they are from before the migration from Dokku and not used anymore. I think somehow Gitea is generating them again and not even saving them to the file system because we make use of the internally implemented SSH server (yep, that is right, golang programmers re-wrote SSH and it actually works!). I think it all stems from my botched migration basically. Would be cool to pair and sort this out one day.

That sounds good but I think the problem needs investigating first. There are some keys stored on the volume but I think they are from before the migration from Dokku and not used anymore. I think somehow Gitea is generating them again and not even saving them to the file system because we make use of the internally implemented SSH server (yep, that is right, golang programmers re-wrote SSH and it actually works!). I think it all stems from my botched migration basically. Would be cool to pair and sort this out one day.
Author
Owner

Ok, I sank some time into this. It seems that the flow is this. We have a volume mounted for the gitea container living at /var/lib/docker/volumes/gitea_git/_data. In there, there is a ssh folder. Now, when Gitea turns on, it generates host keys into that folder. The first time, it sets the gogs.rsa.pub to 1000:1000 permissions. Things work. The next time Gitea turns on, it sems the gogs.rsa.pub file to root:root permissions and then complains that it can't access it and then generates an in-memory ssh host key which is different! Then we get the spooky error message. So, unable to find a real cause to this, I went ahead and just ran chattr +i gogs.rsa and chattr +i gogs.rsa.pub so that Gitea can't mistakenly reset the permissions for the host keys and they persist and are used. I don't even know if I should raise a bug about this or what is the root of it but it seems solved for now.

Ok, I sank some time into this. It seems that the flow is this. We have a volume mounted for the gitea container living at `/var/lib/docker/volumes/gitea_git/_data`. In there, there is a `ssh` folder. Now, when Gitea turns on, it generates host keys into that folder. The first time, it sets the `gogs.rsa.pub` to `1000:1000` permissions. Things work. The next time Gitea turns on, it sems the `gogs.rsa.pub` file to `root:root` permissions and then complains that it can't access it and then generates an in-memory ssh host key which is different! Then we get the spooky error message. So, unable to find a real cause to this, I went ahead and just ran `chattr +i gogs.rsa` and `chattr +i gogs.rsa.pub` so that Gitea can't mistakenly reset the permissions for the host keys and they persist and are used. I don't even know if I should raise a bug about this or what is the root of it but it seems solved for now.
This repo is archived. You cannot comment on issues.
No Label
No Milestone
No Assignees
2 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: autonomic-cooperative/git.autonomic.zone#11
No description provided.