| /openbmc/openbmc/meta-phosphor/recipes-core/dropbear/dropbear/ |
| H A D | dropbear-migrate-key-location.service | a0e20ab1 Fri May 05 16:31:59 CDT 2023 Patrick Williams <patrick@stwcx.xyz> meta-phosphor: fix openssh key generation on read-only-rootfs types
Some of our file system layouts enable the `read-only-rootfs` feature,
which happens to trigger some code in rootfs-postcommands.bbclass that
moves the SSH key location from `/etc` to `/var`. For Dropbear, the
default was to move it to `/var/lib`, which we happen to put into an
overlay, but for OpenSSH it moved it to `/var/run`. The result of this
is that the SSH key is regenerated on each reboot.
In order to bypass this code that expects the SSH key to be in a
volatile file system, Yocto provides the `overlayfs-etc` IMAGE_FEATURE
as well. We need to enable this, but this feature as a side-effect
generates an alternative `/sbin/init` similar to what we do for
pre-mounting the overlay. We need to disable this aspect so I've set
some variables and appends to cause `overlay-etc.bbclass` to have no
effect.
Lastly, the result of all of this is that the location for the dropbear
key moves from `/var/lib` to `/etc` (which is what the default is on
the jffs2-based layouts already). Add some migration services that
will move existing keys in the old location over to `/etc` so that
users do not notice a host key change as part of this.
Tested: Tested on Bletchley (OpenSSH) and Witherspoon (Dropbear).
Bletchley no longer regenerates the SSH key on each reboot.
Witherspoon has the key location in `/etc/dropbear` as expected and
the migration service successfully runs before the
`dropbearkey.service`.
```
May 05 21:46:40 witherspoon systemd[1]: Starting SSH Key Generation...
May 05 21:46:41 witherspoon sh[268]: Generating 2048 bit rsa key, this may take a while...
May 05 21:47:13 witherspoon sh[268]: Public key portion is:
May 05 21:47:13 witherspoon sh[268]: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCgiywAIF3RleqNphZZuUjNCXDI10ChEAoPI02/g9F8CiXI2Pc55nFHh/hrTn7niawydpEc8FH62rf1WpoA5hYkKrj/j6i2Iv1UrGFZX4q9IwlFcd3...
May 05 21:47:13 witherspoon sh[268]: Fingerprint: SHA256:tsjx4PBtcaiLnUCFh4XESPRnTXoGsgujVrbdJD4INMY
May 05 21:47:13 witherspoon systemd[1]: Finished SSH Key Generation.
```
Manually moved the key to `/var/lib` and rebooted and observed the same
key moved back to `/etc` (on Witherspoon).
```
May 05 21:49:01 witherspoon systemd[1]: Starting Migrate dropbear keys from /var/lib to /etc...
May 05 21:49:02 witherspoon migrate-key-location[194]: Migrating Dropbear key from /var/lib to /etc.
May 05 21:49:11 witherspoon systemd[1]: Finished Migrate dropbear keys from /var/lib to /etc.
May 05 21:49:14 witherspoon systemd[1]: Starting SSH Key Generation...
May 05 21:49:18 witherspoon systemd[1]: Finished SSH Key Generation.
```
After one last reboot, the key in `/etc` is reused:
```
May 05 21:51:44 witherspoon systemd[1]: Starting SSH Key Generation...
May 05 21:51:45 witherspoon systemd[1]: Finished SSH Key Generation.
```
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I68b6c383f91931995e3d3203e5aafd8fdc23f750
|
| H A D | migrate-key-location | a0e20ab1 Fri May 05 16:31:59 CDT 2023 Patrick Williams <patrick@stwcx.xyz> meta-phosphor: fix openssh key generation on read-only-rootfs types
Some of our file system layouts enable the `read-only-rootfs` feature,
which happens to trigger some code in rootfs-postcommands.bbclass that
moves the SSH key location from `/etc` to `/var`. For Dropbear, the
default was to move it to `/var/lib`, which we happen to put into an
overlay, but for OpenSSH it moved it to `/var/run`. The result of this
is that the SSH key is regenerated on each reboot.
In order to bypass this code that expects the SSH key to be in a
volatile file system, Yocto provides the `overlayfs-etc` IMAGE_FEATURE
as well. We need to enable this, but this feature as a side-effect
generates an alternative `/sbin/init` similar to what we do for
pre-mounting the overlay. We need to disable this aspect so I've set
some variables and appends to cause `overlay-etc.bbclass` to have no
effect.
Lastly, the result of all of this is that the location for the dropbear
key moves from `/var/lib` to `/etc` (which is what the default is on
the jffs2-based layouts already). Add some migration services that
will move existing keys in the old location over to `/etc` so that
users do not notice a host key change as part of this.
Tested: Tested on Bletchley (OpenSSH) and Witherspoon (Dropbear).
Bletchley no longer regenerates the SSH key on each reboot.
Witherspoon has the key location in `/etc/dropbear` as expected and
the migration service successfully runs before the
`dropbearkey.service`.
```
May 05 21:46:40 witherspoon systemd[1]: Starting SSH Key Generation...
May 05 21:46:41 witherspoon sh[268]: Generating 2048 bit rsa key, this may take a while...
May 05 21:47:13 witherspoon sh[268]: Public key portion is:
May 05 21:47:13 witherspoon sh[268]: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCgiywAIF3RleqNphZZuUjNCXDI10ChEAoPI02/g9F8CiXI2Pc55nFHh/hrTn7niawydpEc8FH62rf1WpoA5hYkKrj/j6i2Iv1UrGFZX4q9IwlFcd3...
May 05 21:47:13 witherspoon sh[268]: Fingerprint: SHA256:tsjx4PBtcaiLnUCFh4XESPRnTXoGsgujVrbdJD4INMY
May 05 21:47:13 witherspoon systemd[1]: Finished SSH Key Generation.
```
Manually moved the key to `/var/lib` and rebooted and observed the same
key moved back to `/etc` (on Witherspoon).
```
May 05 21:49:01 witherspoon systemd[1]: Starting Migrate dropbear keys from /var/lib to /etc...
May 05 21:49:02 witherspoon migrate-key-location[194]: Migrating Dropbear key from /var/lib to /etc.
May 05 21:49:11 witherspoon systemd[1]: Finished Migrate dropbear keys from /var/lib to /etc.
May 05 21:49:14 witherspoon systemd[1]: Starting SSH Key Generation...
May 05 21:49:18 witherspoon systemd[1]: Finished SSH Key Generation.
```
After one last reboot, the key in `/etc` is reused:
```
May 05 21:51:44 witherspoon systemd[1]: Starting SSH Key Generation...
May 05 21:51:45 witherspoon systemd[1]: Finished SSH Key Generation.
```
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I68b6c383f91931995e3d3203e5aafd8fdc23f750
|
| /openbmc/openbmc/meta-phosphor/recipes-core/dropbear/ |
| H A D | dropbear_%.bbappend | a0e20ab1 Fri May 05 16:31:59 CDT 2023 Patrick Williams <patrick@stwcx.xyz> meta-phosphor: fix openssh key generation on read-only-rootfs types
Some of our file system layouts enable the `read-only-rootfs` feature,
which happens to trigger some code in rootfs-postcommands.bbclass that
moves the SSH key location from `/etc` to `/var`. For Dropbear, the
default was to move it to `/var/lib`, which we happen to put into an
overlay, but for OpenSSH it moved it to `/var/run`. The result of this
is that the SSH key is regenerated on each reboot.
In order to bypass this code that expects the SSH key to be in a
volatile file system, Yocto provides the `overlayfs-etc` IMAGE_FEATURE
as well. We need to enable this, but this feature as a side-effect
generates an alternative `/sbin/init` similar to what we do for
pre-mounting the overlay. We need to disable this aspect so I've set
some variables and appends to cause `overlay-etc.bbclass` to have no
effect.
Lastly, the result of all of this is that the location for the dropbear
key moves from `/var/lib` to `/etc` (which is what the default is on
the jffs2-based layouts already). Add some migration services that
will move existing keys in the old location over to `/etc` so that
users do not notice a host key change as part of this.
Tested: Tested on Bletchley (OpenSSH) and Witherspoon (Dropbear).
Bletchley no longer regenerates the SSH key on each reboot.
Witherspoon has the key location in `/etc/dropbear` as expected and
the migration service successfully runs before the
`dropbearkey.service`.
```
May 05 21:46:40 witherspoon systemd[1]: Starting SSH Key Generation...
May 05 21:46:41 witherspoon sh[268]: Generating 2048 bit rsa key, this may take a while...
May 05 21:47:13 witherspoon sh[268]: Public key portion is:
May 05 21:47:13 witherspoon sh[268]: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCgiywAIF3RleqNphZZuUjNCXDI10ChEAoPI02/g9F8CiXI2Pc55nFHh/hrTn7niawydpEc8FH62rf1WpoA5hYkKrj/j6i2Iv1UrGFZX4q9IwlFcd3...
May 05 21:47:13 witherspoon sh[268]: Fingerprint: SHA256:tsjx4PBtcaiLnUCFh4XESPRnTXoGsgujVrbdJD4INMY
May 05 21:47:13 witherspoon systemd[1]: Finished SSH Key Generation.
```
Manually moved the key to `/var/lib` and rebooted and observed the same
key moved back to `/etc` (on Witherspoon).
```
May 05 21:49:01 witherspoon systemd[1]: Starting Migrate dropbear keys from /var/lib to /etc...
May 05 21:49:02 witherspoon migrate-key-location[194]: Migrating Dropbear key from /var/lib to /etc.
May 05 21:49:11 witherspoon systemd[1]: Finished Migrate dropbear keys from /var/lib to /etc.
May 05 21:49:14 witherspoon systemd[1]: Starting SSH Key Generation...
May 05 21:49:18 witherspoon systemd[1]: Finished SSH Key Generation.
```
After one last reboot, the key in `/etc` is reused:
```
May 05 21:51:44 witherspoon systemd[1]: Starting SSH Key Generation...
May 05 21:51:45 witherspoon systemd[1]: Finished SSH Key Generation.
```
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I68b6c383f91931995e3d3203e5aafd8fdc23f750
|
| /openbmc/openbmc/meta-phosphor/recipes-phosphor/images/ |
| H A D | obmc-phosphor-image.bb | a0e20ab1 Fri May 05 16:31:59 CDT 2023 Patrick Williams <patrick@stwcx.xyz> meta-phosphor: fix openssh key generation on read-only-rootfs types
Some of our file system layouts enable the `read-only-rootfs` feature,
which happens to trigger some code in rootfs-postcommands.bbclass that
moves the SSH key location from `/etc` to `/var`. For Dropbear, the
default was to move it to `/var/lib`, which we happen to put into an
overlay, but for OpenSSH it moved it to `/var/run`. The result of this
is that the SSH key is regenerated on each reboot.
In order to bypass this code that expects the SSH key to be in a
volatile file system, Yocto provides the `overlayfs-etc` IMAGE_FEATURE
as well. We need to enable this, but this feature as a side-effect
generates an alternative `/sbin/init` similar to what we do for
pre-mounting the overlay. We need to disable this aspect so I've set
some variables and appends to cause `overlay-etc.bbclass` to have no
effect.
Lastly, the result of all of this is that the location for the dropbear
key moves from `/var/lib` to `/etc` (which is what the default is on
the jffs2-based layouts already). Add some migration services that
will move existing keys in the old location over to `/etc` so that
users do not notice a host key change as part of this.
Tested: Tested on Bletchley (OpenSSH) and Witherspoon (Dropbear).
Bletchley no longer regenerates the SSH key on each reboot.
Witherspoon has the key location in `/etc/dropbear` as expected and
the migration service successfully runs before the
`dropbearkey.service`.
```
May 05 21:46:40 witherspoon systemd[1]: Starting SSH Key Generation...
May 05 21:46:41 witherspoon sh[268]: Generating 2048 bit rsa key, this may take a while...
May 05 21:47:13 witherspoon sh[268]: Public key portion is:
May 05 21:47:13 witherspoon sh[268]: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCgiywAIF3RleqNphZZuUjNCXDI10ChEAoPI02/g9F8CiXI2Pc55nFHh/hrTn7niawydpEc8FH62rf1WpoA5hYkKrj/j6i2Iv1UrGFZX4q9IwlFcd3...
May 05 21:47:13 witherspoon sh[268]: Fingerprint: SHA256:tsjx4PBtcaiLnUCFh4XESPRnTXoGsgujVrbdJD4INMY
May 05 21:47:13 witherspoon systemd[1]: Finished SSH Key Generation.
```
Manually moved the key to `/var/lib` and rebooted and observed the same
key moved back to `/etc` (on Witherspoon).
```
May 05 21:49:01 witherspoon systemd[1]: Starting Migrate dropbear keys from /var/lib to /etc...
May 05 21:49:02 witherspoon migrate-key-location[194]: Migrating Dropbear key from /var/lib to /etc.
May 05 21:49:11 witherspoon systemd[1]: Finished Migrate dropbear keys from /var/lib to /etc.
May 05 21:49:14 witherspoon systemd[1]: Starting SSH Key Generation...
May 05 21:49:18 witherspoon systemd[1]: Finished SSH Key Generation.
```
After one last reboot, the key in `/etc` is reused:
```
May 05 21:51:44 witherspoon systemd[1]: Starting SSH Key Generation...
May 05 21:51:45 witherspoon systemd[1]: Finished SSH Key Generation.
```
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I68b6c383f91931995e3d3203e5aafd8fdc23f750
|