When a forced-command appears in both a certificate and
an authorized keys/principals command= restriction, refuse to accept the
certificate unless they are identical.
The previous (documented) behaviour of having the certificate forced-
command override the other could be a bit confused and more error-prone.
Pointed out by Jann Horn of Project Zero; ok dtucker@
Upstream-ID: 79d811b6eb6bbe1221bf146dde6928f92d2cd05f
refactor canohost.c: move functions that cache results closer
to the places that use them (authn and session code). After this, no state is
cached in canohost.c
feedback and ok markus@
Upstream-ID: 5f2e4df88d4803fc8ec59ec53629105e23ce625e
Add a new authorized_keys option "restrict" that
includes all current and future key restrictions (no-*-forwarding, etc). Also
add permissive versions of the existing restrictions, e.g. "no-pty" -> "pty".
This simplifies the task of setting up restricted keys and ensures they are
maximally-restricted, regardless of any permissions we might implement in the
future.
Example:
restrict,pty,command="nethack" ssh-ed25519 AAAAC3NzaC1lZDI1...
Idea from Jann Horn; ok markus@
Upstream-ID: 04ceb9d448e46e67e13887a7ae5ea45b4f1719d0
Don't make parsing of authorized_keys' environment=
option conditional on PermitUserEnv - always parse it, but only use the
result if the option is enabled. This prevents the syntax of authorized_keys
changing depending on which sshd_config options were enabled.
bz#2329; based on patch from coladict AT gmail.com, ok dtucker@
[PROTOCOL auth-options.c auth-passwd.c auth-rh-rsa.c auth-rhosts.c]
[auth-rsa.c auth.c auth1.c auth2-hostbased.c auth2-kbdint.c auth2-none.c]
[auth2-passwd.c auth2-pubkey.c auth2.c canohost.c channels.c channels.h]
[clientloop.c misc.c misc.h monitor.c mux.c packet.c readconf.c]
[readconf.h servconf.c servconf.h serverloop.c session.c ssh-agent.c]
[ssh.c ssh_config.5 sshconnect.c sshconnect1.c sshconnect2.c sshd.c]
[sshd_config.5 sshlogin.c]
Add support for Unix domain socket forwarding. A remote TCP port
may be forwarded to a local Unix domain socket and vice versa or
both ends may be a Unix domain socket. This is a reimplementation
of the streamlocal patches by William Ahern from:
http://www.25thandclement.com/~william/projects/streamlocal.html
OK djm@ markus@
[Makefile.in auth-bsdauth.c auth-chall.c auth-options.c auth-rsa.c
[auth2-none.c auth2-pubkey.c authfile.c authfile.h cipher-3des1.c
[cipher-chachapoly.c cipher-chachapoly.h cipher.c cipher.h
[digest-libc.c digest-openssl.c digest.h dns.c entropy.c hmac.h
[hostfile.c key.c key.h krl.c monitor.c packet.c rsa.c rsa.h
[ssh-add.c ssh-agent.c ssh-dss.c ssh-ecdsa.c ssh-ed25519.c
[ssh-keygen.c ssh-pkcs11-client.c ssh-pkcs11-helper.c ssh-pkcs11.c
[ssh-rsa.c sshbuf-misc.c sshbuf.h sshconnect.c sshconnect1.c
[sshconnect2.c sshd.c sshkey.c sshkey.h
[openbsd-compat/openssl-compat.c openbsd-compat/openssl-compat.h]
New key API: refactor key-related functions to be more library-like,
existing API is offered as a set of wrappers.
with and ok markus@
Thanks also to Ben Hawkes, David Tomaschik, Ivan Fratric, Matthew
Dempsky and Ron Bowes for a detailed review a few months ago.
NB. This commit also removes portable OpenSSH support for OpenSSL
<0.9.8e.
[auth-options.c channels.c servconf.c servconf.h serverloop.c session.c]
[sshd_config.5]
make AllowTcpForwarding accept "local" and "remote" in addition to its
current "yes"/"no" to allow the server to specify whether just local or
remote TCP forwarding is enabled. ok markus@
[channels.c auth-options.c servconf.c channels.h sshd.8]
Add wildcard support to PermitOpen, allowing things like "PermitOpen
localhost:*". bz #1857, ok djm markus.
[auth-options.c auth1.c auth2.c bufaux.c buffer.h kex.c key.c packet.c]
[packet.h ssh-dss.c ssh-rsa.c]
Add buffer_get_cstring() and related functions that verify that the
string extracted from the buffer contains no embedded \0 characters*
This prevents random (possibly malicious) crap from being appended to
strings where it would not be noticed if the string is used with
a string(3) function.
Use the new API in a few sensitive places.
* actually, we allow a single one at the end of the string for now because
we don't know how many deployed implementations get this wrong, but don't
count on this to remain indefinitely.
[PROTOCOL.certkeys auth-options.c ssh-keygen.c]
Move the permit-* options to the non-critical "extensions" field for v01
certificates. The logic is that if another implementation fails to
implement them then the connection just loses features rather than fails
outright.
ok markus@
[auth-options.c auth-options.h auth.c auth.h auth2-pubkey.c]
[key.c servconf.c servconf.h sshd.8 sshd_config.5]
add some optional indirection to matching of principal names listed
in certificates. Currently, a certificate must include the a user's name
to be accepted for authentication. This change adds the ability to
specify a list of certificate principal names that are acceptable.
When authenticating using a CA trusted through ~/.ssh/authorized_keys,
this adds a new principals="name1[,name2,...]" key option.
For CAs listed through sshd_config's TrustedCAKeys option, a new config
option "AuthorizedPrincipalsFile" specifies a per-user file containing
the list of acceptable names.
If either option is absent, the current behaviour of requiring the
username to appear in principals continues to apply.
These options are useful for role accounts, disjoint account namespaces
and "user@realm"-style naming policies in certificates.
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@
[auth-rhosts.c monitor.c monitor_wrap.c session.c auth-options.c sshd.c]
Hold authentication debug messages until after successful authentication.
Fixes an info leak of environment variables specified in authorized_keys,
reported by Jacob Appelbaum. ok djm@
- 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@
[auth-options.c match.c servconf.c addrmatch.c sshd.8]
support CIDR address matching in .ssh/authorized_keys from="..." stanzas
ok and extensive testing dtucker@
[auth-options.c auth1.c channels.c channels.h clientloop.c gss-serv.c]
[monitor.c monitor_wrap.c nchan.c servconf.c serverloop.c session.c]
[ssh.c sshd.c]
Implement a channel success/failure status confirmation callback
mechanism. Each channel maintains a queue of callbacks, which will
be drained in order (RFC4253 guarantees confirm messages are not
reordered within an channel).
Also includes a abandonment callback to clean up if a channel is
closed without sending confirmation messages. This probably
shouldn't happen in compliant implementations, but it could be
abused to leak memory.
ok markus@ (as part of a larger diff)
[canohost.c channels.c cipher-acss.c defines.h dns.c gss-genr.c]
[gss-serv-krb5.c gss-serv.c log.h loginrec.c logintest.c readconf.c]
[servconf.c ssh-keygen.c ssh-keyscan.c ssh-keysign.c ssh-rand-helper.c]
[ssh.c sshconnect.c sshd.c openbsd-compat/bindresvport.c]
[openbsd-compat/bsd-arc4random.c openbsd-compat/bsd-misc.c]
[openbsd-compat/getrrsetbyname.c openbsd-compat/glob.c]
[openbsd-compat/mktemp.c openbsd-compat/port-linux.c]
[openbsd-compat/port-tun.c openbsd-compat/readpassphrase.c]
[openbsd-compat/setproctitle.c openbsd-compat/xmmap.c]
make the portable tree compile again - sprinkle unistd.h and string.h
back in. Don't redefine __unused, as it turned out to be used in
headers on Linux, and replace its use in auth-pam.c with ARGSUSED
[auth-options.c includes.h misc.c misc.h readconf.c servconf.c]
[serverloop.c ssh.c ssh_config.5 sshd_config.5 configure.ac]
two changes to the new ssh tunnel support. this breaks compatibility
with the initial commit but is required for a portable approach.
- make the tunnel id u_int and platform friendly, use predefined types.
- support configuration of layer 2 (ethernet) or layer 3
(point-to-point, default) modes. configuration is done using the
Tunnel (yes|point-to-point|ethernet|no) option is ssh_config(5) and
restricted by the PermitTunnel (yes|point-to-point|ethernet|no) option
in sshd_config(5).
ok djm@, man page bits by jmc@
[auth-options.c auth-options.h channels.c channels.h clientloop.c]
[misc.c misc.h readconf.c readconf.h scp.c servconf.c servconf.h]
[serverloop.c sftp.c ssh.1 ssh.c ssh_config ssh_config.5 sshconnect.c]
[sshconnect.h sshd.8 sshd_config sshd_config.5]
Add support for tun(4) forwarding over OpenSSH, based on an idea and
initial channel code bits by markus@. This is a simple and easy way to
use OpenSSH for ad hoc virtual private network connections, e.g.
administrative tunnels or secure wireless access. It's based on a new
ssh channel and works similar to the existing TCP forwarding support,
except that it depends on the tun(4) network interface on both ends of
the connection for layer 2 or layer 3 tunneling. This diff also adds
support for LocalCommand in the ssh(1) client.
ok djm@, markus@, jmc@ (manpages), tested and discussed with others
[auth-options.c channels.c channels.h clientloop.c compat.c compat.h]
[misc.c misc.h readconf.c readconf.h servconf.c ssh.1 ssh.c ssh_config.5]
[sshd_config.5]
bz#413: allow optional specification of bind address for port forwardings.
Patch originally by Dan Astorian, but worked on by several people
Adds GatewayPorts=clientspecified option on server to allow remote
forwards to bind to client-specified ports.
- markus@cvs.openbsd.org 2003/06/02 09:17:34
[auth2-hostbased.c auth.c auth-options.c auth-rhosts.c auth-rh-rsa.c]
[canohost.c monitor.c servconf.c servconf.h session.c sshd_config]
[sshd_config.5]
deprecate VerifyReverseMapping since it's dangerous if combined
with IP based access control as noted by Mike Harding; replace with
a UseDNS option, UseDNS is on by default and includes the
VerifyReverseMapping check; with itojun@, provos@, jakob@ and deraadt@
ok deraadt@, djm@
- (djm) Fix portable-specific uses of verify_reverse_mapping too
djm@openbsd.org
mmcc@openbsd.org
markus@openbsd.org
Damien Miller
Darren Tucker
Ben Lindstrom