> Daniel Kral <d.k...@proxmox.com> hat am 27.06.2025 10:59 CEST geschrieben:
>
>
> On 6/27/25 10:46, Fabian Grünbichler wrote:
> >
> >> 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..
>
> 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
