Messages

That won't survive a reboot, IIRC.

It does indeed survive a reboot.

It is possible that you encounter the following:

OPNsense 25.1 released

I don't think so, I have 4 installations with OPNsense 25.1.4_1-amd64 and only one of them is exhibiting the problem.

All of the users are non-admin accounts with a shell configured so they can be used as a jump host.

The UI renders fine, but adding or removing group membership has no effect.

As a workaround, I've just added the user to the unix group manually like so `sudo pw group mod ssh -m <username>`

Hi,

I have just discovered a small bug regarding user group membership:

When editing a user in the UI, adding or removing a user from a group no longer updates the unix group membership.

Bug seen on OPNsense 25.1.4_1-amd64

--
Best regards,
David Jack Wange Olrik

Some further digging has found a workaround and a probable cause.

When running the uploader manually, it stops and asks for confirmation, and answering yes here lets it cache the host keys correctly and any subsequent upload now works.

Code Select Expand


$ sudo ./upload_sftp.php --log --host=host.behind.jump.host --port=22 --identity-type=ed25519 --user=user test-connection
INFO: Logging to stdout enabled
INFO: No host key specified, using existing known_hosts entry for 'host.behind.jump.host'
The authenticity of host '[192.168.1.5]:22 (<no hostip for proxy command>)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
No matching host key fingerprint found in DNS.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
INFO: SFTP: Warning: Permanently added '[192.168.1.5]:22' (ED25519) to the list of known hosts.
INFO: SFTP: Connected to host.behind.jump.host.
INFO: SFTP: sftp> pwd
INFO: SFTP: sftp> ls -la
INFO: SFTP: sftp> put '/tmp/sftp-upload-4PBEJw' 'sftp-upload-4PBEJw'
INFO: SFTP: Uploading /tmp/sftp-upload-4PBEJw to /home/user/sftp-upload-4PBEJw
INFO: SFTP: sftp> rm '/home/user/sftp-upload-4PBEJw'
INFO: SFTP: Removing /home/user/sftp-upload-4PBEJw
INFO: SFTP: sftp> exit


My "host.behind.jump.host" host has no public dns name, and is only known in the ssh config, and behind the jumphost.

Hi,

I'm trying to make a acme-client automation that sftp's a cert to a ubuntu box via a jump host.

sftp works on the command line like so:

Code Select Expand

sudo -u root sftp -F /var/etc/acme-client/sftp-config/config user@host.behind.jump.host

I've configured ssh in /var/etc/acme-client/sftp-config/config and it seems to pickup my config, but I get a connection refused in the web ui like so:

Code Select Expand


Failed to connect to host.
{ "actions": [ "connecting" ], "success": false, "connection_closed": true, "error": "Connection closed.", "connect_failed": true }


My ssh config looks like this:

Code Select Expand


Host jump.host
    User user
    Port 22
    HostName <ip>
    HostKeyAlias jump.host
    IdentitiesOnly yes
    IdentityFile /var/etc/acme-client/sftp-config/id.ed25519
    PasswordAuthentication no

Host host.behind.jump.host
    User user
    Port 22
    HostName <private-ip>
    ProxyJump jump.host
    IdentityFile /var/etc/acme-client/sftp-config/id.ed25519


To me it seems that the web-ui is running as some user that isn't root.

Any hints would be much appriciated!

Updated to 2.7.1, and the problem is still there.

I waited several hours, as I started the upgrade just before leaving work and only started looking into what went wrong when the kids complained about the lack of internet.

And the problem persists - every time I reboot, I have to connect to the console and control+c into single user mode, and then exit to complete the boot sequence.

Hi,

I Just updated to 20.7, and after reboot it just hangs. Hardware is a Deciso A10.

I can connect a console cable and press control+c to go into single user mode and then exit single user mode, after which it boots as normal.

Code Select Expand


ugen4.1: <AMD EHCI root HUB> at usbus4
ugen1.1: <AMD OHCI root HUB> at usbus1
uhub0: <AMD EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus4
ugen3.1: <AMD OHCI root HUB> at usbus3
ugen2.1: <AMD EHCI root HUB> at usbus2
ugen0.1: <0x1022 XHCI root HUB> at usbus0
uhub1: <AMD OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
uhub2: <AMD EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus2
uhub3: <AMD OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus3
uhub4: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <TS128GSSD370S N1126KB> ACS-2 ATA SATA 3.x device
ada0: Serial Number C434162910
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 1024bytes)
ada0: Command Queueing enabled
ada0: 122104MB (250069680 512 byte sectors)
Trying to mount root from ufs:/dev/ufs/opnsense [rw,noatime]...
arc4random: no preloaded entropy cache
random: unblocking device.
uhub1: 4 ports with 4 removable, self powered
uhub3: 4 ports with 4 removable, self powered
uhub4: 4 ports with 4 removable, self powered
uhub0: 4 ports with 4 removable, self powered
uhub2: 4 ports with 4 removable, self powered

^C  <---- It hangs here.

2020-07-31T18:48:07.190743+02:00  init 1 - - /bin/sh on /etc/rc terminated abnormally, going to single user mode
Enter full pathname of shell or RETURN for /bin/sh:
#
# ^DMounting filesystems...
tunefs: soft updates remains unchanged as enabled
tunefs: file system reloaded
tunefs: issue TRIM to the disk remains unchanged as enabled
tunefs: file system reloaded
** /dev/ufs/opnsense
FILE SYSTEM CLEAN; SKIPPING CHECKS
clean, 54392121 free (21961 frags, 6796270 blocks, 0.0% fragmentation)
Setting hostuuid: 25368743-50b4-11e8-98b5-f490ea10068b.
Setting hostid: 0x9b4894a0.
Configuring syscons: blanktime.
Configuring crash dump device: /dev/null
swapon: /dev/ufs/swap: No such file or directory
.ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/ipsec /usr/local/lib/mysql /usr/local/lib/perl5/5.30/mach/CORE
32-bit compatibility ldconfig path: /usr/lib32
done.
>>> Invoking early script 'update'
>>> Invoking early script 'configd'
Starting configd.
>>> Invoking early script 'templates'
Generating configuration: OK
>>> Invoking early script 'backup'
>>> Invoking backup script 'captiveportal'
>>> Invoking backup script 'dhcpleases'


If I reboot again, it hangs the at the same place.

Awesome!

Quick question:

If the backend is detached, why is there a warning about "don't navigate away from this page when the upgrade is running" ?

When upgrading to 16.1.13 the upgrade appeared to stop just after "Updating /etc/shells".

On the console in the browser there were a single error:

Code Select Expand

https://my-opnsense.tld/api/core/firmware/upgradestatus Failed to load resource: the server responded with a status of 404 (Not Found)

Looking at processes on the box itself showed no "upgrade" processes, indicating it was finished.

Hitting https://yoda.grepmasters.net/api/core/firmware/upgradestatus manually works and the status in the json is "done".

I'm guessing the api was offline for a split second where my browser requested the upgradestatus.