Strange SSH/SSL failing since UTM mac 4.1.x

[GregOriol]

Describe the issue
With UTM mac 4.0.9, I have an Ubuntu 20.04 VM with the following working:

• I can ssh into it with an rsa public key authentication
• I can curl https urls to target an nginx inside the VM

With the same VM and UTM mac 4.1.5, I have the following behavior:

• I can't ssh into it with the public key, I must use a password
• I can't curl the https urls

Configuration

• UTM Version: 4.1.5
• macOS Version: 12.6.2
• Mac Chip (Intel, M1, ...): M1
• Networking of the VM is shared

Debug log
curl fails with an error error:04FFF085:rsa routines:CRYPTO_internal:first octet invalid ssh doesn't show any error, just fails accepting the public key and goes on with other auth methods

I'm providing ssh -vvv and curl -vvv logs. I'll need your guidance for more information and how to help debugging this.

utm-ssh-log.txt utm-curl-log.txt

[azric]

Same problem with curl - which also breaks "dnf update".
My Configuration:

• UTM Version: 4.1.5
• macOS Version: 13.1
• Mac Chip (Intel, M1, ...): M1
• Networking of the VM is shared

[azric]

Changed network to Bridged - same error with curl - curl: (35) error:0200008A:rsa routines::invalid padding

[CodingMinds]

Same here.

• UTM Version 4.1.5 (74)
• macOS Version: 13.1 (22C65)
• Mach Chip: M1
• Network mode: Emulated VLAN
• Architecture: x86_64
• System: Standard PC (q35)
• CPU: All supported features enabled (max)
• Forced multicore

[CodingMinds]

@azric / @GregOriol : I've switched the CPU to qemu64-v1 which seems to "fix" the issue. Maybe you'd like to try this as well.

[GregOriol]

@CodingMinds That seems to "fix" it indeed

[normalcoder]

Also found that the following CPUs works fine: Default, Denverton, and all versions of Haswell, Nehalem, IvyBridge, SandyBridge.

And all other CPUs have this error.

M1, UTM Version 4.1.5 (75), shared net.

tried to run curl and wget with https and got these errors: curl: (35) error:0A00007B:SSL routines::bad signature curl: (35) error:0200008A:rsa routines::invalid padding

[normalcoder]

it's reproduced in UTM Version 4.1.3 but not in 4.1.2 so guess the bug is appeared in qemu v7.2.0

it seems, qemu already have this issue: https://gitlab.com/qemu-project/qemu/-/issues/1471

[kristiandupont]

So I think I am experiencing this problem, except reverting to 4.1.2 didn't work and neither does changing system to virt-7.1. I am on an M1 Macbook and I'm trying to run an ARM Linux.

[GregOriol]

it seems, qemu already have this issue: https://gitlab.com/qemu-project/qemu/-/issues/1471

It looks like it will be fixed in qemu 8.0

[wzzrd]

This is still problematic for me on UTM 4.2.5. Anyone else still seeing this?

Edit: switching to qemu64-v1 doesn't work for EL9, because qemu64-v1 doesn't support qemu-x86_64-v2, from what I can see.

[wzzrd]

The 4.3.0 beta includes qemu 8 and makes this problem go away for me.

[ezrizhu]

This seems related, please let me know if I should make a separate issue, or if this should be on the QEMU ML, or if it's a nonissue.

UTM Ver utm-beta 4.4.5

Host Mac14,2 macOS 14.2.1 23C71 arm64 M2 CPU

Guest CPU: Enables all features supported by the accelerator in the current host (max) lscpu in guest: https://paste.debian.net/1304871/ Debian 12 3.0.11-1~deb12u2 amd64

$ openssl genrsa -out aaa.key 2048
Error generating RSA key 40073529347F0000:error:01800079:bignum routines:ossl_bn_rsa_filps186_4_derive_prime:no prime candidate:../crypto/bn/bn_rsa_flips186_4.c:353:

(https also fails via certificate signature failure)

kernel printk=8 doesn't show anything

Workaround: switching to qemu64 CPU

[chauhanmkk]

For ubuntu x86 amd, changing cpu to qemu64 is working ... Thanks @CodingMinds