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

[Daniel Kral <d.kral@proxmox.com>]

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(...)?


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