Commit 9f6de2d7 authored by Dag-Erling Smørgrav's avatar Dag-Erling Smørgrav
Browse files

Vendor import of OpenSSH 5.7p1

parent 3a927e69
This diff is collapsed.
......@@ -206,6 +206,7 @@ OpenSSH contains no GPL code.
Sun Microsystems
The SCO Group
Daniel Walsh
Red Hat, Inc
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
......
# $Id: Makefile.in,v 1.310 2010/05/12 06:51:39 dtucker Exp $
# $Id: Makefile.in,v 1.320 2011/01/17 10:15:29 dtucker Exp $
# uncomment if you run a non bourne compatable shell. Ie. csh
#SHELL = @SH@
......@@ -58,6 +58,7 @@ ENT=@ENT@
XAUTH_PATH=@XAUTH_PATH@
LDFLAGS=-L. -Lopenbsd-compat/ @LDFLAGS@
EXEEXT=@EXEEXT@
MANFMT=@MANFMT@
INSTALL_SSH_PRNG_CMDS=@INSTALL_SSH_PRNG_CMDS@
INSTALL_SSH_RAND_HELPER=@INSTALL_SSH_RAND_HELPER@
......@@ -71,26 +72,27 @@ LIBSSH_OBJS=acss.o authfd.o authfile.o bufaux.o bufbn.o buffer.o \
log.o match.o md-sha256.o moduli.o nchan.o packet.o \
readpass.o rsa.o ttymodes.o xmalloc.o addrmatch.o \
atomicio.o key.o dispatch.o kex.o mac.o uidswap.o uuencode.o misc.o \
monitor_fdpass.o rijndael.o ssh-dss.o ssh-rsa.o dh.o kexdh.o \
kexgex.o kexdhc.o kexgexc.o msg.o progressmeter.o dns.o \
entropy.o gss-genr.o umac.o jpake.o schnorr.o \
ssh-pkcs11.o
monitor_fdpass.o rijndael.o ssh-dss.o ssh-ecdsa.o ssh-rsa.o dh.o \
kexdh.o kexgex.o kexdhc.o kexgexc.o bufec.o kexecdh.o kexecdhc.o \
msg.o progressmeter.o dns.o entropy.o gss-genr.o umac.o jpake.o \
schnorr.o ssh-pkcs11.o
SSHOBJS= ssh.o readconf.o clientloop.o sshtty.o \
sshconnect.o sshconnect1.o sshconnect2.o mux.o \
roaming_common.o roaming_client.o
SSHDOBJS=sshd.o auth-rhosts.o auth-passwd.o auth-rsa.o auth-rh-rsa.o \
audit.o audit-bsm.o audit-linux.o platform.o \
sshpty.o sshlogin.o servconf.o serverloop.o \
auth.o auth1.o auth2.o auth-options.o session.o \
auth-chall.o auth2-chall.o groupaccess.o \
auth-skey.o auth-bsdauth.o auth2-hostbased.o auth2-kbdint.o \
auth2-none.o auth2-passwd.o auth2-pubkey.o auth2-jpake.o \
monitor_mm.o monitor.o monitor_wrap.o kexdhs.o kexgexs.o \
monitor_mm.o monitor.o monitor_wrap.o kexdhs.o kexgexs.o kexecdhs.o \
auth-krb5.o \
auth2-gss.o gss-serv.o gss-serv-krb5.o \
loginrec.o auth-pam.o auth-shadow.o auth-sia.o md5crypt.o \
audit.o audit-bsm.o platform.o sftp-server.o sftp-common.o \
sftp-server.o sftp-common.o \
roaming_common.o roaming_serv.o
MANPAGES = moduli.5.out scp.1.out ssh-add.1.out ssh-agent.1.out ssh-keygen.1.out ssh-keyscan.1.out ssh.1.out sshd.8.out sftp-server.8.out sftp.1.out ssh-rand-helper.8.out ssh-keysign.8.out ssh-pkcs11-helper.8.out sshd_config.5.out ssh_config.5.out
......@@ -108,6 +110,7 @@ PATHSUBS = \
-e 's|/usr/libexec|$(libexecdir)|g' \
-e 's|/etc/shosts.equiv|$(sysconfdir)/shosts.equiv|g' \
-e 's|/etc/ssh/ssh_host_key|$(sysconfdir)/ssh_host_key|g' \
-e 's|/etc/ssh/ssh_host_ecdsa_key|$(sysconfdir)/ssh_host_ecdsa_key|g' \
-e 's|/etc/ssh/ssh_host_dsa_key|$(sysconfdir)/ssh_host_dsa_key|g' \
-e 's|/etc/ssh/ssh_host_rsa_key|$(sysconfdir)/ssh_host_rsa_key|g' \
-e 's|/var/run/sshd.pid|$(piddir)/sshd.pid|g' \
......@@ -230,7 +233,7 @@ catman-do:
@for f in $(MANPAGES_IN) ; do \
base=`echo $$f | sed 's/\..*$$//'` ; \
echo "$$f -> $$base.0" ; \
nroff -mandoc $$f | cat -v | sed -e 's/.\^H//g' \
$(MANFMT) $$f | cat -v | sed -e 's/.\^H//g' \
>$$base.0 ; \
done
......@@ -324,20 +327,27 @@ install-sysconf:
host-key: ssh-keygen$(EXEEXT)
@if [ -z "$(DESTDIR)" ] ; then \
if [ -f "$(DESTDIR)$(sysconfdir)/ssh_host_key" ] ; then \
echo "$(DESTDIR)$(sysconfdir)/ssh_host_key already exists, skipping." ; \
if [ -f "$(sysconfdir)/ssh_host_key" ] ; then \
echo "$(sysconfdir)/ssh_host_key already exists, skipping." ; \
else \
./ssh-keygen -t rsa1 -f $(DESTDIR)$(sysconfdir)/ssh_host_key -N "" ; \
./ssh-keygen -t rsa1 -f $(sysconfdir)/ssh_host_key -N "" ; \
fi ; \
if [ -f $(DESTDIR)$(sysconfdir)/ssh_host_dsa_key ] ; then \
echo "$(DESTDIR)$(sysconfdir)/ssh_host_dsa_key already exists, skipping." ; \
if [ -f $(sysconfdir)/ssh_host_dsa_key ] ; then \
echo "$(sysconfdir)/ssh_host_dsa_key already exists, skipping." ; \
else \
./ssh-keygen -t dsa -f $(DESTDIR)$(sysconfdir)/ssh_host_dsa_key -N "" ; \
./ssh-keygen -t dsa -f $(sysconfdir)/ssh_host_dsa_key -N "" ; \
fi ; \
if [ -f $(DESTDIR)$(sysconfdir)/ssh_host_rsa_key ] ; then \
echo "$(DESTDIR)$(sysconfdir)/ssh_host_rsa_key already exists, skipping." ; \
if [ -f $(sysconfdir)/ssh_host_rsa_key ] ; then \
echo "$(sysconfdir)/ssh_host_rsa_key already exists, skipping." ; \
else \
./ssh-keygen -t rsa -f $(DESTDIR)$(sysconfdir)/ssh_host_rsa_key -N "" ; \
./ssh-keygen -t rsa -f $(sysconfdir)/ssh_host_rsa_key -N "" ; \
fi ; \
if [ -z "@COMMENT_OUT_ECC@" ] ; then \
if [ -f $(sysconfdir)/ssh_host_ecdsa_key ] ; then \
echo "$(sysconfdir)/ssh_host_ecdsa_key already exists, skipping." ; \
else \
./ssh-keygen -t ecdsa -f $(sysconfdir)/ssh_host_ecdsa_key -N "" ; \
fi ; \
fi ; \
fi ;
......@@ -345,6 +355,7 @@ host-key-force: ssh-keygen$(EXEEXT)
./ssh-keygen -t rsa1 -f $(DESTDIR)$(sysconfdir)/ssh_host_key -N ""
./ssh-keygen -t dsa -f $(DESTDIR)$(sysconfdir)/ssh_host_dsa_key -N ""
./ssh-keygen -t rsa -f $(DESTDIR)$(sysconfdir)/ssh_host_rsa_key -N ""
test -z "@COMMENT_OUT_ECC@" && ./ssh-keygen -t ecdsa -f $(DESTDIR)$(sysconfdir)/ssh_host_ecdsa_key -N ""
uninstallall: uninstall
-rm -f $(DESTDIR)$(sysconfdir)/ssh_config
......@@ -405,6 +416,8 @@ tests interop-tests: $(TARGETS)
TEST_SSH_PUTTYGEN="puttygen"; \
TEST_SSH_CONCH="conch"; \
TEST_SSH_IPV6="@TEST_SSH_IPV6@" ; \
TEST_SSH_ECC="@TEST_SSH_ECC@" ; \
TEST_SSH_SHA256="@TEST_SSH_SHA256@" ; \
cd $(srcdir)/regress || exit $$?; \
$(MAKE) \
.OBJDIR="$${BUILDDIR}/regress" \
......@@ -425,7 +438,9 @@ tests interop-tests: $(TARGETS)
TEST_SSH_PLINK="$${TEST_SSH_PLINK}" \
TEST_SSH_PUTTYGEN="$${TEST_SSH_PUTTYGEN}" \
TEST_SSH_CONCH="$${TEST_SSH_CONCH}" \
TEST_SSH_IPV6="@TEST_SSH_IPV6@" \
TEST_SSH_IPV6="$${TEST_SSH_IPV6}" \
TEST_SSH_ECC="$${TEST_SSH_ECC}" \
TEST_SSH_SHA256="$${TEST_SSH_SHA256}" \
EXEEXT="$(EXEEXT)" \
$@ && echo all tests passed
......
......@@ -12,7 +12,9 @@ are individually implemented as extensions described below.
The protocol used by OpenSSH's ssh-agent is described in the file
PROTOCOL.agent
1. transport: Protocol 2 MAC algorithm "umac-64@openssh.com"
1. Transport protocol changes
1.1. transport: Protocol 2 MAC algorithm "umac-64@openssh.com"
This is a new transport-layer MAC method using the UMAC algorithm
(rfc4418). This method is identical to the "umac-64" method documented
......@@ -20,7 +22,7 @@ in:
http://www.openssh.com/txt/draft-miller-secsh-umac-01.txt
2. transport: Protocol 2 compression algorithm "zlib@openssh.com"
1.2. transport: Protocol 2 compression algorithm "zlib@openssh.com"
This transport-layer compression method uses the zlib compression
algorithm (identical to the "zlib" method in rfc4253), but delays the
......@@ -31,14 +33,27 @@ The method is documented in:
http://www.openssh.com/txt/draft-miller-secsh-compression-delayed-00.txt
3. transport: New public key algorithms "ssh-rsa-cert-v00@openssh.com" and
"ssh-dsa-cert-v00@openssh.com"
1.3. transport: New public key algorithms "ssh-rsa-cert-v00@openssh.com",
"ssh-dsa-cert-v00@openssh.com",
"ecdsa-sha2-nistp256-cert-v01@openssh.com",
"ecdsa-sha2-nistp384-cert-v01@openssh.com" and
"ecdsa-sha2-nistp521-cert-v01@openssh.com"
OpenSSH introduces two new public key algorithms to support certificate
OpenSSH introduces new public key algorithms to support certificate
authentication for users and hostkeys. These methods are documented in
the file PROTOCOL.certkeys
4. connection: Channel write close extension "eow@openssh.com"
1.4. transport: Elliptic Curve cryptography
OpenSSH supports ECC key exchange and public key authentication as
specified in RFC5656. Only the ecdsa-sha2-nistp256, ecdsa-sha2-nistp384
and ecdsa-sha2-nistp521 curves over GF(p) are supported. Elliptic
curve points encoded using point compression are NOT accepted or
generated.
2. Connection protocol changes
2.1. connection: Channel write close extension "eow@openssh.com"
The SSH connection protocol (rfc4254) provides the SSH_MSG_CHANNEL_EOF
message to allow an endpoint to signal its peer that it will send no
......@@ -77,8 +92,8 @@ message is only sent to OpenSSH peers (identified by banner).
Other SSH implementations may be whitelisted to receive this message
upon request.
5. connection: disallow additional sessions extension
"no-more-sessions@openssh.com"
2.2. connection: disallow additional sessions extension
"no-more-sessions@openssh.com"
Most SSH connections will only ever request a single session, but a
attacker may abuse a running ssh client to surreptitiously open
......@@ -105,7 +120,7 @@ of this message, the no-more-sessions request is only sent to OpenSSH
servers (identified by banner). Other SSH implementations may be
whitelisted to receive this message upon request.
6. connection: Tunnel forward extension "tun@openssh.com"
2.3. connection: Tunnel forward extension "tun@openssh.com"
OpenSSH supports layer 2 and layer 3 tunnelling via the "tun@openssh.com"
channel type. This channel type supports forwarding of network packets
......@@ -166,7 +181,9 @@ The contents of the "data" field for layer 2 packets is:
The "frame" field contains an IEEE 802.3 Ethernet frame, including
header.
7. sftp: Reversal of arguments to SSH_FXP_SYMLINK
3. SFTP protocol changes
3.1. sftp: Reversal of arguments to SSH_FXP_SYMLINK
When OpenSSH's sftp-server was implemented, the order of the arguments
to the SSH_FXP_SYMLINK method was inadvertently reversed. Unfortunately,
......@@ -179,7 +196,7 @@ SSH_FXP_SYMLINK as follows:
string targetpath
string linkpath
8. sftp: Server extension announcement in SSH_FXP_VERSION
3.2. sftp: Server extension announcement in SSH_FXP_VERSION
OpenSSH's sftp-server lists the extensions it supports using the
standard extension announcement mechanism in the SSH_FXP_VERSION server
......@@ -200,7 +217,7 @@ ever changed in an incompatible way. The server MAY advertise the same
extension with multiple versions (though this is unlikely). Clients MUST
check the version number before attempting to use the extension.
9. sftp: Extension request "posix-rename@openssh.com"
3.3. sftp: Extension request "posix-rename@openssh.com"
This operation provides a rename operation with POSIX semantics, which
are different to those provided by the standard SSH_FXP_RENAME in
......@@ -217,7 +234,7 @@ rename(oldpath, newpath) and will respond with a SSH_FXP_STATUS message.
This extension is advertised in the SSH_FXP_VERSION hello with version
"1".
10. sftp: Extension requests "statvfs@openssh.com" and
3.4. sftp: Extension requests "statvfs@openssh.com" and
"fstatvfs@openssh.com"
These requests correspond to the statvfs and fstatvfs POSIX system
......@@ -258,4 +275,20 @@ The values of the f_flag bitmask are as follows:
Both the "statvfs@openssh.com" and "fstatvfs@openssh.com" extensions are
advertised in the SSH_FXP_VERSION hello with version "2".
$OpenBSD: PROTOCOL,v 1.15 2010/02/26 20:29:54 djm Exp $
10. sftp: Extension request "hardlink@openssh.com"
This request is for creating a hard link to a regular file. This
request is implemented as a SSH_FXP_EXTENDED request with the
following format:
uint32 id
string "hardlink@openssh.com"
string oldpath
string newpath
On receiving this request the server will perform the operation
link(oldpath, newpath) and will respond with a SSH_FXP_STATUS message.
This extension is advertised in the SSH_FXP_VERSION hello with version
"1".
$OpenBSD: PROTOCOL,v 1.17 2010/12/04 00:18:01 djm Exp $
......@@ -159,8 +159,8 @@ successfully added or a SSH_AGENT_FAILURE if an error occurred.
2.2.3 Add protocol 2 key
The OpenSSH agent supports DSA and RSA keys for protocol 2. DSA keys may
be added using the following request
The OpenSSH agent supports DSA, ECDSA and RSA keys for protocol 2. DSA
keys may be added using the following request
byte SSH2_AGENTC_ADD_IDENTITY or
SSH2_AGENTC_ADD_ID_CONSTRAINED
......@@ -182,6 +182,30 @@ DSA certificates may be added with:
string key_comment
constraint[] key_constraints
ECDSA keys may be added using the following request
byte SSH2_AGENTC_ADD_IDENTITY or
SSH2_AGENTC_ADD_ID_CONSTRAINED
string "ecdsa-sha2-nistp256" |
"ecdsa-sha2-nistp384" |
"ecdsa-sha2-nistp521"
string ecdsa_curve_name
string ecdsa_public_key
mpint ecdsa_private
string key_comment
constraint[] key_constraints
ECDSA certificates may be added with:
byte SSH2_AGENTC_ADD_IDENTITY or
SSH2_AGENTC_ADD_ID_CONSTRAINED
string "ecdsa-sha2-nistp256-cert-v01@openssh.com" |
"ecdsa-sha2-nistp384-cert-v01@openssh.com" |
"ecdsa-sha2-nistp521-cert-v01@openssh.com"
string certificate
mpint ecdsa_private_key
string key_comment
constraint[] key_constraints
RSA keys may be added with this request:
byte SSH2_AGENTC_ADD_IDENTITY or
......@@ -214,7 +238,7 @@ order to the protocol 1 add keys message. As with the corresponding
protocol 1 "add key" request, the private key is overspecified to avoid
redundant processing.
For both DSA and RSA key add requests, "key_constraints" may only be
For DSA, ECDSA and RSA key add requests, "key_constraints" may only be
present if the request type is SSH2_AGENTC_ADD_ID_CONSTRAINED.
The agent will reply with a SSH_AGENT_SUCCESS if the key has been
......@@ -294,8 +318,7 @@ Protocol 2 keys may be removed with the following request:
string key_blob
Where "key_blob" is encoded as per RFC 4253 section 6.6 "Public Key
Algorithms" for either of the supported key types: "ssh-dss" or
"ssh-rsa".
Algorithms" for any of the supported protocol 2 key types.
The agent will delete any private key matching the specified public key
and return SSH_AGENT_SUCCESS. If no such key was found, the agent will
......@@ -364,8 +387,7 @@ Followed by zero or more consecutive keys, encoded as:
string key_comment
Where "key_blob" is encoded as per RFC 4253 section 6.6 "Public Key
Algorithms" for either of the supported key types: "ssh-dss" or
"ssh-rsa".
Algorithms" for any of the supported protocol 2 key types.
2.6 Private key operations
......@@ -429,9 +451,9 @@ a protocol 2 key:
uint32 flags
Where "key_blob" is encoded as per RFC 4253 section 6.6 "Public Key
Algorithms" for either of the supported key types: "ssh-dss" or
"ssh-rsa". "flags" is a bit-mask, but at present only one possible value
is defined (see below for its meaning):
Algorithms" for any of the supported protocol 2 key types. "flags" is
a bit-mask, but at present only one possible value is defined (see below
for its meaning):
SSH_AGENT_OLD_SIGNATURE 1
......@@ -535,4 +557,4 @@ Locking and unlocking affects both protocol 1 and protocol 2 keys.
SSH_AGENT_CONSTRAIN_LIFETIME 1
SSH_AGENT_CONSTRAIN_CONFIRM 2
$OpenBSD: PROTOCOL.agent,v 1.5 2010/02/26 20:29:54 djm Exp $
$OpenBSD: PROTOCOL.agent,v 1.6 2010/08/31 11:54:45 djm Exp $
......@@ -5,31 +5,37 @@ Background
----------
The SSH protocol currently supports a simple public key authentication
mechanism. Unlike other public key implementations, SSH eschews the
use of X.509 certificates and uses raw keys. This approach has some
benefits relating to simplicity of configuration and minimisation
of attack surface, but it does not support the important use-cases
of centrally managed, passwordless authentication and centrally
certified host keys.
mechanism. Unlike other public key implementations, SSH eschews the use
of X.509 certificates and uses raw keys. This approach has some benefits
relating to simplicity of configuration and minimisation of attack
surface, but it does not support the important use-cases of centrally
managed, passwordless authentication and centrally certified host keys.
These protocol extensions build on the simple public key authentication
system already in SSH to allow certificate-based authentication.
The certificates used are not traditional X.509 certificates, with
numerous options and complex encoding rules, but something rather
more minimal: a key, some identity information and usage options
that have been signed with some other trusted key.
system already in SSH to allow certificate-based authentication. The
certificates used are not traditional X.509 certificates, with numerous
options and complex encoding rules, but something rather more minimal: a
key, some identity information and usage options that have been signed
with some other trusted key.
A sshd server may be configured to allow authentication via certified
keys, by extending the existing ~/.ssh/authorized_keys mechanism
to allow specification of certification authority keys in addition
to raw user keys. The ssh client will support automatic verification
of acceptance of certified host keys, by adding a similar ability
to specify CA keys in ~/.ssh/known_hosts.
keys, by extending the existing ~/.ssh/authorized_keys mechanism to
allow specification of certification authority keys in addition to
raw user keys. The ssh client will support automatic verification of
acceptance of certified host keys, by adding a similar ability to
specify CA keys in ~/.ssh/known_hosts.
Certified keys are represented using two new key types:
ssh-rsa-cert-v01@openssh.com and ssh-dss-cert-v01@openssh.com that
include certification information along with the public key that is used
to sign challenges. ssh-keygen performs the CA signing operation.
Certified keys are represented using new key types:
ssh-rsa-cert-v01@openssh.com
ssh-dss-cert-v01@openssh.com
ecdsa-sha2-nistp256-cert-v01@openssh.com
ecdsa-sha2-nistp384-cert-v01@openssh.com
ecdsa-sha2-nistp521-cert-v01@openssh.com
These include certification information along with the public key
that is used to sign challenges. ssh-keygen performs the CA signing
operation.
Protocol extensions
-------------------
......@@ -47,10 +53,9 @@ in RFC4252 section 7.
New public key formats
----------------------
The ssh-rsa-cert-v01@openssh.com and ssh-dss-cert-v01@openssh.com key
types take a similar high-level format (note: data types and
encoding are as per RFC4251 section 5). The serialised wire encoding of
these certificates is also used for storing them on disk.
The certificate key types take a similar high-level format (note: data
types and encoding are as per RFC4251 section 5). The serialised wire
encoding of these certificates is also used for storing them on disk.
#define SSH_CERT_TYPE_USER 1
#define SSH_CERT_TYPE_HOST 2
......@@ -93,6 +98,26 @@ DSA certificate
string signature key
string signature
ECDSA certificate
string "ecdsa-sha2-nistp256@openssh.com" |
"ecdsa-sha2-nistp384@openssh.com" |
"ecdsa-sha2-nistp521@openssh.com"
string nonce
string curve
string public_key
uint64 serial
uint32 type
string key id
string valid principals
uint64 valid after
uint64 valid before
string critical options
string extensions
string reserved
string signature key
string signature
The nonce field is a CA-provided random bitstring of arbitrary length
(but typically 16 or 32 bytes) included to make attacks that depend on
inducing collisions in the signature hash infeasible.
......@@ -101,6 +126,9 @@ e and n are the RSA exponent and public modulus respectively.
p, q, g, y are the DSA parameters as described in FIPS-186-2.
curve and public key are respectively the ECDSA "[identifier]" and "Q"
defined in section 3.1 of RFC5656.
serial is an optional certificate serial number set by the CA to
provide an abbreviated way to refer to certificates from that CA.
If a CA does not wish to number its certificates it must set this
......@@ -123,7 +151,8 @@ any principal of the specified type. XXX DNS wildcards?
"valid after" and "valid before" specify a validity period for the
certificate. Each represents a time in seconds since 1970-01-01
00:00:00. A certificate is considered valid if:
valid after <= current time < valid before
valid after <= current time < valid before
criticial options is a set of zero or more key options encoded as
below. All such options are "critical" in the sense that an implementation
......@@ -137,15 +166,17 @@ The reserved field is currently unused and is ignored in this version of
the protocol.
signature key contains the CA key used to sign the certificate.
The valid key types for CA keys are ssh-rsa and ssh-dss. "Chained"
The valid key types for CA keys are ssh-rsa, ssh-dss and the ECDSA types
ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521. "Chained"
certificates, where the signature key type is a certificate type itself
are NOT supported. Note that it is possible for a RSA certificate key to
be signed by a DSS CA key and vice-versa.
be signed by a DSS or ECDSA CA key and vice-versa.
signature is computed over all preceding fields from the initial string
up to, and including the signature key. Signatures are computed and
encoded according to the rules defined for the CA's public key algorithm
(RFC4253 section 6.6 for ssh-rsa and ssh-dss).
(RFC4253 section 6.6 for ssh-rsa and ssh-dss, RFC5656 for the ECDSA
types).
Critical options
----------------
......@@ -222,4 +253,4 @@ permit-user-rc empty Flag indicating that execution of
of this script will not be permitted if
this option is not present.
$OpenBSD: PROTOCOL.certkeys,v 1.7 2010/08/04 05:40:39 djm Exp $
$OpenBSD: PROTOCOL.certkeys,v 1.8 2010/08/31 11:54:45 djm Exp $
......@@ -28,7 +28,7 @@ defined.
To open a new multiplexed session, a client may send the following
request:
uint32 MUX_C_MSG_NEW_SESSION
uint32 MUX_C_NEW_SESSION
uint32 request id
string reserved
bool want tty flag
......@@ -99,7 +99,7 @@ The server will reply with one of MUX_S_OK or MUX_S_PERMISSION_DENIED.
A client may request the master to establish a port forward:
uint32 MUX_C_OPEN_FORWARD
uint32 MUX_C_OPEN_FWD
uint32 request id
uint32 forwarding type
string listen host
......@@ -118,24 +118,23 @@ For dynamically allocated listen port the server replies with
uint32 client request id
uint32 allocated remote listen port
5. Requesting closure of port forwards
6. Requesting closure of port forwards
Note: currently unimplemented (server will always reply with MUX_S_FAILURE).
A client may request the master to establish a port forward:
uint32 MUX_C_OPEN_FORWARD
uint32 MUX_C_CLOSE_FWD
uint32 request id
uint32 forwarding type
string listen host
string listen port
string connect host
string connect port
forwarding type may be MUX_FWD_LOCAL, MUX_FWD_REMOTE, MUX_FWD_DYNAMIC.
A server may reply with a MUX_S_OK, a MUX_S_PERMISSION_DENIED or a
MUX_S_FAILURE.
6. Requesting stdio forwarding
7. Requesting stdio forwarding
A client may request the master to establish a stdio forwarding:
......@@ -153,7 +152,7 @@ The contents of "reserved" are currently ignored.
A server may reply with a MUX_S_SESSION_OPEED, a MUX_S_PERMISSION_DENIED
or a MUX_S_FAILURE.
7. Status messages
8. Status messages
The MUX_S_OK message is empty:
......@@ -170,14 +169,15 @@ The MUX_S_PERMISSION_DENIED and MUX_S_FAILURE include a reason:
uint32 client request id
string reason
7. Protocol numbers
9. Protocol numbers
#define MUX_MSG_HELLO 0x00000001
#define MUX_C_NEW_SESSION 0x10000002
#define MUX_C_ALIVE_CHECK 0x10000004
#define MUX_C_TERMINATE 0x10000005
#define MUX_C_OPEN_FORWARD 0x10000006
#define MUX_C_CLOSE_FORWARD 0x10000007
#define MUX_C_OPEN_FWD 0x10000006
#define MUX_C_CLOSE_FWD 0x10000007
#define MUX_C_NEW_STDIO_FWD 0x10000008
#define MUX_S_OK 0x80000001
#define MUX_S_PERMISSION_DENIED 0x80000002
#define MUX_S_FAILURE 0x80000003
......@@ -200,4 +200,4 @@ XXX server->client error/warning notifications
XXX port0 rfwd (need custom response message)
XXX send signals via mux
$OpenBSD: PROTOCOL.mux,v 1.2 2010/05/16 12:55:51 markus Exp $
$OpenBSD: PROTOCOL.mux,v 1.3 2011/01/13 21:55:25 djm Exp $
See http://www.openssh.com/txt/release-5.6 for the release notes.
See http://www.openssh.com/txt/release-5.7 for the release notes.
- A Japanese translation of this document and of the OpenSSH FAQ is
- available at http://www.unixuser.org/~haruyama/security/openssh/index.html
......@@ -62,4 +62,4 @@ References -
[6] http://www.openbsd.org/cgi-bin/man.cgi?query=style&sektion=9
[7] http://www.openssh.com/faq.html
$Id: README,v 1.74 2010/08/08 16:32:06 djm Exp $
$Id: README,v 1.75 2011/01/22 09:23:12 djm Exp $
/* $OpenBSD: atomicio.c,v 1.25 2007/06/25 12:02:27 dtucker Exp $ */
/* $OpenBSD: atomicio.c,v 1.26 2010/09/22 22:58:51 djm Exp $ */
/*
* Copyright (c) 2006 Damien Miller. All rights reserved.
* Copyright (c) 2005 Anil Madhavapeddy. All rights reserved.
......@@ -48,7 +48,8 @@
* ensure all of data on socket comes through. f==read || f==vwrite
*/
size_t
atomicio(ssize_t (*f) (int, void *, size_t), int fd, void *_s, size_t n)
atomicio6(ssize_t (*f) (int, void *, size_t), int fd, void *_s, size_t n,
int (*cb)(void *, size_t), void *cb_arg)
{
char *s = _s;
size_t pos = 0;
......@@ -73,17 +74,28 @@ atomicio(ssize_t (*f) (int, void *, size_t), int fd, void *_s, size_t n)
return pos;
default:
pos += (size_t)res;
if (cb != NULL && cb(cb_arg, (size_t)res) == -1) {
errno = EINTR;
return pos;
}
}
}
return (pos);
return pos;
}
size_t
atomicio(ssize_t (*f) (int, void *, size_t), int fd, void *_s, size_t n)
{
return atomicio6(f, fd, _s, n, NULL, NULL);
}
/*
* ensure all of data on socket comes through. f==readv || f==writev
*/
size_t
atomiciov(ssize_t (*f) (int, const struct iovec *, int), int fd,
const struct iovec *_iov, int iovcnt)
atomiciov6(ssize_t (*f) (int, const struct iovec *, int), int fd,
const struct iovec *_iov, int iovcnt,
int (*cb)(void *, size_t), void *cb_arg)
{
size_t pos = 0, rem;
ssize_t res;
......@@ -137,6 +149,17 @@ atomiciov(ssize_t (*f) (int, const struct iovec *, int), int fd,
iov[0].iov_base = ((char *)iov[0].iov_base) + rem;
iov[0].iov_len -= rem;
}
if (cb != NULL && cb(cb_arg, (size_t)res) == -1) {
errno = EINTR;
return pos;
}
}
return pos;
}
size_t
atomiciov(ssize_t (*f) (int, const struct iovec *, int), int fd,
const struct iovec *_iov, int iovcnt)
{
return atomiciov6(f, fd, _iov, iovcnt, NULL, NULL);
}
/* $OpenBSD: atomicio.h,v 1.10 2006/08/03 03:34:41 deraadt Exp $ */
/* $OpenBSD: atomicio.h,v 1.11 2010/09/22 22:58:51 djm Exp $ */