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

["Fabian Grünbichler" <f.gruenbichler@proxmox.com>]

> Daniel Kral <d.kral@proxmox.com> hat am 27.06.2025 10:59 CEST geschrieben:
> 
>  
> On 6/27/25 10:46, Fabian Grünbichler wrote:
> > 
> >> Daniel Kral <d.kral@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@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..
> 
> Right, then I'll extend that one instead.
> 
> > 
> > while we are at it we could add .ignore support if we really want to
> > have an option of skipping deletion and regeneration..
> 
> I added the check ct_is_file_ignored($key_filename) because 
> ct_unlink($key_filename) later checks against that and then the log 
> message would be wrong, right? Or should the later rewrite_ssh_host_keys 
> part also acknowledge ct_is_file_ignored(...)?

yes, if we ignore something then the file should be neither deleted nor
rewritten, IMHO. it should probably be logged that it is left
untouched though ;)


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel