select() to poll() by moving FD_SET construction out of channel handlers into
separate functions. ok markus
OpenBSD-Commit-ID: 937fbf2a4de12b19fb9d5168424e206124807027
already supported either sha512 (default) or sha256, but plumbing wasn't
there mostly by Linus Nordberg
OpenBSD-Commit-ID: 1b536404b9da74a84b3a1c8d0b05fd564cdc96cd
allowed_signers line that contains a namespace restriction, but no
restriction specified on the command-line; report and fix from Fabian Stelzer
OpenBSD-Commit-ID: 4a201b86afb668c908d1a559c6af456a61f4b145
one supposedly being tested. Spotted by dtucker and using his VM zoo (which
includes some systems old enough to lack ed25519 key support)
OpenBSD-Regress-ID: 7976eb3df11cc2ca3af91030a6a8c0cef1590bb5
authmethod_lookup() into a separate authmethod_byname(), for cases where we
don't need to check whether a method is enabled, etc.
use this to fix the "none" authentication method regression reported
by Nam Nguyen via bugs@
ok deraadt@
OpenBSD-Commit-ID: 8cd188dc3a83aa8abe5b7693e762975cd8ea8a17
If the platform has a native SHA2, does not define SHA.*_BLOCK_LENGTH
but does define SHA.*_HMAC_BLOCK_SIZE (eg Solaris) then use the latter.
Should fix --without-openssl build on Solaris.
Allow control over which pubkey methods are used. Added out of
concern that some hardware devices may have difficulty signing
the longer pubkey authentication challenges. This provides a
way for them to disable the extension. It's also handy for
testing.
feedback / ok markus@
OpenBSD-Commit-ID: ee52580db95c355cf6d563ba89974c210e603b1a
Require host-bound userauth requests for forwarded SSH connections.
The hostkey parsed from the host-bound userauth request is now checked
against the most recently bound session ID / hostkey on the agent socket
and the signature refused if they do not match.
ok markus@
OpenBSD-Commit-ID: d69877c9a3bd8d1189a5dbdeceefa432044dae02
Allow parse_userauth_request() to work with blobs from
publickey-hostbound-v00@openssh.com userauth attempts.
Extract hostkey from these blobs.
ok markus@
OpenBSD-Commit-ID: 81c064255634c1109477dc65c3e983581d336df8
the EXT_INFO packet gets a new publickey-hostbound@openssh.com to
advertise the hostbound public key method.
Client side support to parse this feature flag and set the kex->flags
indicator if the expected version is offered (currently "0").
ok markus@
OpenBSD-Commit-ID: 4cdb2ca5017ec1ed7a9d33bda95c1d6a97b583b0
Add kex->flags member to enable the publickey-hostbound-v00@openssh.com
authentication method.
Use the new hostbound method in client if the kex->flags flag was set,
and include the inital KEX hostkey in the userauth request.
Note: nothing in kex.c actually sets the new flag yet
ok markus@
OpenBSD-Commit-ID: 5a6fce8c6c8a77a80ee1526dc467d91036a5910d
This is identical to the standard "publickey" method, but it also includes
the initial server hostkey in the message signed by the client.
feedback / ok markus@
OpenBSD-Commit-ID: 7ea01bb7238a560c1bfb426fda0c10a8aac07862
allow authentication methods to have one additional name beyond their
primary name.
allow lookup by this synonym
Use primary name for authentication decisions, e.g. for
PermitRootLogin=publickey
Pass actual invoked name to the authmethods, so they can tell whether they
were requested via the their primary name or synonym.
ok markus@
OpenBSD-Commit-ID: 9e613fcb44b8168823195602ed3d09ffd7994559
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.
feedback Jann Horn & markus@
ok markus@
OpenBSD-Commit-ID: 84a7fb81106c2d609a6ac17469436df16d196319
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.
feedback Jann Horn & markus@
ok markus@
OpenBSD-Commit-ID: 6b52cd2b637f3d29ef543f0ce532a2bce6d86af5
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.
feedback Jann Horn & markus@
ok markus@
OpenBSD-Commit-ID: ef47fa9ec0e3c2a82e30d37ef616e245df73163e
record session ID/hostkey/forwarding status for each active socket.
Attempt to parse data-to-be-signed at signature request time and extract
session ID from the blob if it is a pubkey userauth request.
ok markus@
OpenBSD-Commit-ID: a80fd41e292b18b67508362129e9fed549abd318
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.
ok markus@
OpenBSD-Commit-ID: 2f154844fe13167d3ab063f830d7455fcaa99135
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.
Motivated by bz3366; by Pedro Martelletto
OpenBSD-Commit-ID: ffac7f3215842397800e1ae2e20229671a55a63d
djm@openbsd.org
dtucker@openbsd.org
Darren Tucker
jsg@openbsd.org
jmc@openbsd.org
Damien Miller
anton@openbsd.org
deraadt@openbsd.org
naddy@openbsd.org