> Daniel Kral <d.k...@proxmox.com> hat am 27.06.2025 10:20 CEST geschrieben:
>
>
> On 6/27/25 07:04, Fabian Grünbichler wrote:
> >
> >> Wolfgang Bumiller <w.bumil...@proxmox.com> hat am 26.06.2025 13:36 CEST
> >> geschrieben:
> >>
> >>
> >> On Wed, Jun 25, 2025 at 11:56:31AM +0200, Daniel Kral wrote:
> >>> OpenSSH 10.0 removes support for the DSA signature algorithm [0], which
> >>> is the base version that will be shipped for Debian 13 trixie [1]. Since
> >>> it has been marked deprecated for some time and generating DSA
> >>> signatures with OpenSSH 10.0 will fail, remove it.
> >>
> >> We should probably actively remove existing dsa host keys in case a
> >> container template ships them, just to make sure older distro containers
> >> won't end up all sharing the same DSA key when created on a trixie
> >> pve...
> >>
> >> In fact, maybe we should remove all files matching
> >> `/etc/ssh/ssh_host_*` in the setup code, in case there are types we
> >> missed?
> >
> > that sounds like a good idea, but should probably be visibly logged.
> >
> > for legacy distros (which are not the best fit for containers anyway)
> > it's always possible to generate keys if needed inside the container
> > afterwards..
>
> So something like
>
> sub remove_existing_ssh_host_keys {
> my ($self, $conf) = @_;
>
> my $ssh_dir = "$self->{rootdir}/etc/ssh";
>
> return if !-d $ssh_dir;
>
> my $keyfiles = [];
> PVE::Tools::dir_glob_foreach(
> $ssh_dir,
> qr/ssh_host_.*/,
> sub {
> my ($key_filename) = @_;
>
> next if $self->ct_is_file_ignored($key_filename);
>
> print "Removing pre-existing ssh host key
> '$key_filename' ...\n";
>
> push $keyfiles->@*, $key_filename;
> }
> );
>
> $self->protected_call(sub {
> for my $key_filename ($keyfiles->@*) {
> $self->ct_unlink($key_filename);
> }
> });
> }
>
> and calling it in PVE::LXC::Setup::Base::post_create_hook(...), so that
> unmanaged containers are not affected by this?
we already have PVE::LXC::Setup::rewrite_ssh_host_keys which AFAICT is
called unconditionally in Setup::post_create_hook even for unmanaged
containers, given that precedent I think we can just extend that..
while we are at it we could add .ignore support if we really want to
have an option of skipping deletion and regeneration..
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
