Update SSH Public Key

Stewart

I have multiple pfSense firewalls but they were all built off of clones of each other and then the config modified to match the needs of the site. Now that I'm setting up the auto-backup, they all show the same backup key because it is derived from the SSH public key. How do I update the SSH public key to remedy this?

jimp

You can delete/remove /etc/ssh/ssh_host_*key* and then run /etc/sshd which will generate a new set.

So for example:

: ls /etc/ssh/ssh_host_*key*

Confirm that shows you the key files you want to remove. If so:

: rm /etc/ssh/ssh_host_*key*
: /etc/sshd

sgw

I have exactly the same task to do.
As the pfSenses are remote, I better ask once more: is that safe to do via ssh session?
Or better via WebGUI and the command prompt?

I even consider doing it via ansible, but maybe that is too ambitious.

stephenw10

I had to restart the sshd service via the gui to regenerate the keys. Running /etc/sshd is not permitted in current versions, even when run as root.

However you can restart it at the command line in the php shell:

Enter an option: 12

Starting the Netgate pfSense Plus developer shell....

Welcome to the Netgate pfSense Plus developer shell

Type "help" to show common usage scenarios.

Available playback commands:
     changepassword cryptconfig disablecarp disablecarpmaint disabledhcpd disablereferercheck enableallowallwan enablecarp enablecarpmaint enablesshd externalconfiglocator gatewaystatus generateguicert gitsync installpkg listpkg pfanchordrill pftabledrill removepkgconfig removeshaper resetwebgui restartallwan restartdhcpd restartipsec svc uninstallpkg upgradeconfig 

Netgate pfSense Plus shell: playback svc restart sshd

Playback of file svc started.

Attempting to issue restart to sshd service...

sshd has been restarted.

So you could remove the old keys then exit back to the menu and restart sshd from the php shell. BUT I would want to have remote access to the GUI because one extra press on 'enter' would leave you unable to reconnect via SSH until the service is restarted.

Steve

sgw

@stephenw10 Thank you! I will test that with 2 new appliances later this week: I will have them in my office so that will be less risky.

sgw

This leads me to thinking about how to efficiently handle such deployments with multiple "clones"

So far I export the config.xml from a working box, and edit it a little bit:

for example change the hostname and the LAN-IP/subnet

and I write random stuff over the OpenVPN-client-password to avoid that the cloned box connects via the same tunnel as the first box. I replace the ovpn-config then via the GUI.

I am quite efficient doing this when I have the steps in mind.

Sometimes the appliances are delivered with an older release of pfSense-Plus, so I have to run upgrades first. Might be faster to reinstall from scratch via USB-stick and already provision it with a prepared xml-file.

I have to prepare 10 boxes in the near future and like the thought of optimizing that ;-)

stephenw10

Well you can export the config without the SSH keys to prevent the issue you saw here.

Stewart

Since I'm the OP I thought I'd chime in here. We changed what we do and don't clone anymore. Instead we keep a default config with 90% of the work done and have it import on a brand new install. That config does not contain the SSH keys or RRD data so we don't have to worry about it getting mixed up with other devices. Generally the only things we need to change at that point is the name and the WAN config and anything specific about that install. We leave the WAN to DHCP and plugged in upstream so that the packages reinstall on boot and then change when put in to place.