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
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
Add a ssh_request_reply_decode() function that sends a message to
the agent, reads and parses a success/failure reply.
Use it for all requests that only expect success/failure
ok markus@
OpenBSD-Commit-ID: e0c1f4d5e6cfa525d62581e2b8de93be0cb85adb
While freezero() returns early if the pointer is NULL the tests for
NULL in callers are left to avoid warnings about passing an
uninitialised size argument across a function boundry.
ok deraadt@ djm@
OpenBSD-Commit-ID: 2660fa334fcc7cd05ec74dd99cb036f9ade6384a
specified by $SSH_AUTH_SOCK, by extending the existing ForwardAgent option to
accepting an explicit path or the name of an environment variable in addition
to yes/no.
Patch by Eric Chiang, manpage by me; ok markus@
OpenBSD-Commit-ID: 98f2ed80bf34ea54d8b2ddd19ac14ebbf40e9265
This commit adds a helper function which allows the caller to
check if a given public key is present in ssh-agent.
work by Sebastian Kinne; ok markus@
OpenBSD-Commit-ID: d43c5826353e1fdc1af71eb42961b30782c7bd13
some arbitrary value < 0. errno is only updated in this case. Change all
(most?) callers of syscalls to follow this better, and let's see if this
strictness helps us in the future.
OpenBSD-Commit-ID: 48081f00db7518e3b712a49dca06efc2a5428075
speculation and memory sidechannel attacks like Spectre, Meltdown, Rowhammer
and Rambleed. This change encrypts private keys when they are not in use with
a symmetic key that is derived from a relatively large "prekey" consisting of
random data (currently 16KB).
Attackers must recover the entire prekey with high accuracy before
they can attempt to decrypt the shielded private key, but the current
generation of attacks have bit error rates that, when applied
cumulatively to the entire prekey, make this unlikely.
Implementation-wise, keys are encrypted "shielded" when loaded and then
automatically and transparently unshielded when used for signatures or
when being saved/serialised.
Hopefully we can remove this in a few years time when computer
architecture has become less unsafe.
been in snaps for a bit already; thanks deraadt@
ok dtucker@ deraadt@
OpenBSD-Commit-ID: 19767213c312e46f94b303a512ef8e9218a39bd4
In ssh, when an agent fails to return a RSA-SHA2 signature when
requested and falls back to RSA-SHA1 instead, retry the signature to
ensure that the public key algorithm sent in the SSH_MSG_USERAUTH
matches the one in the signature itself.
In sshd, strictly enforce that the public key algorithm sent in the
SSH_MSG_USERAUTH message matches what appears in the signature.
Make the sshd_config PubkeyAcceptedKeyTypes and
HostbasedAcceptedKeyTypes options control accepted signature algorithms
(previously they selected supported key types). This allows these
options to ban RSA-SHA1 in favour of RSA-SHA2.
Add new signature algorithms "rsa-sha2-256-cert-v01@openssh.com" and
"rsa-sha2-512-cert-v01@openssh.com" to force use of RSA-SHA2 signatures
with certificate keys.
feedback and ok markus@
OpenBSD-Commit-ID: c6e9f6d45eed8962ad502d315d7eaef32c419dde
Drop compatibility hacks for some ancient SSH
implementations, including ssh.com <=2.* and OpenSSH <= 3.*.
These versions were all released in or before 2001 and predate the
final SSH RFCs. The hacks in question aren't necessary for RFC-
compliant SSH implementations.
ok markus@
OpenBSD-Commit-ID: 4be81c67db57647f907f4e881fb9341448606138
remove post-SSHv1 removal dead code from rsa.c and merge
the remaining bit that it still used into ssh-rsa.c; ok markus
Upstream-ID: ac8a048d24dcd89594b0052ea5e3404b473bfa2f
Allow ssh-keygen to use a key held in ssh-agent as a CA when
signing certificates. bz#2377 ok markus
Upstream-ID: fb42e920b592edcbb5b50465739a867c09329c8f
since a couple of people have asked, leave a comment
explaining why we retain SSH v.1 support in the "delete all keys from agent"
path.
Upstream-ID: 4b42dcfa339813c15fe9248a2c1b7ed41c21bbb4
implement SHA2-{256,512} for RSASSA-PKCS1-v1_5 signatures
(user and host auth) based on draft-rsa-dsa-sha2-256-03.txt and
draft-ssh-ext-info-04.txt; with & ok djm@
Upstream-ID: cf82ce532b2733e5c4b34bb7b7c94835632db309
Fix occurrences of "r = func() != 0" which result in the
wrong error codes being returned due to != having higher precedence than =.
ok deraadt@ markus@
Upstream-ID: 5fc35c9fc0319cc6fca243632662d2f06b5fd840
[authfd.c]
bzero the agent address. the kernel was for a while very cranky about
these things. evne though that's fixed, always good to initialize
memory. ok deraadt djm
[kexecdhc.c kexecdhs.c key.c key.h myproposal.h packet.c readconf.c]
[ssh-agent.c ssh-ecdsa.c ssh-keygen.c ssh.c] Disable ECDH and ECDSA on
platforms that don't have the requisite OpenSSL support. ok dtucker@
[PROTOCOL PROTOCOL.agent PROTOCOL.certkeys auth2-jpake.c authfd.c]
[authfile.c buffer.h dns.c kex.c kex.h key.c key.h monitor.c]
[monitor_wrap.c myproposal.h packet.c packet.h pathnames.h readconf.c]
[ssh-add.1 ssh-add.c ssh-agent.1 ssh-agent.c ssh-keygen.1 ssh-keygen.c]
[ssh-keyscan.1 ssh-keyscan.c ssh-keysign.8 ssh.1 ssh.c ssh2.h]
[ssh_config.5 sshconnect.c sshconnect2.c sshd.8 sshd.c sshd_config.5]
[uuencode.c uuencode.h bufec.c kexecdh.c kexecdhc.c kexecdhs.c ssh-ecdsa.c]
Implement Elliptic Curve Cryptography modes for key exchange (ECDH) and
host/user keys (ECDSA) as specified by RFC5656. ECDH and ECDSA offer
better performance than plain DH and DSA at the same equivalent symmetric
key length, as well as much shorter keys.
Only the mandatory sections of RFC5656 are implemented, specifically the
three REQUIRED curves nistp256, nistp384 and nistp521 and only ECDH and
ECDSA. Point compression (optional in RFC5656 is NOT implemented).
Certificate host and user keys using the new ECDSA key types are supported.
Note that this code has not been tested for interoperability and may be
subject to change.
feedback and ok markus@
[PROTOCOL.certkeys auth-options.c auth-options.h auth-rsa.c]
[auth2-pubkey.c authfd.c key.c key.h myproposal.h ssh-add.c]
[ssh-agent.c ssh-dss.c ssh-keygen.1 ssh-keygen.c ssh-rsa.c]
[sshconnect.c sshconnect2.c sshd.c]
revised certificate format ssh-{dss,rsa}-cert-v01@openssh.com with the
following changes:
move the nonce field to the beginning of the certificate where it can
better protect against chosen-prefix attacks on the signature hash
Rename "constraints" field to "critical options"
Add a new non-critical "extensions" field
Add a serial number
The older format is still support for authentication and cert generation
(use "ssh-keygen -t v00 -s ca_key ..." to generate a v00 certificate)
ok markus@
- djm@cvs.openbsd.org 2010/02/26 20:29:54
[PROTOCOL PROTOCOL.agent PROTOCOL.certkeys addrmatch.c auth-options.c]
[auth-options.h auth.h auth2-pubkey.c authfd.c dns.c dns.h hostfile.c]
[hostfile.h kex.h kexdhs.c kexgexs.c key.c key.h match.h monitor.c]
[myproposal.h servconf.c servconf.h ssh-add.c ssh-agent.c ssh-dss.c]
[ssh-keygen.1 ssh-keygen.c ssh-rsa.c ssh.1 ssh.c ssh2.h sshconnect.c]
[sshconnect2.c sshd.8 sshd.c sshd_config.5]
Add support for certificate key types for users and hosts.
OpenSSH certificate key types are not X.509 certificates, but a much
simpler format that encodes a public key, identity information and
some validity constraints and signs it with a CA key. CA keys are
regular SSH keys. This certificate style avoids the attack surface
of X.509 certificates and is very easy to deploy.
Certified host keys allow automatic acceptance of new host keys
when a CA certificate is marked as sh/known_hosts.
see VERIFYING HOST KEYS in ssh(1) for details.
Certified user keys allow authentication of users when the signing
CA key is marked as trusted in authorized_keys. See "AUTHORIZED_KEYS
FILE FORMAT" in sshd(8) for details.
Certificates are minted using ssh-keygen(1), documentation is in
the "CERTIFICATES" section of that manpage.
Documentation on the format of certificates is in the file
PROTOCOL.certkeys
feedback and ok markus@
dtucker@openbsd.org
djm@openbsd.org
markus@openbsd.org
jsg@openbsd.org
deraadt@openbsd.org
naddy@openbsd.org
Damien Miller
Darren Tucker