Insecure migration settings

valeech · Nov 18, 2016

Hello,

Running PVE 4.3. I would like to disable secure migrations. Per http://pve.proxmox.com/wiki/Manual:_datacenter.cfg I should add the following line to the /etc/pve/datacenter.cfg:

migration: type=insecure

I have added that to the config file. Now, every night I get an email with the following:

parse error in '/etc/pve/datacenter.cfg' - 'migration': property is not defined in schema and the schema does not allow additional properties

I found other forum and blog references that mention adding the following to the datacenter.cfg file:

migration_unsecure: 1

I would have added this, however, the Proxmox manual at the URL above specifically says not to use it as it is deprecated.

What is the best method at this point to disable secure migrations?

Thanks!

adamb · Nov 18, 2016

valeech said:
Hello,

Running PVE 4.3. I would like to disable secure migrations. Per http://pve.proxmox.com/wiki/Manual:_datacenter.cfg I should add the following line to the /etc/pve/datacenter.cfg:

migration: type=insecure

I have added that to the config file. Now, every night I get an email with the following:

parse error in '/etc/pve/datacenter.cfg' - 'migration': property is not defined in schema and the schema does not allow additional properties

I found other forum and blog references that mention adding the following to the datacenter.cfg file:

migration_unsecure: 1

I would have added this, however, the Proxmox manual at the URL above specifically says not to use it as it is deprecated.

What is the best method at this point to disable secure migrations?

Thanks!

As far as I know "migration_unsecure: 1" still works.

tom · Nov 18, 2016

Please check the online documentation:

http://pve.proxmox.com/pve-docs/pve-admin-guide.html#_configuration_files_2

valeech · Nov 18, 2016

Great! Thanks. I will try that out.

Once I add the parameter to the config file, do I need to do anything for it to take effect? Do I need to run pveupdate or anything or is it automatic?

valeech · Nov 18, 2016

tom said:
Please check the online documentation:

http://pve.proxmox.com/pve-docs/pve-admin-guide.html#_configuration_files_2

Hi Tom, that documentation states the same thing as the manual I linked to. It says to use the new format, but that format does not work.

tom · Nov 18, 2016

I assume you do not run latest version, update to latest.

and post your:

> pveversion -v

adamb · Nov 18, 2016

tom said:
I assume you do not run latest version, update to latest.

and post your:

> pveversion -v

I am running the latest version and I can confirm the new option does not work but the old option does.

Working
migration_unsecure: 1

Not Working
migration:type=insecure

root@supprox1:~# cat /etc/pve/datacenter.cfg
keyboard: en-us
migration_unsecure: 1
#migration:type=insecure
root@supprox1:~# pveversion -v
proxmox-ve: 4.3-71 (running kernel: 4.4.21-1-pve)
pve-manager: 4.3-9 (running version: 4.3-9/f7c6f0cd)
pve-kernel-4.4.6-1-pve: 4.4.6-48
pve-kernel-4.4.13-1-pve: 4.4.13-56
pve-kernel-4.2.6-1-pve: 4.2.6-36
pve-kernel-4.4.8-1-pve: 4.4.8-52
pve-kernel-4.4.13-2-pve: 4.4.13-58
pve-kernel-4.4.21-1-pve: 4.4.21-71
pve-kernel-4.2.8-1-pve: 4.2.8-41
pve-kernel-4.1.3-1-pve: 4.1.3-7
pve-kernel-4.4.19-1-pve: 4.4.19-66
pve-kernel-4.4.10-1-pve: 4.4.10-54
pve-kernel-4.2.3-2-pve: 4.2.3-22
lvm2: 2.02.116-pve3
corosync-pve: 2.4.0-1
libqb0: 1.0-1
pve-cluster: 4.0-46
qemu-server: 4.0-92
pve-firmware: 1.1-10
libpve-common-perl: 4.0-79
libpve-access-control: 4.0-19
libpve-storage-perl: 4.0-68
pve-libspice-server1: 0.12.8-1
vncterm: 1.2-1
pve-docs: 4.3-12
pve-qemu-kvm: 2.7.0-4
pve-container: 1.0-80
pve-firewall: 2.0-31
pve-ha-manager: 1.0-35
ksm-control-daemon: 1.2-1
glusterfs-client: 3.5.2-2+deb8u2
lxc-pve: 2.0.5-1
lxcfs: 2.0.4-pve2
criu: 1.6.0-1
novnc-pve: 0.5-8
smartmontools: 6.5+svn4324-1~pve80
zfsutils: 0.6.5.8-pve13~bpo80

