Re: [pve-devel] [PATCH docs 2/2] ssh: document PVE-specific setup
--- Begin Message ---
On Fri, Jan 12, 2024 at 01:04:50PM +, Esi Y wrote:
> On Fri, Jan 12, 2024 at 01:40:44PM +0100, Fabian Grünbichler wrote:
> >
> > > Esi Y via pve-devel hat am 12.01.2024 13:33
> > > CET geschrieben:
> > > On Thu, Jan 11, 2024 at 11:51:20AM +0100, Fabian Grünbichler wrote:
> > > > such as adapted configs and managed files.
> > > >
> > > > Signed-off-by: Fabian Grünbichler
> > > > ---
> > > > Notes: actual version needs to be inserted!
> > > >
> > > > pvecm.adoc | 18 ++
> > > > 1 file changed, 18 insertions(+)
> > > >
> > > > diff --git a/pvecm.adoc b/pvecm.adoc
> > > > index 5b5b27b..3a32cfb 100644
> > > > --- a/pvecm.adoc
> > > > +++ b/pvecm.adoc
> > > > @@ -918,6 +918,24 @@ transfer memory and disk contents.
> > > >
> > > > * Storage replication
> > > >
> > > > +SSH setup
> > > > +~
> > > > +
> > > > +On {pve} systems, the following changes are made to the SSH
> > > > configuration/setup:
> > > > +
> > > > +* the `root` user's SSH client config gets setup to prefer `AES` over
> > > > `ChaCha20`
> > > > +
> > > > +* the `root` user's `authorized_keys` file gets linked to
> > > > + `/etc/pve/priv/authorized_keys`, merging all authorized keys within
> > > > a cluster
> > >
> > > Will you be opening a new fix # thread on this one or intending to keep
> > > it as-is (even as the known_hosts changes are rolled out)?
> >
> > see the cover letter - if this series gets applied in its current form,
> > then changing the (client) key setup (both the keys used, and the
> > authorized keys handling) would be a potential (but not required)
> > follow-up. the main issue with that is that setups out there might rely on
> > the current behaviour (e.g., ssh-copy-id to one node registering the key
> > automatically with all nodes in the cluster), so it's likely only possible
> > to switch by default on the next major bump, if we decide to go down that
> > route.
>
> I read the cover, I was just surprised it goes into the docs now as if
> already decided on. The backwards compatibility until next major could be
> retained if this was implemented (also) with AuthorizedKeysCommand. That way
> also logging of potential issues coming up with the next major could be used
> as a cue in upgrade script, i.e. if there were any uses of the "old" keys
> from the shared location.
Somehow forgotten to include the list. This is analogous suggestion to the
KnownHostsCommand to avoid relying on -o's.
--- End Message ---
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH cluster 2/4] fix #4886: SSH: pin node's host key if available
--- Begin Message ---
On Thu, Jan 11, 2024 at 11:51:16AM +0100, Fabian Grünbichler wrote:
> if the target node has already stored their SSH host key on pmxcfs, pin it and
> ignore the global known hosts information.
>
> Signed-off-by: Fabian Grünbichler
> ---
> src/PVE/SSHInfo.pm | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/src/PVE/SSHInfo.pm b/src/PVE/SSHInfo.pm
> index c351148..fad23bf 100644
> --- a/src/PVE/SSHInfo.pm
> +++ b/src/PVE/SSHInfo.pm
> @@ -49,11 +49,24 @@ sub get_ssh_info {
>
> sub ssh_info_to_command_base {
> my ($info, @extra_options) = @_;
> +
> +my $nodename = $info->{name};
> +
> +my $known_hosts_file = "/etc/pve/nodes/$nodename/ssh_known_hosts";
> +my $known_hosts_options = undef;
> +if (-f $known_hosts_file) {
> + $known_hosts_options = [
> + '-o', "UserKnownHostsFile=$known_hosts_file",
> + '-o', 'GlobalKnownHostsFile=none',
why does Global need to be none, even as this only applies if the snippet
exists?
> + ];
> +}
> +
> return [
> '/usr/bin/ssh',
> '-e', 'none',
> '-o', 'BatchMode=yes',
> - '-o', 'HostKeyAlias='.$info->{name},
> + '-o', 'HostKeyAlias='.$nodename,
> + defined($known_hosts_options) ? @$known_hosts_options : (),
> @extra_options
> ];
> }
> --
> 2.39.2
>
>
>
> ___
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
--- End Message ---
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-manager] qemu: bump max cores to 256 by socket
On 1/12/24 21:08, Alexandre Derumier wrote:
New epyc cpu already support 168 threads
qemu 8.1 support 1024 cores with q35
---
www/manager6/qemu/ProcessorEdit.js | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/www/manager6/qemu/ProcessorEdit.js
b/www/manager6/qemu/ProcessorEdit.js
index b845ff66..b3538727 100644
--- a/www/manager6/qemu/ProcessorEdit.js
+++ b/www/manager6/qemu/ProcessorEdit.js
@@ -125,7 +125,7 @@ Ext.define('PVE.qemu.ProcessorInputPanel', {
xtype: 'proxmoxintegerfield',
name: 'cores',
minValue: 1,
- maxValue: 128,
+ maxValue: 256,
value: '1',
fieldLabel: gettext('Cores'),
allowBlank: false,
mhmm.. in the backend we don't actually have a limit, maybe it's time to remove
the limit in the ui
altogether? it does not help anyway:
for numbers that are not too big (too many for qemu, too many for the host)
it's not the right limit (qemu) or we don't know at that point in the gui (host
cores)
but in case next year there is e.g. a 512 core machine, the limit is too low
again...
so i'd be either for
* removing the limit at all
* limit to the qemu limits (but maybe also in the backend?)
* use the number of cores of the current host as limit in the gui (should be possible, but an
additional api call)
what do you think?
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH cluster 2/4] fix #4886: SSH: pin node's host key if available
> On Thu, Jan 11, 2024 at 11:51:16AM +0100, Fabian Grünbichler wrote:
> > if the target node has already stored their SSH host key on pmxcfs, pin it
> > and
> > ignore the global known hosts information.
> >
> > Signed-off-by: Fabian Grünbichler
> > ---
> > src/PVE/SSHInfo.pm | 15 ++-
> > 1 file changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/PVE/SSHInfo.pm b/src/PVE/SSHInfo.pm
> > index c351148..fad23bf 100644
> > --- a/src/PVE/SSHInfo.pm
> > +++ b/src/PVE/SSHInfo.pm
> > @@ -49,11 +49,24 @@ sub get_ssh_info {
> >
> > sub ssh_info_to_command_base {
> > my ($info, @extra_options) = @_;
> > +
> > +my $nodename = $info->{name};
> > +
> > +my $known_hosts_file = "/etc/pve/nodes/$nodename/ssh_known_hosts";
> > +my $known_hosts_options = undef;
> > +if (-f $known_hosts_file) {
> > + $known_hosts_options = [
> > + '-o', "UserKnownHostsFile=$known_hosts_file",
> > + '-o', 'GlobalKnownHostsFile=none',
>
> why does Global need to be none, even as this only applies if the snippet
> exists?
because we want to only let SSH look at our pinned file, not the regular one,
which might contain bogus information. since our pinned file contains an entry
for our host key alias which must match, the global file can never improve the
situation, but it can cause a verification failure.
> > + ];
> > +}
> > +
> > return [
> > '/usr/bin/ssh',
> > '-e', 'none',
> > '-o', 'BatchMode=yes',
> > - '-o', 'HostKeyAlias='.$info->{name},
> > + '-o', 'HostKeyAlias='.$nodename,
> > + defined($known_hosts_options) ? @$known_hosts_options : (),
> > @extra_options
> > ];
> > }
> > --
> > 2.39.2
> >
> >
> >
> > ___
> > pve-devel mailing list
> > pve-devel@lists.proxmox.com
> > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-manager] qemu: bump max cores to 256 by socket
>>mhmm.. in the backend we don't actually have a limit, maybe it's time >>to remove the limit in the ui >>altogether? it does not help anyway: >>for numbers that are not too big (too many for qemu, too many for the >>host) >>it's not the right limit (qemu) or we don't know at that point in the >>gui (host cores) >>but in case next year there is e.g. a 512 core machine, the limit is >>too low again... >>so i'd be either for >>* removing the limit at all >>* limit to the qemu limits (but maybe also in the backend?) >>* use the number of cores of the current host as limit in the gui >>(should be possible, but an >>additional api call) >> >>what do you think? Yes, indeed the backend don't have any limit. We could indeed remove the limit in the gui. I think we shouldn't limit based on the current host, as anyway, we can create && migrate the vm on antoher host just after the create. Maybe an improvement in qemu-server, could be to add additional check at vm start, (maybe a simple warn), depending of qemu version or setup. For example, 1024 cores only works with q35 && qemu 8.1, it could be interesting to give an clean hint mesage to user instead a qemu process error. ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-manager] qemu: bump max cores to 256 by socket
Am 15.01.24 um 13:43 schrieb DERUMIER, Alexandre: > > > Maybe an improvement in qemu-server, could be to add additional check > at vm start, (maybe a simple warn), depending of qemu version or > setup. > For example, 1024 cores only works with q35 && qemu 8.1, > it could be interesting to give an clean hint mesage to user instead > a qemu process error. > Is the QEMU error message understandable? If yes, I don't see much value in adding such a heuristic and warning ourselves. If no, we can either improve the QEMU error message or do as you suggested. ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH cluster 2/4] fix #4886: SSH: pin node's host key if available
--- Begin Message ---
On Mon, Jan 15, 2024 at 12:51:48PM +0100, Fabian Grünbichler wrote:
> > On Thu, Jan 11, 2024 at 11:51:16AM +0100, Fabian Grünbichler wrote:
> > > if the target node has already stored their SSH host key on pmxcfs, pin
> > > it and
> > > ignore the global known hosts information.
> > >
> > > Signed-off-by: Fabian Grünbichler
> > > ---
> > > src/PVE/SSHInfo.pm | 15 ++-
> > > 1 file changed, 14 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/src/PVE/SSHInfo.pm b/src/PVE/SSHInfo.pm
> > > index c351148..fad23bf 100644
> > > --- a/src/PVE/SSHInfo.pm
> > > +++ b/src/PVE/SSHInfo.pm
> > > @@ -49,11 +49,24 @@ sub get_ssh_info {
> > >
> > > sub ssh_info_to_command_base {
> > > my ($info, @extra_options) = @_;
> > > +
> > > +my $nodename = $info->{name};
> > > +
> > > +my $known_hosts_file = "/etc/pve/nodes/$nodename/ssh_known_hosts";
> > > +my $known_hosts_options = undef;
> > > +if (-f $known_hosts_file) {
> > > + $known_hosts_options = [
> > > + '-o', "UserKnownHostsFile=$known_hosts_file",
> > > + '-o', 'GlobalKnownHostsFile=none',
> >
> > why does Global need to be none, even as this only applies if the snippet
> > exists?
>
> because we want to only let SSH look at our pinned file, not the regular one,
> which might contain bogus information. since our pinned file contains an
> entry for our host key alias which must match, the global file can never
> improve the situation, but it can cause a verification failure.
This might not work as expected.
1. There will not be any verification failure if there is at least some valid
key present. If wrong keys are present alongside a good one, it's a pass. If
_only_ wrong keys are present, with StrictHostKeyChecking default (ask) it will
outright stop.
2. The Global none does not improve anything there. If no keys are present it
will try to ask (under SKHC default), but no use in BatchMode.
3. Using -o UserKHF alongside default SKHC, e.g. if run by someone even
manually after a failed script without BatchMode, will have it crash for them
because the pinned file cannot be updated by ssh properly due to the same issue
as mentioned before regarding ssh-keygen -R. In this case the pmxcfs will cause
it to crash again on link-unlink-rename() again [1].
[1]
https://github.com/openssh/openssh-portable/blob/50080fa42f5f744b798ee29400c0710f1b59f50e/hostfile.c#L695
4. I suppose you did not like my suggestion re KnownHostsCommand [2] instead of
"pinning", but giving -o's to ssh code where the files reside on pmxcfs is just
creating the same problem (that e.g. keygen -R had) elsewhere depending if you
plan e.g. multiline.
[2] https://lists.proxmox.com/pipermail/pve-devel/2024-January/061329.html
> > > + ];
> > > +}
> > > +
> > > return [
> > > '/usr/bin/ssh',
> > > '-e', 'none',
> > > '-o', 'BatchMode=yes',
> > > - '-o', 'HostKeyAlias='.$info->{name},
> > > + '-o', 'HostKeyAlias='.$nodename,
> > > + defined($known_hosts_options) ? @$known_hosts_options : (),
> > > @extra_options
> > > ];
> > > }
> > > --
> > > 2.39.2
> > >
> > >
> > >
> > > ___
> > > pve-devel mailing list
> > > pve-devel@lists.proxmox.com
> > > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
--- End Message ---
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH cluster/manager/storage/docs 0/9] fix #4886: improve SSH handling
Tested cluster creation with three new nodes on 8.1 and the patches Cluster creation and further ssh communication (eq. migration) worked flawless Tested-by: Hannes Duerr On 1/11/24 11:51, Fabian Grünbichler wrote: this series replaces the old mechanism that used a cluster-wide merged known hosts file with distributing of each node's host key via pmxcfs, and pinning the distributed key explicitly for internal SSH connections. the main changes in pve-cluster somewhat break the old manager and storage versions, but only when such a partial upgrade is mixed with a host key rotation of some sort. pve-storage uses a newly introduced helper, so needs a versioned dependency accordingly. the last pve-docs patch has a placeholder for the actual version shipping the changes which needs to be replaced when applying. there's still some potential for follow-ups: - 'pvecm ssh' wrapper to debug and/or re-use the host key pinning (and other future changes) - also add non-RSA host keys - key (and thus authorized keys) and/or sshd disentangling (this potentially also affects external access, so might be done on a major release to give more heads up) cluster: Fabian Grünbichler (4): fix #4886: write node SSH hostkey to pmxcfs fix #4886: SSH: pin node's host key if available ssh: expose SSH options on their own pvecm: stop merging SSH known hosts by default src/PVE/CLI/pvecm.pm | 10 -- src/PVE/Cluster/Setup.pm | 24 +--- src/PVE/SSHInfo.pm | 31 +++ 3 files changed, 56 insertions(+), 9 deletions(-) docs: Fabian Grünbichler (2): ssh: make pitfalls a regular section instead of block ssh: document PVE-specific setup pvecm.adoc | 26 +- 1 file changed, 21 insertions(+), 5 deletions(-) manager: Fabian Grünbichler (2): vnc: use SSH command helper pvesh: use SSH command helper PVE/API2/Nodes.pm | 3 ++- PVE/CLI/pvesh.pm | 4 ++-- 2 files changed, 4 insertions(+), 3 deletions(-) storage: Fabian Grünbichler (1): upload: use SSH helper to get ssh/scp options src/PVE/API2/Storage/Status.pm | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-manager] fix #4963: firewall: fix editing firewall rules using cidrs
Fallback to v.ref when we do not use an alias or ipset in order to be
able to use normal CIDRs as source / destination address again
Signed-off-by: Stefan Hanreich
---
www/manager6/form/IPRefSelector.js | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/www/manager6/form/IPRefSelector.js
b/www/manager6/form/IPRefSelector.js
index b50ac1e10..7e5eea63a 100644
--- a/www/manager6/form/IPRefSelector.js
+++ b/www/manager6/form/IPRefSelector.js
@@ -37,8 +37,10 @@ Ext.define('PVE.form.IPRefSelector', {
calculate: function(v) {
if (v.type === 'alias') {
return `${v.scope}/${v.name}`;
- } else {
+ } else if (v.type === 'ipset') {
return `+${v.scope}/${v.name}`;
+ } else {
+ return v.ref;
}
},
},
--
2.39.2
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied-series: [PATCH v3 ceph 0/2] Complete Workaround For Ceph Dashboard
Am 05/01/2024 um 15:07 schrieb Max Carrara: > These two patches allow the Ceph Dashboard to work again as intended. > > The first patch provides a backport of a pull request [0] which removes > the dependency on PyJWT. [1] > > The second patch removes two usages of functions that use PyOpenSSL, [2] > which prevents running into sub-interpreter-related issues with > PyO3. [3] This is achieved by removing a check during the dashboard's > launch as well as prohibiting users from creating self-signed TLS certs > via the `ceph` CLI. Users may still provide a key/cert pair manually > and are instructed to do so once they try to execute the respective > command. [4] > > > [0]: https://github.com/ceph/ceph/pull/54710 > [1]: https://github.com/jpadilla/pyjwt > [2]: https://github.com/pyca/pyopenssl > [3]: https://tracker.ceph.com/issues/63529 > [4]: `ceph dashboard create-self-signed-cert` > > Max Carrara (2): > mgr/dashboard: add backport that allows the dashboard to work again > mgr/dashboard: add patch that removes PyOpenSSL-related usages > > ...hboard-simplify-authentication-proto.patch | 279 ++ > ...move-ability-to-create-and-check-TLS.patch | 101 +++ > patches/series| 2 + > 3 files changed, 382 insertions(+) > create mode 100644 > patches/0012-backport-mgr-dashboard-simplify-authentication-proto.patch > create mode 100644 > patches/0013-mgr-dashboard-remove-ability-to-create-and-check-TLS.patch > applied, thanks! ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH docs] pvecm: remove node: explain how to deal with the node's pmxcfs directory
Am 05/01/2024 um 10:26 schrieb Fiona Ebner: > Reported in the community forum: > https://forum.proxmox.com/threads/139006/post-621739 > > Signed-off-by: Fiona Ebner > --- > pvecm.adoc | 4 > 1 file changed, 4 insertions(+) > > applied, thanks! ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH proxmox-i18n] es: update translations
Am 03/01/2024 um 16:18 schrieb Maximiliano Sandoval: > This patch follows the the discussion at > https://lists.proxmox.com/pipermail/pve-devel/2023-December/061192.html. > > The use of exclamation and question marks is improved, one or two typos > are fixed, and we use lowercase rather than "Header Capitalization" in a > consistent way. > > Signed-off-by: Maximiliano Sandoval > --- > es.po | 1201 + > 1 file changed, 603 insertions(+), 598 deletions(-) > > applied, thanks! ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
