[pve-devel] [RFC container] setup: remove deprecated dsa from ssh host key generation

Fabian Grünbichler f.gruenbichler at proxmox.com
Fri Jun 27 10:46:28 CEST 2025


> Daniel Kral <d.kral at proxmox.com> hat am 27.06.2025 10:20 CEST geschrieben:
> 
>  
> On 6/27/25 07:04, Fabian Grünbichler wrote:
> > 
> >> Wolfgang Bumiller <w.bumiller at 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..




More information about the pve-devel mailing list