e.g.
PermitListen 2222 8080
is equivalent to:
PermitListen *:2222 *:8080
Some bonus manpage improvements, mostly from markus@
"looks fine" markus@
OpenBSD-Commit-ID: 6546b0cc5aab7f53d65ad0a348ca0ae591d6dd24
authorized_keys lines that contained permitopen/permitlisten were being
treated as invalid.
OpenBSD-Commit-ID: 7ef41d63a5a477b405d142dc925b67d9e7aaa31b
options to allow underscores in variable names (regression introduced in
7.7). bz2851, ok deraadt@
OpenBSD-Commit-ID: 69690ffe0c97ff393f2c76d25b4b3d2ed4e4ac9c
"expiry-time" as the former is confusing wrt similar terminology in X.509;
pointed out by jsing@
OpenBSD-Commit-ID: 376939466a1f562f3950a22314bc6505733aaae6
remove the legacy one.
Includes a fairly big refactor of auth2-pubkey.c to retain less state
between key file lines.
feedback and ok markus@
OpenBSD-Commit-ID: dece6cae0f47751b9892080eb13d6625599573df
This API parses options to a dedicated structure rather than the old API's
approach of setting global state. It also includes support for merging
options, e.g. from authorized_keys, authorized_principals and/or
certificates.
feedback and ok markus@
OpenBSD-Commit-ID: 98badda102cd575210d7802943e93a34232c80a2
refactor channels.c
Move static state to a "struct ssh_channels" that is allocated at
runtime and tracked as a member of struct ssh.
Explicitly pass "struct ssh" to all channels functions.
Replace use of the legacy packet APIs in channels.c.
Rework sshd_config PermitOpen handling: previously the configuration
parser would call directly into the channels layer. After the refactor
this is not possible, as the channels structures are allocated at
connection time and aren't available when the configuration is parsed.
The server config parser now tracks PermitOpen itself and explicitly
configures the channels code later.
ok markus@
Upstream-ID: 11828f161656b965cc306576422613614bea2d8f
make sure we don't pass a NULL string to vfprintf
(triggered by the principals-command regress test); ok bluhm
Upstream-ID: eb49854f274ab37a0b57056a6af379a0b7111990
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)
Damien Miller
dtucker@openbsd.org
djm@openbsd.org
Darren Tucker
deraadt@openbsd.org
markus@openbsd.org
mmcc@openbsd.org
Darren Tucker