valeech · Nov 18, 2016

Here is my version:

root@pve:~# pveversion -v
proxmox-ve: 4.3-66 (running kernel: 4.4.19-1-pve)
pve-manager: 4.3-3 (running version: 4.3-3/557191d3)
pve-kernel-4.4.6-1-pve: 4.4.6-48
pve-kernel-4.4.19-1-pve: 4.4.19-66
lvm2: 2.02.116-pve3
corosync-pve: 2.4.0-1
libqb0: 1.0-1
pve-cluster: 4.0-46
qemu-server: 4.0-91
pve-firmware: 1.1-9
libpve-common-perl: 4.0-75
libpve-access-control: 4.0-19
libpve-storage-perl: 4.0-66
pve-libspice-server1: 0.12.8-1
vncterm: 1.2-1
pve-qemu-kvm: 2.6.2-2
pve-container: 1.0-78
pve-firewall: 2.0-31
pve-ha-manager: 1.0-35
ksm-control-daemon: 1.2-1
glusterfs-client: 3.5.2-2+deb8u2
lxc-pve: 2.0.5-1
lxcfs: 2.0.4-pve1
criu: 1.6.0-1
novnc-pve: 0.5-8
zfsutils: 0.6.5.7-pve10~bpo80
ceph: 0.94.9-1~bpo80+1

robhost · Nov 18, 2016

What does "insecure" instead of SSH? Simply netcat?

robhost · Nov 18, 2016

PS:

Same here:

parse error in '/etc/pve/datacenter.cfg' - 'migration': property is not defined in schema and the schema does not allow additional properties
migration listens on unix:/run/qemu-server/9997.migrate
TASK OK

Old setting "migration_unsecure" still works, the "new" format not.

pve-manager/4.3-9/f7c6f0cd (running kernel: 4.4.19-1-pve)
root@hav101:/etc/pve# pveversion -v
proxmox-ve: 4.3-71 (running kernel: 4.4.19-1-pve)
pve-manager: 4.3-9 (running version: 4.3-9/f7c6f0cd)
pve-kernel-4.4.13-1-pve: 4.4.13-56
pve-kernel-4.4.8-1-pve: 4.4.8-52
pve-kernel-4.4.13-2-pve: 4.4.13-58
pve-kernel-4.4.21-1-pve: 4.4.21-71
pve-kernel-4.4.15-1-pve: 4.4.15-60
pve-kernel-4.4.16-1-pve: 4.4.16-64
pve-kernel-4.2.2-1-pve: 4.2.2-16
pve-kernel-4.4.19-1-pve: 4.4.19-66
pve-kernel-4.4.10-1-pve: 4.4.10-54
lvm2: 2.02.116-pve3
corosync-pve: 2.4.0-1
libqb0: 1.0-1
pve-cluster: 4.0-46
qemu-server: 4.0-92
pve-firmware: 1.1-10
libpve-common-perl: 4.0-79
libpve-access-control: 4.0-19
libpve-storage-perl: 4.0-68
pve-libspice-server1: 0.12.8-1
vncterm: 1.2-1
pve-docs: 4.3-12
pve-qemu-kvm: 2.7.0-4
pve-container: 1.0-80
pve-firewall: 2.0-31
pve-ha-manager: 1.0-35
ksm-control-daemon: 1.2-1
glusterfs-client: 3.5.2-2+deb8u2
lxc-pve: 2.0.5-1
lxcfs: 2.0.4-pve2
criu: 1.6.0-1
novnc-pve: 0.5-8
smartmontools: 6.5+svn4324-1~pve80
zfsutils: 0.6.5.8-pve13~bpo80

tom · Nov 18, 2016

See https://bugzilla.proxmox.com/show_bug.cgi?id=1177

__

For this functionality the following package version (or newer) are needed:

qemu-server: 4.0-93
libpve-common-perl: 4.0-80
pve-cluster: 4.0-47

valeech · Nov 18, 2016

Thanks Tom! I'll try that out and report back.

robhost · Nov 18, 2016

tom said:
See https://bugzilla.proxmox.com/show_bug.cgi?id=1177

__

For this functionality the following package version (or newer) are needed:

qemu-server: 4.0-93
libpve-common-perl: 4.0-80
pve-cluster: 4.0-47

Okay, these version seems not (yet) to be in the enterprise repo, right?

