Releases: ovh/the-bastion
v3.23.01
⚡ Security
- No security fixes since previous release
- Oldest release with no known security issue is
v3.22.00(2025-09-17)
💡 Highlights
This minor release mainly fixes an issue where a preexisting bastion group would have reserved a GID that you expected to allow to a future account.
This is only of importance if you're using fixed UIDs to create accounts, and can't let the system pick the UIDs itself, for example because these UIDs are referenced in some other system of your company.
This change applies a GID shifting to all the bastion groups to ensure they can never take a GID that would pertain to a later-to-be-created account with a fixed UID/GID.
This shift amount is configurable in bastion.conf as groupGidMin (500000 by default).
Use the updated :file:bin/admin/fix-group-gid.sh script to shift any preexisting group GID that would be out of the new groupGidMin range.
We also get our usual round of fixes and enhancements, listed below.
for an exhaustive (and boring) list, please refer to the commit log.
📌 Changes
- feat: accept
-las an additional alias to specify the username (mimickingssh's option) - enh: better interaction between systemd units and /home encryption
- fix: add
groupGidMinto avoid stealing an account's GID - fix: missing
-regexfollowing @cdbd6c7 from #550 - chore: deprecate the use of -f and -l in selfListIngressKeys
⏩ Upgrading
v3.23.00
⚡ Security
- No security fixes since previous release
- Oldest release with no known security issue is
v3.22.00(2025-09-17)
💡 Highlights
This release adds support for more than just GET and POST methods to the HTTPS Proxy, configurable through
osh-http-proxy.conf.
A new feature also adds some quality of life to users of :file:/home-encrypted bastions: the node status can now be
seen directly in the sshd banner, so that they know whether they need to use another node, see the
Specific upgrade instructions
on how to enable it on an already installed bastion.
We also get our usual round of fixes and enhancements, listed below.
for an exhaustive (and boring) list, please refer to the commit log.
📌 Changes
- feat: switch banner if node is sealed
- feat: httpproxy: add support for more HTTP methods (#601)
- feat: add admin script apply-ingress-keys-from-globally.pl (#604)
- enh: allow colon in remote user names (#602)
- fix: scp: more robust parsing for remote users with special chars (#600)
- fix: debian 13 uses lastlog2 (#590)
- fix: hide mfa info msg in quiet mode (#598)
- fix:
accountInfo: correctly return info when PIV grace period is set (#594)
⏩ Upgrading
v3.22.00
⚡ Security
- Security fix for CVE-2025-59339 (Scored 4.4 with CVSS v3)
💡 Highlights
This release fixes the lack of GPG signature of ttyrec files when using the osh-encrypt-rsync script (see CVE above).
Thanks to @siv0 for the responsible disclosure!
Most of the other changes are fixes around the HTTPS Proxy and enhancements to the setup helper scripts,
adding more checks to ensure they behave correctly even when the system is not in the suspected state.
If you've been using the docker sandbox, modifying the container image and committing it to a remote registry,
you may have noticed that The Bastion was not behaving correctly in some cases, such as ACLKeepers of a group
were not able to run ACLKeepers commands if they were not also members of the same group.
This is due to the fact that filesystem-level ACLs are silently dropped in a container image pushed to a registry,
so when you pull this image back from the registry, this information is lacking, and as The Bastion is relying
on the OS DAC in addition to the system group membership to secure sensitive modifications by accounts, they were
in effect losing some of their privileges. This has been fixed by re-applying the filesystem-level ACLs on the
sandbox container start.
A more complete list of changes can be found below,
for an exhaustive (and boring) list, please refer to the commit log.
📌 Changes
- feat: httpproxy: craft the
Hostheader on the egress request (#564) - fix: httpproxy: duplicate
X-Bastion-Local-Statusheaders in some cases - fix:
osh-encrypt-rsync: sign files when encrypting (fixes CVE-2025-59339) - fix: docker sandbox: re-apply filesystem ACLs on start
- fix: add checks and make setup helper scripts more idempotent
- doc: added a few FAQ entries
⏩ Upgrading
v3.21.00
⚡ Security
- No security fixes since previous release
- Oldest release with no known security issue is
v3.14.15(2023-11-08)
💡 Highlights
This release drops official support for Debian 10, whose LTS support has ended in June 2024.
We now support the new Debian 13 stable (Trixie), and as a side effect, compatibility with other untested Linux distributions
using OpenSSH >= 10.0 should also be better.
We took this opportunity to clean up compatibility code for long unsupported systems (such as NetBSD, OpenBSD), and enhance
support for FreeBSD, particularly (but not exclusively) on satellite cron scripts.
A few bugs were also squished: a more complete list of changes can be found below,
for an exhaustive (and boring) list, please refer to the commit log.
📌 Changes
- chg: deprecate Debian 10, support Debian 13 (Trixie)
- enh: scp: add more scp options to the wrapper
- fix: FreeBSD: add missing package for interactive mode (close #548)
- fix: better FreeBSD compatibility for cron scripts (#550)
- fix:
groupAddServer: don't ignore --force-key (close #561) - fix: logic error validating idle(Lock|Kill)Timeout config values (close #549)
- fix: ping max deadline is 3600 on FreeBSD (close #547)
- fix: recent versions of sshd have a separate sshd-session $0
- fix: remove tests for DSA keys, compiled out of recent OpenSSH versions
- fix: scp/sftp: handle case where TMPDIR is mounted in noexec (#569)
- fix: sftp wrapper: handle -P properly (close #553)
- fix: supported key algorithms detection for OpenSSH >= 10
- fix: tests: better detect faulty modules syntax
- fix: tests: FreeBSD: proper reload of recent sshd
- fix: tests: more robust sshd reloading across OSes
- fix: tests: remove support for MD5 fingerprints
⏩ Upgrading
v3.20.00
⚡ Security
- No security fixes since previous release
- Oldest release with no known security issue is
v3.14.15(2023-11-08)
💡 Highlights
This release drops official support for Ubuntu 18.04. Consequently, we upped the minimum required version of Perl to v5.26 (released in 2017).
The main change is the support of arbitrary binary data passed through the HTTPS proxy, hence if you use it, restarting the daemon after the upgrade is important.
A more complete list of changes can be found below, for an exhaustive (and boring) list, please refer to the commit log.
📌 Changes
- chg: deprecate Ubuntu 18.04, up required perl version to v5.26
- enh: ensure JSON streams are purely us-ascii
- fix: httpproxy: allow binary data to be passed through unmodified
- chore: dockerhub: remove i386 build, no longer supported by yubico-piv-checker builds
- chore: fix yubico-piv-checker package name since 1.0.2
- chore: workflows: allow manual launch of distro tests
⏩ Upgrading
v3.19.01
⚡ Security
- No security fixes since previous release
- Oldest release with no known security issue is
v3.14.15(2023-11-08)
💡 Highlights
This release adds the possibility to allow plain HTTP on the egress side of the bastion HTTPS proxy.
Of course, this feature is disabled by default, and you must allow it explicitly if your business constraints force you to. To this effect, you may specify the allowed_egress_protocols option of the osh-http-proxy.conf file.
A more complete list of changes can be found below, for an exhaustive (and boring) list, please refer to the commit log.
📌 Changes
- feat: httpproxy: optional support for plain http on egress
- fix: selfPlaySession: warn in syslog properly
- chore: github actions: replace ubuntu 20.04 by 24.04 (EOL)
⏩ Upgrading
v3.19.00
⚡ Security
- No security fixes since previous release
- Oldest release with no known security issue is
v3.14.15(2023-11-08)
💡 Highlights
Will 2025 be the year of IPv6? Let's not try to answer this controversial question and just say that the main change of this release is drum roll the official support of IPv6!
Most of the code was already IPv6-aware, but in some places IPv4 was assumed so these all have been adjusted to work with both IP versions.
Note that by default, IPv6 support is disabled, we've introduced the IPv6Allowed boolean option in bastion.conf that you must set to true to allow egress connections in IPv6. We've also taken this opportunity to add an IPv4Allowed option, which is enabled by default, you can set it to false should you want to have a strictly IPv6-only bastion!
The characters dictionary used by selfGeneratePassword and groupGeneratePassword has been reduced to only contain special characters recognized by the TL1 protocol, as some network devices only allow these. As this functionaly (SSH password autologin) is mainly aimed at network devices that don't support SSH keys, this has been deemed as a sane default to ensure proper compatibility. Note that this reduces the entropy of generated passwords a bit, but adding one or two characters to the password length is enough to compensate, should it be a concern in your environment.
We've also taken this opportunity to make a few other changes, such as:
- speeding up the
is_valid_ipcheck (35% speedup, noticeable for groups with thousands of ACLs) - set
ECDSAas the default algorithm for generated egress keys instead of RSA, for new installs only (defaultAccountEgressKeyAlgorithm)
Some work has also been done around the unit tests (using the more standard TAP::Harness) and functional tests (speeding them up).
A more complete list of changes can be found below, for an exhaustive (and boring) list, please refer to the commit log.
📌 Changes
- feat: IPv6 support
- feat: add agent forwarding support on egress side
- chg: set ECDSA as default egress key algo for new installs
- chg:
groupInfo: remove deprecated JSON fields - chg: upgrade tests from FreeBSD 13.2 to 14.2
- enh: 35% faster
is_valid_ip()when fast=1 - enh:
accountInfo: add osh-only information for accounts - enh: tests: add
--skip-functional-testsand--skip-unit-tests - enh: ssh autologin: allow TERM env passthrough
- enh: use only TL1 special chars when generating passwords
- fix:
accountInfo: don't attempt (and fail) to display info non-auditors don't have access to - fix:
groupInfo: don't attempt to (and fail) display the guest list when account doesn't have access to it - fix: deny subnets for
nc,mtr,ping,aliveplugins - fix: is_in_any_net: support matching subnets
- fix:
groupSetServers: don't ignore ACL comments - chore: faster tests by removing grant/revoke command dance
- chore: tests: no longer run consistency check by default
- chore: use proper naming of 'subnet' instead of 'prefix' or 'slash'
- chore: use
TAP::Harnessfor unit tests
⏩ Upgrading
v3.18.99-rc1
⚡ Security
- No security fixes since previous release
- Oldest release with no known security issue is
v3.14.15(2023-11-08)
💡 Highlights
Will 2025 be the year of IPv6? Let's not try to answer this controversial question and just say that the main change of this pre-release is drum roll the official support of IPv6!
Most of the code was already IPv6-aware, but in some places IPv4 was assumed so these all have been adjusted to work with both IP versions.
Note that by default, IPv6 support is disabled, we've introduced the IPv6Allowed boolean option in bastion.conf that you must set to true to allow egress connections in IPv6. We've also taken this opportunity to add an IPv4Allowed option, which is enabled by default, you can set it to false should you want to have a strictly IPv6-only bastion!
A lot of tests have been added to ensure everything works correctly with this change, but as this is still an important change, and only a few tests have been done in-the-field yet, this'll be a pre-release for a few weeks.
We've also taken this opportunity to make a few other changes, such as:
- speeding up the
is_valid_ipcheck (35% speedup, noticeable for groups with thousands of ACLs) - set
ECDSAas the default algorithm for generated egress keys instead of RSA, for new installs only (defaultAccountEgressKeyAlgorithm)
Some work has also been done around the unit tests (using the more standard TAP::Harness) and functional tests (speeding them up).
A more complete list of changes can be found below, for an exhaustive (and boring) list, please refer to the commit log.
📌 Changes
- feat: IPv6 support
- chg: set ECDSA as default egress key algo for new installs
- chg:
groupInfo: remove deprecated JSON fields - enh: 35% faster
is_valid_ip()when fast=1 - enh:
accountInfo: add osh-only information for accounts - enh: tests: add
--skip-functional-testsand--skip-unit-tests - fix:
accountInfo: don't attempt (and fail) to display info non-auditors don't have access to - fix:
groupInfo: don't attempt to (and fail) display the guest list when account doesn't have access to it - fix: deny subnets for
nc,mtr,ping,aliveplugins - fix: is_in_any_net: support matching subnets
- chore: faster tests by removing grant/revoke command dance
- chore: tests: no longer run consistency check by default
- chore: use proper naming of 'subnet' instead of 'prefix' or 'slash'
- chore: use
TAP::Harnessfor unit tests
⏩ Upgrading
v3.18.00
⚡ Security
- No security fixes since previous release
- Oldest release with no known security issue is
v3.14.15(2023-11-08)
💡 Highlights
A new restricted command has been added: assetForgetHostKey, which is the bastion-wide version of the selfForgetHostKey command. In other words, it removes a given asset's hostkey from all the bastion accounts' personal known_hosts file. This is particularely useful when a given asset is reinstalled or its IP is being reallocated, and you've left the bastion-wide default of StrictHostKeyChecking to 'ask': in that case, if this command is not used after the asset hostkeys have changed, each account will have to use selfForgetHostKey on their own, to tell the bastion that the previously known hostkey should be forgotten.
This new command makes it possible to sync the reinstallation of an asset with a bastion-wide reset of its hostkeys (e.g. using an automation account that will be granted the use of the assetForgetHostKey command), without requiring all the other accounts to do it on their own. On their next connection, the other accounts will just have to accept the new hostkey (if StrictHostKeyChecking is set to ask, which is the default), or the new hostkey will be auto-accepted in the absence of a known one (if StrictHostKeyChecking is set to accept-new).
A long-standing but has also been fixed with stalling downloads using scp (#486).
The list of changes can be found below, for an exhaustive (and boring) list, please refer to the commit log.
📌 Changes
- feat: add assetForgetHostKey
- fix: scp: downloads would sometimes stall (fix #486)
⏩ Upgrading
v3.17.01
⚡ Security
- No security fixes since previous release
- Oldest release with no known security issue is
v3.14.15(2023-11-08)
💡 Highlights
No specific highlight, as this release addresses a few issues and minor enhancements.
A more complete list of changes can be found below, for an exhaustive (and boring) list, please refer to the commit log.
📌 Changes
- enh: interactive: handle CTRL+C nicely (fix #497)
- fix: osh.pl: remove a warning on interactive mode timeout
- fix: allow ssh-as in connect.pl
- chore: fix bad scpup/scpupload scp/scpdownload references in help and doc (thanks @TomRicci!)