How do I stop pfSense's SSH identity from changing?
-
I use the CLI around pfSense a lot, mostly to SSH in and run tests from the firewalls' perspective or reinstalling packages without all the click-wait-click-wait-click, it's much faster and doesn't hang up.
I'd like to step it up and notch and have pfSense as the sole source/proxy to ACME, using exported files in
/conf/acme
and have all the servers pull the certs instead of each making additional API calls that could get me banned or something. pfSense already does the whole thing in a single cert for all of my domains+wildcards because of HAProxy, so it makes sense to just reuse them and set a cron job to keep pulling them.I already wrote the script to do the whole thing complete with syncing
.ssh
directories their permissions and manipulating the files so they fall right in place in several Linux servers and macOS Server'System.keychain
(this took a while) so it goes well every time. The problem is that when you first connect over SSH you have to accept the server's identity as known and pfSense seems to randomly change it. I'm not sure if the change is triggered on reboots or timed or after updates and how is it that it can change its identity invoking client warnings when it doesn't match anymore--I've seen this too in ESXi hosts but I've never wanted to find out why there because of the damage potential.Can I lock down whatever it's reading its identity from so it's forever (or a really long time) the same? I don't know how to do interactive answers in a script and, since it'll run with
root
privileges, I'm not sure what happens when it's waiting for an answers, if other elevated processes halt or something else. :/ I think I'll have another server pull them first acting as an intermediary, but even so it doesn't solve the identity changing issue.Thanks !
-
The SSH private is generated when SSH is first enabled after an install. It's not stored in the config so the identity will change across a restore. However it should not change if the firmware is not re-installed. Certainly not randomly across a reboot.
Is it actually a new key you're seeing or some other error when you try to connect?Steve
-
Hi, thanks for answering,
Like I said I'm not sure what triggers it and I don't get errors whatsoever I just the message shown on first connections. It's so weird because the client should warn me it the host is not the same right? But it doesn't.
It's not on every reboot, and I should probably had mentioned pfSense runs on vSphere. I don't know if this is related but I was having this disk error on an Ubuntu Server VM, something similar to that cam-something + series-of-numbers that sometimes appears on FreeBSD, the fix was to set a property on the VM called disk.EnableUUID, it reminded me the FreeBSD cam thing so I powered off pfSense to make an offline clone in case of emergency and set the property there too. I haven't seen any errors so far because of what I did or otherwise--but also this last pfSense box is super fresh, two weeks old at the most and I had a lot of care deploying it.
It also occurred to me that if I push the certs from pfSense instead of pulling them, I can get around it. Back to pfSense though; FreeBSD, as I very little understand, had this thing where the console isn't as almighty as it is in other UNIX-like systems, FreeNAS for instance has a warning that all changes done in console as root will be discarded, like if it was nothing, I've sort of noticed this as well on pfSense, file modifications are kept, public keys are kept too but only for while, these might actually be indeed deleted on reboots, only now I thought of it. I don't know how to think as a dev bc I'm not one--but what I do know is that it feels very container-like when you press 8 to enter the shell, like if reset to a template or something.
I'll start documenting logins to the firewall to see if I can come up with something. In the meantime I got my wildcard-multidomain super certs. :)
Thanks again.
-
The fact the console does not seem all powerful is not a BSD or even FreeBSD thing it's a pfSense and FreeNAS thing. Both OSs use a central single config file that writes out all the required conf files at boot. So if you make some change at the console as though it was vanilla FreeBSD that gets overwritten at boot. pfSense is intended to be GUI driven. A single config file makes backup and restore trivial.
But as I say the ssh keys are not included in that, they are generated on each install when sshd is enabled.
Usually if you re-install a system and it generates new keys ssh will complain when you try to connect because the hostname/IP is known but the key has changed. It will refuse the connection. But you are just seeing it ask you accept the host again?
What are you connecting from?Steve
-
Ugh!
If only I had checked back my email. I found that only until today, well… I found that the system is mounted read-only, fixable (not that is broken) with
mount -uw /
. I thought it was like a FreeBSD jail thing. It's never not amazing the simplicity with which UNIX-like systems solve problems while others just pile bloat on top.On other hand though, attempting to break my system, 'cause that's what I'll do, I ran into another of these:
Another disappeared key. Does it mean I have to install it through the GUI too? I guess we'll see; I just pushed another copy and I'll let proof here even if I'm only talking to myself to come back to it later.
🧩