I'm at a bit of a loss on this one so I thought I'd see if anyone has any other suggestions.
My home network is all Ubiquity UniFi gear. I have a USG-3P router, a few switches and one AP. There is a UniFi controller app that centrally handles the configuration of the devices, including managing SSH access. You enter a public key in the controller software and it distributes it to all the devices automatically. I rarely actually SSH into any of the devices so I don't know when this stopped working but at some point it did work. I have the public keys for my desktop and laptop, both running Fedora 33, in the controller but when I attempt to SSH I am prompted for the UniFi admin password rather than my private key password. I don't get any sort of cipher mismatch or any other error, it just prompts for the account password.
Things I've tried: * Verified permissions on ~/.ssh * I can still SSH into many other hosts and they all accept my RSA key just fine * I removed and re-added the keys in the USG controller * The fingerprint of the keys, as displaying in the controller software, matches the fingerprint in seahorse (Passwords and Keys) * Verified public key auth works to the UniFi gear from several other devices I have, including a Macbook, iPhone, Raspberry Pi, and an Ubuntu VM * I built a fresh Fedora 33 virtual machine, added its public key, and it has the same issue * I verified the keys are actually being copied to the authorized_keys on several different UniFi boxes * Comparing keys to my MacBook, both are RSA and have a length of 3072
Essentially any Fedora box I've tried won't do public key auth to any of the UniFi gear but they all authenticate fine everywhere else, and every non-Fedora device I've tried can authenticate to the UniFi stuff. The UniFi gear doesn't even all run the same OS, the USG runs EdgeOS and has the keys in .ssh/authorized_keys but the switches have a busybox shell and use dropbear for ssh with the keys at /etc/dropbear/authorized_keys
I can just use the password for SSH, it's very rare that I actually have any reason to do it at all, it's just the puzzle that is driving me crazy.
have you googled 'linux ssh how to login without password' ??
On Mon, Apr 26, 2021 at 1:27 PM Kevin Becker kevin@kevinbecker.org wrote:
I'm at a bit of a loss on this one so I thought I'd see if anyone has any other suggestions.
My home network is all Ubiquity UniFi gear. I have a USG-3P router, a few switches and one AP. There is a UniFi controller app that centrally handles the configuration of the devices, including managing SSH access. You enter a public key in the controller software and it distributes it to all the devices automatically. I rarely actually SSH into any of the devices so I don't know when this stopped working but at some point it did work. I have the public keys for my desktop and laptop, both running Fedora 33, in the controller but when I attempt to SSH I am prompted for the UniFi admin password rather than my private key password. I don't get any sort of cipher mismatch or any other error, it just prompts for the account password.
Things I've tried:
- Verified permissions on ~/.ssh
- I can still SSH into many other hosts and they all accept my RSA key
just fine
- I removed and re-added the keys in the USG controller
- The fingerprint of the keys, as displaying in the controller
software, matches the fingerprint in seahorse (Passwords and Keys)
- Verified public key auth works to the UniFi gear from several other
devices I have, including a Macbook, iPhone, Raspberry Pi, and an Ubuntu VM
- I built a fresh Fedora 33 virtual machine, added its public key, and
it has the same issue
- I verified the keys are actually being copied to the authorized_keys
on several different UniFi boxes
- Comparing keys to my MacBook, both are RSA and have a length of 3072
Essentially any Fedora box I've tried won't do public key auth to any of the UniFi gear but they all authenticate fine everywhere else, and every non-Fedora device I've tried can authenticate to the UniFi stuff. The UniFi gear doesn't even all run the same OS, the USG runs EdgeOS and has the keys in .ssh/authorized_keys but the switches have a busybox shell and use dropbear for ssh with the keys at /etc/dropbear/authorized_keys
I can just use the password for SSH, it's very rare that I actually have any reason to do it at all, it's just the puzzle that is driving me crazy.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Apr 26, 2021, at 5:20 PM, Jack Craig jack.craig.aptos@gmail.com wrote:
have you googled 'linux ssh how to login without password' ??
Weirdly that query didn’t return anything specific to Fedora guests (and only Fedora guests) not being able to use public key authentication to a specific subset of hosts while working perfectly fine on other hosts. I’m very familiar with public key authentication. As I stated I can ssh “without a password” from my Fedora computers to multiple different hosts just fine. And I can log in to the unifi gear “without a password” from multiple different machines so long as they are not running Fedora.
It turns out the one thing that had slipped my mind was the updated crypto policy in Fedora 33. Running "update-crypto-policies --set DEFAULT:FEDORA32” solved the issue for now. The next step is to figure out what was deprecated and see if I can override it in my .ssh/config file for the UniFi hosts rather than changing the crypto policy system-wide.
On Apr 26, 2021, at 9:56 PM, Kevin Becker kevin@kevinbecker.org wrote:
It turns out the one thing that had slipped my mind was the updated crypto policy in Fedora 33. Running "update-crypto-policies --set DEFAULT:FEDORA32” solved the issue for now. The next step is to figure out what was deprecated and see if I can override it in my .ssh/config file for the UniFi hosts rather than changing the crypto policy system-wide.
Adding "PubkeyAcceptedKeyTypes +ssh-rsa” to my .ssh/config entries for each of the UniFi hosts has resolved the issue without downgrading the crypto policy system wide.
-
Jack Craig -
Kevin Becker