djm@openbsd.org [Sun, 19 Dec 2021 22:11:39 +0000 (22:11 +0000)]
upstream: ssh-agent side of destination constraints
Gives ssh-agent the ability to parse restrict-destination-v00@openssh.com
constraints and to apply them to keys.
Check constraints against the hostkeys recorded for a SocketEntry when
attempting a signature, adding, listing or deleting keys. Note that
the "delete all keys" request will remove constrained keys regardless of
location.
djm@openbsd.org [Sun, 19 Dec 2021 22:11:06 +0000 (22:11 +0000)]
upstream: ssh-add side of destination constraints
Have ssh-add accept a list of "destination constraints" that allow
restricting where keys may be used in conjunction with a ssh-agent/ssh
that supports session ID/hostkey binding.
Constraints are specified as either "[user@]host-pattern" or
"host-pattern>[user@]host-pattern".
The first form permits a key to be used to authenticate as the
specified user to the specified host.
The second form permits a key that has previously been permitted
for use at a host to be available via a forwarded agent to an
additional host.
For example, constraining a key with "user1@host_a" and
"host_a>host_b". Would permit authentication as "user1" at
"host_a", and allow the key to be available on an agent forwarded
to "host_a" only for authentication to "host_b". The key would not
be visible on agent forwarded to other hosts or usable for
authentication there.
Internally, destination constraints use host keys to identify hosts.
The host patterns are used to obtain lists of host keys for that
destination that are communicated to the agent. The user/hostkeys are
encoded using a new restrict-destination-v00@openssh.com key
constraint.
host keys are looked up in the default client user/system known_hosts
files. It is possible to override this set on the command-line.
djm@openbsd.org [Sun, 19 Dec 2021 22:10:24 +0000 (22:10 +0000)]
upstream: ssh-add side of destination constraints
Have ssh-add accept a list of "destination constraints" that allow
restricting where keys may be used in conjunction with a ssh-agent/ssh
that supports session ID/hostkey binding.
Constraints are specified as either "[user@]host-pattern" or
"host-pattern>[user@]host-pattern".
The first form permits a key to be used to authenticate as the
specified user to the specified host.
The second form permits a key that has previously been permitted
for use at a host to be available via a forwarded agent to an
additional host.
For example, constraining a key with "user1@host_a" and
"host_a>host_b". Would permit authentication as "user1" at
"host_a", and allow the key to be available on an agent forwarded
to "host_a" only for authentication to "host_b". The key would not
be visible on agent forwarded to other hosts or usable for
authentication there.
Internally, destination constraints use host keys to identify hosts.
The host patterns are used to obtain lists of host keys for that
destination that are communicated to the agent. The user/hostkeys are
encoded using a new restrict-destination-v00@openssh.com key
constraint.
host keys are looked up in the default client user/system known_hosts
files. It is possible to override this set on the command-line.
djm@openbsd.org [Sun, 19 Dec 2021 22:08:48 +0000 (22:08 +0000)]
upstream: ssh client side of binding
send session ID, hostkey, signature and a flag indicating whether the
agent connection is being forwarded to ssh agent each time a connection
is opened via a new "session-bind@openssh.com" agent extension.
djm@openbsd.org [Thu, 2 Dec 2021 23:23:13 +0000 (23:23 +0000)]
upstream: improve the testing of credentials against inserted FIDO
keys a little more: ask the token whether a particular key belongs to it in
cases where the token support on-token user- verification (e.g. biometrics)
rather than just assuming that it will accept it.
Will reduce spurious "Confirm user presence" notifications for key
handles that relate to FIDO keys that are not currently inserted in at
least some cases.
Darren Tucker [Fri, 19 Nov 2021 05:01:51 +0000 (16:01 +1100)]
Don't auto-enable Capsicum sandbox on FreeBSD 9/10.
Since we changed from select() to ppoll() tests have been failing.
This seems to be because FreeBSD 10 (and presumably 9) do not allow
ppoll() in the privsep process and sshd will fail with "Not permitted in
capability mode". Setting CAP_EVENT on the FDs doesn't help, but weirdly,
poll() works without that. Those versions are EOL so this situation is
unlikely to change.
Damien Miller [Wed, 17 Nov 2021 23:16:55 +0000 (10:16 +1100)]
adjust seccomp filter for select->poll conversion
Needed to add ppoll syscall but also to relax the fallback rlimit
sandbox. Linux poll() fails with EINVAL if npfds > RLIMIT_NOFILE,
so we have to allow a single fd in the rlimit.
Darren Tucker [Fri, 12 Nov 2021 11:55:27 +0000 (22:55 +1100)]
Switch from LibreSSL 3.4.0 to 3.4.1.
The LibreSSL 3.4.0 release has an OPENBSD_BRANCH that points to
"master" and that branch no longer has the files LibreSSL expects
and thus it will no longer build, breaking the test.
Darren Tucker [Wed, 10 Nov 2021 01:34:25 +0000 (12:34 +1100)]
Don't trust closefrom() on Linux.
glibc's closefrom implementation does not work in a chroot when the kernel
does not have close_range. It tries to read from /proc/self/fd and when
that fails dies with an assertion of sorts. Instead, call close_range
ourselves from our compat code and fall back if that fails. bz#3349,
with william.wilson at canonical.com and fweimer at redhat.com.
Darren Tucker [Sat, 6 Nov 2021 10:07:03 +0000 (21:07 +1100)]
Skip getline() on HP-UX 10.x.
HP-UX 10.x has a getline() implementation in libc that does not behave
as we expect so don't use it. With correction from Thorsten Glaser and
typo fix from Larkin Nickle.
djm@openbsd.org [Tue, 2 Nov 2021 22:56:40 +0000 (22:56 +0000)]
upstream: Better handle FIDO keys on tokens that provide user
verification (UV) on the device itself, including biometric keys.
Query the token during key creation to determine whether it supports
on-token UV and, if so, clear the SSH_SK_USER_VERIFICATION_REQD flag
in the key so that ssh(1) doesn't automatically prompty for PIN later.
When making signatures with the key, query the token's capabilities
again and check whether the token is able (right now) to perform user-
verification without a PIN. If it is then the PIN prompt is bypassed
and user verification delegated to the token. If not (e.g. the token
is biometric capable, but no biometric are enrolled), then fall back
to user verification via the usual PIN prompt.
djm@openbsd.org [Fri, 29 Oct 2021 03:03:06 +0000 (03:03 +0000)]
upstream: sshsig: add tests for signing key validity and
find-principals
- adds generic find-principals tests (this command had none before)
- tests certs with a timeboxed validity both with and without a
restriced lifetime for the CA
- test for a revoked CA cert
Damien Miller [Thu, 6 May 2021 00:08:30 +0000 (10:08 +1000)]
remove built-in support for md5crypt()
Users of MD5-hashed password should arrange for ./configure to link
against libxcrypt or similar. Though it would be better to avoid use
of MD5 password hashing entirely, it's arguably worse than DEScrypt.
upstream: For open/openat, if the flags parameter does not contain
O_CREAT, the 3rd (variadic) mode_t parameter is irrelevant. Many developers
in the past have passed mode_t (0, 044, 0644, or such), which might lead
future people to copy this broken idiom, and perhaps even believe this
parameter has some meaning or implication or application. Delete them all.
This comes out of a conversation where tb@ noticed that a strange (but
intentional) pledge behaviour is to always knock-out high-bits from mode_t on
a number of system calls as a safety factor, and his bewilderment that this
appeared to be happening against valid modes (at least visually), but no
sorry, they are all irrelevant junk. They could all be 0xdeafbeef. ok
millert
Prevent mem leaks in the (unlikely) event that getaddrinfo returns
no addresses. ALso, remove an unneeded NULL check in addr_ntop. From
khaleesicodes via github PR#281, ok deraadt@
Darren Tucker [Wed, 6 Oct 2021 06:09:31 +0000 (17:09 +1100)]
Define OPENSSL_NO_SHA including OpenSSL from test.
We don't use SHA256 from OpenSSL in the sk-dummy module and the
definitions can conflict with system sha2.h (eg on NetBSD) so define
OPENSSL_NO_SHA so we don't attempt to redefine them.