tom · Nov 19, 2016

robhost said:
Okay, these version seems not (yet) to be in the enterprise repo, right?

yes, not yet. there are some improvements which are not yet committed.

Alessandro 123 · Nov 19, 2016

I have a suggestion. With secure migration, would be possible to force (or allow customization of) the cipher ?

arcfour256 or, even better, arcfour128 are way faster than default (about 2 times faster)
https://blog.famzah.net/2010/06/11/openssh-ciphers-performance-benchmark/

There is no need to use an heavy cipher for a VM transfer. The transfer time is so short that would be impossible to decrypt any traffic in that time.

dcsapak · Nov 21, 2016

Alessandro 123 said:
I have a suggestion. With secure migration, would be possible to force (or allow customization of) the cipher ?

this should already be possible with your ssh_config on the hosts? (if i am not missing something)

Alessandro 123 said:
There is no need to use an heavy cipher for a VM transfer. The transfer time is so short that would be impossible to decrypt any traffic in that time.

but if an attacker captures it, he could decrypt it much easier afterwards..

Alessandro 123 · Nov 21, 2016

dcsapak said:
this should already be possible with your ssh_config on the hosts? (if i am not missing something)

Yes but having it integrated in pve is better than having to customize each node

but if an attacker captures it, he could decrypt it much easier afterwards..

unless you are transferring via internet, i think this is a nonexistant issue
And even in that case, an attacker has to intercept the traffic during the transfer (a couple of hours?)
I dont think this would be an issue at all and you are still free to choose a different cipher...

fabian · Nov 21, 2016

I don't think this is a good idea

if you have a really private network for migration, you can simply use the unencrypted variant. if not, you should use proper encryption (and accept the performance hit). lowering the security properties while pretending to still be secure (which the configuration option name would imply!) is misleading. feel free to configure whichever ciphers you want (for both SSH and TLS) - but the default should be (reasonably) secure. also, switching to RC4 should not give you a noticeable performance boost anyway (on modern enough hardware)..

Alessandro 123 · Nov 21, 2016

With recent hardware (less than 1 year old, dual E5-2600) switching from the default cipher to ARC4 increased 4 times the transfer rate with scp

fabian · Nov 22, 2016

Alessandro 123 said:
With recent hardware (less than 1 year old, dual E5-2600) switching from the default cipher to ARC4 increased 4 times the transfer rate with scp

benchmark on a single socket, quad core Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (copying from ram disk to ram disk, three times, speeds are in MB/s):

Code:

aes128-cbc: 503 490 501
aes128-ctr: 617 671 645
aes128-gcm@openssh.com: 744 687 731
aes192-cbc: 466 469 468
aes192-ctr: 635 598 645
aes256-cbc: 445 445 448
aes256-ctr: 594 612 605
aes256-gcm@openssh.com: 679 682 673
arcfour: 341 347 350
arcfour128: 350 344 355
arcfour256: 351 346 348
blowfish-cbc: 131 131 131
cast128-cbc: 131 130 130
chacha20-poly1305@openssh.com: 283 287 286
3des-cbc: 32.8 32.8 32.9

the default that openssh on Jessie seems to use if no preference is given either on the server or client side is aes128-ctr, which is probably a good compromise in general - but if your benchmark shows that another AES mode is faster on your hardware, you can set the preferred cipher order accordingly in the root user's ssh config.

but even if that were not the case, arcfour is disabled for a reason (not just by us, but by Debian by default - it is insecure!). if you are not worried about using arcfour, you should not be worried about not encrypting at all. if you have doubts about migrating without encryption, then you should not use arcfour either. also not that if you'd enable arcfour cluster-wide, all SSH connections potentially would use arcfour - also those from outside (so the security properties that might apply for migration on the local network don't hold anymore) - which is why we offer migration without ssh for setups where the local network is sufficiently secure without encryption.

if anything, I'd be in favour of switching the cipher list on the server side to "Ciphers aes128-gcm@openssh.com,aes128-ctr,aes256-ctr,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com" by default

Insecure migration settings

Well-Known Member

Famous Member

Proxmox Staff Member

Well-Known Member

Well-Known Member

Proxmox Staff Member

Famous Member

Well-Known Member

Active Member

Active Member

Proxmox Staff Member

Well-Known Member

Active Member

Proxmox Staff Member

Well-Known Member

Proxmox Staff Member

Well-Known Member

Proxmox Staff Member

Well-Known Member

Proxmox Staff Member