Damien Miller [Fri, 14 Jun 2024 04:19:23 +0000 (14:19 +1000)]
add a sshd_config PamServiceName option
Allows selecting which PAM service name to use when UsePAM is
enabled. Defaults to "sshd" unless overridden at compile time
by defining SSHD_PAM_SERVICE.
Damien Miller [Thu, 13 Jun 2024 06:41:29 +0000 (16:41 +1000)]
sshd: don't use argv[0] as PAM service name
sshd would implicitly use argv[0] as the PAM service name to
allow people to select different PAM service names by making
differently-named copies/links to the sshd binary.
Splitting sshd into sshd/sshd-session broke this, as the process
that starts PAM is always sshd-session and the user has no control
over this.
Hardcode "sshd" as the default PAM service name unless/until we
figure out a better way. Should unbreak OSX integration tests.
Damien Miller [Thu, 13 Jun 2024 05:00:28 +0000 (15:00 +1000)]
prepare for checking in autogenerated files
We plan to check in automatically generated files (config.h.in, etc) on
release branches. These files are normally ignored by .gitignore, but
this shuffles the contents of this file to make it easy to un-ignore
them.
Damien Miller [Thu, 13 Jun 2024 04:35:25 +0000 (14:35 +1000)]
fix PTY allocation on Cygwin, broken by sshd split
Cygwin doesn't support FD passing and so used to disable post-auth
privilege separation entirely because privsep requires PTY allocation
to happen in the privileged monitor process with the PTY file
descriptors being passed back to the unprivileged process.
This brings back a minimal version of the previous special treatment
for Cygwin (and any other platform that sets DISABLE_FD_PASSING):
privilege separation remains enabled, but PTY allocation happens in
the post-auth user process rather than the monitor.
This either requires PTY allocation to not need privilege to begin
with (this appears to be the case on Cygwin), or the post-auth
privsep process retain privilege (other platforms that set the
DISABLE_FD_PASSING option).
Keeping privileges here is bad, but the non-Cygwin systems that set
DISABLE_FD_PASSING are so deeply legacy that this is likely to be the
least of their problems.
Damien Miller [Thu, 13 Jun 2024 01:33:09 +0000 (11:33 +1000)]
delay lookup of privsep user until config loaded
sshd-session attempting to use options.kerberos_authentication to
decide whether it needed to lookup the privsep user before the
configuration was loaded. This caused it to get a placeholder value
that caused it always to try to lookup the privsep user, breaking at
least one test environment.
djm@openbsd.org [Wed, 12 Jun 2024 22:36:00 +0000 (22:36 +0000)]
upstream: split PerSourcePenalties address tracking. Previously it
used one shared table and overflow policy for IPv4 and IPv6 addresses, now it
will use separate tables and optionally different overflow policies.
This prevents misbehaviour from IPv6 addresses (which are vastly easier
to obtain many of) from affecting IPv4 connections and may allow for
stricter overflow policies.
djm@openbsd.org [Thu, 6 Jun 2024 20:25:48 +0000 (20:25 +0000)]
upstream: enable PerSourcePenalties by default.
ok markus
NB. if you run a sshd that accepts connections from behind large NAT
blocks, proxies or anything else that aggregates many possible users
behind few IP addresses, then this change may cause legitimate traffic
to be denied.
Please read the PerSourcePenalties, PerSourcePenaltyExemptList and
PerSourceNetBlockSize options in sshd_config(5) for how to tune your
sshd(8) for your specific circumstances.
djm@openbsd.org [Thu, 6 Jun 2024 17:15:25 +0000 (17:15 +0000)]
upstream: Add a facility to sshd(8) to penalise particular
problematic client behaviours, controlled by two new sshd_config(5) options:
PerSourcePenalties and PerSourcePenaltyExemptList.
When PerSourcePenalties are enabled, sshd(8) will monitor the exit
status of its child pre-auth session processes. Through the exit
status, it can observe situations where the session did not
authenticate as expected. These conditions include when the client
repeatedly attempted authentication unsucessfully (possibly indicating
an attack against one or more accounts, e.g. password guessing), or
when client behaviour caused sshd to crash (possibly indicating
attempts to exploit sshd).
When such a condition is observed, sshd will record a penalty of some
duration (e.g. 30 seconds) against the client's address. If this time
is above a minimum threshold specified by the PerSourcePenalties, then
connections from the client address will be refused (along with any
others in the same PerSourceNetBlockSize CIDR range).
Repeated offenses by the same client address will accrue greater
penalties, up to a configurable maximum. A PerSourcePenaltyExemptList
option allows certain address ranges to be exempt from all penalties.
We hope these options will make it significantly more difficult for
attackers to find accounts with weak/guessable passwords or exploit
bugs in sshd(8) itself.
PerSourcePenalties is off by default, but we expect to enable it
automatically in the near future.
djm@openbsd.org [Sat, 1 Jun 2024 07:03:37 +0000 (07:03 +0000)]
upstream: be really strict with fds reserved for communication with the
separate sshd-session process - reserve them early and fatal if we can't
dup2(2) them later. The pre-split fallback to re-reading the configuration
files is not possible, so sshd-session absolutely requires the fd the
configuration is passed over to be in order.
djm@openbsd.org [Fri, 17 May 2024 00:30:23 +0000 (00:30 +0000)]
upstream: Start the process of splitting sshd into separate
binaries. This step splits sshd into a listener and a session binary. More
splits are planned.
After this changes, the listener binary will validate the configuration,
load the hostkeys, listen on port 22 and manage MaxStartups only. All
session handling will be performed by a new sshd-session binary that the
listener fork+execs.
This reduces the listener process to the minimum necessary and sets us
up for future work on the sshd-session binary.
feedback/ok markus@ deraadt@
NB. if you're updating via source, please restart sshd after installing,
otherwise you run the risk of locking yourself out.
upstream: also create a relink kit for ssh-agent, since it is a
long-running setgid program carrying keys with some (not very powerful)
communication channels. solution for testing the binary from dtucker.
agreement from djm. Will add it into /etc/rc in a few days.
upstream: new-style relink kit for sshd. The old scheme created
a Makefile by concatenating two Makefiles and was incredibly fragile. In the
new way a narrow-purposed install.sh script is created and shipped with the
objects. A recently commited /etc/rc script understands these files.
Darren Tucker [Thu, 25 Apr 2024 03:20:19 +0000 (13:20 +1000)]
Merge flags for OpenSSL 3.x versions.
OpenSSL has moved to 3.4 which we don't currently accept. Based on
the OpenSSL versioning policy[0] it looks like all of the 3.x versions
should work with OpenSSH, so remove the distinction in configure and
accept all of them.
Darren Tucker [Sat, 30 Mar 2024 07:20:16 +0000 (18:20 +1100)]
Check if OpenSSL implementation supports DSA.
If --enable/disable-dsa-keys is not specified, set based on what OpenSSL
supports. If specified as enabled, but not supported by OpenSSL error
out. ok djm@