This adds another transport protocol extension to allow a sshd to send
SSH2_MSG_EXT_INFO during user authentication, after the server has
learned the username that is being logged in to.
This lets sshd to update the acceptable signature algoritms for public
key authentication, and allows these to be varied via sshd_config(5)
"Match" directives, which are evaluated after the server learns the
username being authenticated.
Full details in the PROTOCOL file
OpenBSD-Commit-ID: 1de7da7f2b6c32a46043d75fcd49b0cbb7db7779
This adds a protocol extension to improve the integrity of the SSH
transport protocol, particular in and around the initial key exchange
(KEX) phase.
Full details of the extension are in the PROTOCOL file.
with markus@
OpenBSD-Commit-ID: 2a66ac962f0a630d7945fee54004ed9e9c439f14
This adds a pair of SSH transport protocol messages SSH2_MSG_PING/PONG
to implement a ping capability. These messages use numbers in the "local
extensions" number space and are advertised using a "ping@openssh.com"
ext-info message with a string version number of "0".
ok markus@
OpenBSD-Commit-ID: b6b3c4cb2084c62f85a8dc67cf74954015eb547f
extension request that allows the client to obtain user/group names that
correspond to a set of uids/gids.
Will be used to make directory listings more useful and consistent
in sftp(1).
ok markus@
OpenBSD-Commit-ID: 7ebabde0bcb95ef949c4840fe89e697e30df47d3
Add support to the sftp-server for the home-directory extension defined
in draft-ietf-secsh-filexfer-extensions-00. This overlaps a bit with the
existing expand-path@openssh.com, but uses a more official protocol name,
and so is a bit more likely to be implemented by non-OpenSSH clients.
From Mike Frysinger, ok dtucker@
OpenBSD-Commit-ID: bfc580d05cc0c817831ae7ecbac4a481c23566ab
allow server-side copies to be performed without having to go via the client.
Patch by Mike Frysinger, ok dtucker@
OpenBSD-Commit-ID: 00aa510940fedd66dab1843b58682de4eb7156d5
~-prefixed paths, in particular ~user ones. Allows scp in sftp mode to accept
these paths, like scp in rcp mode does.
prompted by and much discussion deraadt@
ok markus@
OpenBSD-Commit-ID: 7d794def9e4de348e1e777f6030fc9bafdfff392
The documentation was lacking the needed want-reply field in the initial
global request.
https://github.com/openssh/openssh-portable/pull/218 by dbussink
OpenBSD-Commit-ID: 051824fd78edf6d647a0b9ac011bf88e28775054
This is a simple extension that allows the server to clearly
communicate transfer limits it is imposing so the client doesn't
have to guess, or force the user to manually tune. This is
particularly useful when an attempt to use too large of a value
causes the server to abort the connection.
Patch from Mike Frysinger; ok dtucker@
OpenBSD-Commit-ID: f96293221e5aa24102d9bf30e4f4ef04d5f4fb51
While I'm here, describe and link to the remaining local PROTOCOL.*
docs that weren't already mentioned (PROTOCOL.key, PROTOCOL.krl and
PROTOCOL.mux)
OpenBSD-Commit-ID: 2a900f9b994ba4d53e7aeb467d44d75829fd1231
that the client may not support, and that the client should simply disregard
such keys (this is what ssh does already).
OpenBSD-Commit-ID: 65f8ffbc32ac8d12be8f913d7c0ea55bef8622bf
We accidentally send an empty string and a zero uint32 with
every direct-streamlocal@openssh.com channel open, in contravention of our
own spec.
Fixing this is too hard wrt existing versions that expect these
fields to be present and fatal() if they aren't, so document them
as "reserved" fields in the PROTOCOL spec as though we always
intended this and let us never speak of it again.
bz#2529, reported by Ron Frederick
Upstream-ID: 34cd326a4d236ca6e39084c4ff796bd97ab833e7
direct-streamlocal@openssh.com Unix domain foward
messages do not contain a "reserved for future use" field and in fact,
serverloop.c checks that there isn't one. Remove erroneous mention from
PROTOCOL description. bz#2421 from Daniel Black
Upstream-ID: 3d51a19e64f72f764682f1b08f35a8aa810a43ac
UpdateHostKeys fixes:
I accidentally changed the format of the hostkeys@openssh.com messages
last week without changing the extension name, and this has been causing
connection failures for people who are running -current. First reported
by sthen@
s/hostkeys@openssh.com/hostkeys-00@openssh.com/
Change the name of the proof message too, and reorder it a little.
Also, UpdateHostKeys=ask is incompatible with ControlPersist (no TTY
available to read the response) so disable UpdateHostKeys if it is in
ask mode and ControlPersist is active (and document this)
Revise hostkeys@openssh.com hostkey learning extension.
The client will not ask the server to prove ownership of the private
halves of any hitherto-unseen hostkeys it offers to the client.
Allow UpdateHostKeys option to take an 'ask' argument to let the
user manually review keys offered.
ok markus@
Host key rotation support.
Add a hostkeys@openssh.com protocol extension (global request) for
a server to inform a client of all its available host key after
authentication has completed. The client may record the keys in
known_hosts, allowing it to upgrade to better host key algorithms
and a server to gracefully rotate its keys.
The client side of this is controlled by a UpdateHostkeys config
option (default on).
ok markus@
[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 PROTOCOL PROTOCOL.chacha20poly1305 authfile.c chacha.c]
[chacha.h cipher-chachapoly.c cipher-chachapoly.h cipher.c cipher.h]
[dh.c myproposal.h packet.c poly1305.c poly1305.h servconf.c ssh.1]
[ssh.c ssh_config.5 sshd_config.5] Add a new protocol 2 transport
cipher "chacha20-poly1305@openssh.com" that combines Daniel
Bernstein's ChaCha20 stream cipher and Poly1305 MAC to build an
authenticated encryption mode.
Inspired by and similar to Adam Langley's proposal for TLS:
http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03
but differs in layout used for the MAC calculation and the use of a
second ChaCha20 instance to separately encrypt packet lengths.
Details are in the PROTOCOL.chacha20poly1305 file.
Feedback markus@, naddy@; manpage bits Loganden Velvindron @ AfriNIC
ok markus@ naddy@
[PROTOCOL sftp-client.c sftp-client.h sftp-server.c sftp.1 sftp.c]
fsync@openssh.com protocol extension for sftp-server
client support to allow calling fsync() faster successful transfer
patch mostly by imorgan AT nas.nasa.gov; bz#1798
"fine" markus@ "grumble OK" deraadt@ "doesn't sound bad to me" millert@
[PROTOCOL authfile.c cipher.c cipher.h kex.c kex.h monitor_wrap.c]
[myproposal.h packet.c ssh_config.5 sshd_config.5]
support AES-GCM as defined in RFC 5647 (but with simpler KEX handling)
ok and feedback djm@
[PROTOCOL authfile.c cipher.c cipher.h kex.h mac.c myproposal.h]
[packet.c ssh_config.5 sshd_config.5]
add encrypt-then-mac (EtM) modes to openssh by defining new mac algorithms
that change the packet format and compute the MAC over the encrypted
message (including the packet size) instead of the plaintext data;
these EtM modes are considered more secure and used by default.
feedback and ok djm@
[sftp-server.c sftp.1 sftp-client.h sftp.c PROTOCOL sftp-client.c]
add a protocol extension to support a hard link operation. It is
available through the "ln" command in the client. The old "ln"
behaviour of creating a symlink is available using its "-s" option
or through the preexisting "symlink" command; based on a patch from
miklos AT szeredi.hu in bz#1555; ok markus@
[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@
- 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@
