Reverse Secure Shell (Reverse SSH)Juniper Networkskwatsen@juniper.net
Operations
NETCONF Working Groupreverse-sshThis memo presents a technique for a NETCONF server to
initiate a SSH connection to a NETCONF client. This is
accomplished by the NETCONF client listening on IANA-assigned
TCP port XXX and starting the SSH client protocol immediately
after accepting a TCP connection on it. This role-reversal
is necessary as the NETCONF server must also be the SSH Server,
in order for the NETCONF client to open the IANA-assigned
SSH subsystem "netconf".The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in RFC 2119 .This memo presents a technique for a NETCONF
server to initiate a
Secure Shell (SSH) connection to
a NETCONF client. This is accomplished by the NETCONF
client listening on IANA-assigned TCP port XXX and starting
the SSH client protocol immediately after accepting a TCP
connection on it. This role-reversal is necessary as the
NETCONF server must also be the SSH Server, in order for
the NETCONF client to open the IANA-assigned SSH subsystem
"netconf" .While the motivation for this work is for the NETCONF
protocol, the solution is not specific to NETCONF and is
applicable any time it is desired for a SSH server to
initiate a connection to a SSH client. For this reason,
the solution is given the generic name "Reverse SSH" and
the port the remote peer listens on is the Reverse SSH
port.The SSH protocol is nearly ubiquitous for device management,
as it is the transport for the command-line applications `ssh`,
`scp`, and `sftp` and is the required transport for the NETCONF
protocol . However, all these SSH-based
protocols expect the managed device to be the SSH server.Reverse SSH enables the managed device to consistently be
the SSH server regardless of which peer initiates the underlying
TCP connection. Maintaining the role of SSH Server is both
necessary and desirable. It is necessary because SSH
channels and subsystems can only be opened on the SSH Server.
It is desirable because it conviently leverages infrastructure
that may be deployed for host-key verification and user
authentication.Reverse SSH is useful for both initial deployment and
on-going device management and may be used to enable any
of the following scenarios:
The device may proactively "call home" after
being powered on for the first time to register
itself with its management system.The managed device may access the network in a way that
dynamically assigns it an IP address and it doesn't
register its assigned IP addressed to a mapping service.The managed device may be configured in "stealth mode"
and thus doesn't have any open ports.The managed device may be deployed behind a firewall
that doesn't allow SSH access to the internal
network.The managed device may be deployed behind a firewall
that implements network address translation (NAT)
for all internal network IP addresses.The operator may prefer to have managed devices initiate
management connections believing it is easier to
secure one open-port in the data center than to
have an open port on each managed device in the network.One key benefit of using SSH as the transport protocol is
its ability to multiplex an unspecified number of independently
flow-controlled TCP sessions . This
is valuable as the managed device only needs to be configured
to initiate a single Reverse SSH connection regardless the number
of TCP-based protocols the application wishes to support. For
instance, the application may "pin up" a channel for each
distinct type of asynchronous notification the managed device
supports (logs, traps, backups, etc.) and dynamically open/close
channels as needed by its runtime.The NETCONF server's perspective
The NETCONF server initiates a TCP connection to
the NETCONF client on the IANA-assigned Reverse SSH
port XXX.Immediately after the TCP session starts, the NETCONF
server starts the SSH server protocol using the
accepted TCP connection. That is, the NETCONF Server
sends its SSH host key during the SSH key exchange.The NETCONF client's perspective
The NETCONF client listens for TCP connections
on the IANA-assigned SSH port XXX.The NETCONF client accepts an incoming TCP
connection and immediately starts the SSH client
protocol. That is, the NETCONF client will need
to authenticate its peer's SSH host key during the
SSH key exchange.This document updates the SSH Transport Layer Protocol
only by removing the restriction
in Section 4 (Connection Setup) of
that the SSH Client must initiate the transport connection.
Security implications related to this change are discussed
in the Security Considerations
section.For first-time connections, in order for the NETCONF client
to authenticate the NETCONF server, a public host key algorithm
that certifies the the NETCONF server's identity and host-key
SHOULD be used. Examples of suitable public host key algorithms
are the x509v3-* algorithms defined in
and the the hmac-* algorithms defined in the
The hmac-* Public Key Algorithms
section below.This section defines a family of public host key algorithms
that can be used to both identify the SSH server and enable its
host key to be automatically authenticated.The algorithms presented in this section rely on a symmetric
HMAC key to convey trust. This is in contrast to the PKI based
authentication model used by the x.509 based public host key
algorithms (). An HMAC key enables
Reverse SSH to be used in deployments where it's not possible for
a x.509 Certificate Authority to sign the managed device's
certificate in time, as it only requires a password to be
provided.The HMAC-based public host key algorithms defined in this
specification mirror those defined in .
These host-keys are to be treated the same way as in
, except that the peer authenticates
the host key via an HMAC, instead of PKIX. The algorithms
defined by this specification are:Regardless of which underlying host key is used, the format
of the hmac-* based public key is as follows:The "server-id" field encodes a user-configured unique
identifier for the SSH Server, or its Serial Number if none
provided. This field is necessary as the SSH client MAY
not otherwise be identifiable. For instance, the SSH
server may be "calling home" for the first time or have
a dynamically assigned address (DHCP, NAT, etc.).The "host-key" field is the SSH Server's corresponding
SSH host key. For instance, if the "hmac-ssh-rsa" public
key was negotiated during key exchange, this field would
encode the "ssh-rsa" host key.The "hmac" field is the value produced using the MAC
algorithm negotiated during key exchange over the selected
host key and a user-configured HMAC key.
[]For devices supporting NETCONF, this section defines
a YANG module to configure Reverse
SSH on the device. For devices that do not support NETCONF,
this section illustrates what its configuration data model
SHOULD include.This YANG module enables a NETCONF client to generically
manage a NETCONF server's Reverse SSH configuration. Key
aspects of this YANG module include support for more than
one application, more than one server per application, and
a reconnection strategy.This RFC does not attempt to define any strategy for how an
initial deployment might obtain its bootstrapping "call home"
configuration, as defined by this YANG module. That said,
implementations may consider fetching configuration from a
server identified via the DHCP protocol or loading it off a
USB drive plugged into the device before being powered on.This RFC deviates from standard SSH protocol usage by
allowing the SSH server to initiate the TCP connection.
This conflicts with section 4 of the SSH Transport Layer
Protocol RFC , which states
"The client initiates the connection". However this
statement is made without rationalization and it's not
clear how it impacts the security of the protocol, so
this section analyzes the security offered by the
having the client initiate the connection.First, assuming the SSH server is not using a public
host key algorithm that certifies its identity, the
security of the protocol doesn't seem to be sensitive
to which peer initiates the connection. That is, it is
still the case that reliable distribution of host keys
(or their fingerprints) should occur prior to first connection
and that verification for subsequent connections happens
by comparing the host keys in locally cached database.
It does not seem to matter if the SSH Server's host
name is derived from user-input or extracted from the
TCP layer, potentially via a reverse-DNS lookup. Once
the host name-to-key association is stored in a local
database, no man-in-the-middle attack is possible due
to the attacker being unable to guess the real SSH
server's private key (Section 9.3.4 (Man-in-th-middle) of
).That said, this RFC recommends implementations use
a public host key algorithm that certifies the SSH
server's identity. The identity can be any unique
identifier, such as a device's serial number or a
deployment-specific value. If this recommendation is
followed, then no information from the TCP layer would
be needed to lookup the device in a local database and
therefore the directionality of the TCP layer is
clearly inconsequential.The SSH protocol negotiates which algorithms it will
use during key exchange (Section 7.1 (Algortihm Negotition)
in ). The algorithm
selected is essentially the first compatible algorithm
listed by the SSH client that is also listed by the SSH
server. For a network management application, there
may be a need to advertise a large number of algorithms
to be compatible with the various devices it manages.
It is RECOMMENDED that the SSH client orders its list of
public host key algorithms such that all the certifiable
public host key algorithms are listed first. Additionally,
when possible, SSH servers SHOULD only list certifiable
public host key algorithms. Note that since the SSH server
would have to be configured to know which IP address it
needs to connect to, it is expected that it will also be
configured to know which host key algorithm to use
for the particular application, and hence only needs
to list just that one public host key algorithm.This RFC suggests implementations can use a device's
serial number as a form of identity. A potential concern
with using a serial number is that the SSH protocol passes
the SSH server's host-key in the clear and many times
serial numbers encode revealing information about the
device, such as what kind of device it is and when it
was manufactured. While there is little security in
trying to hide this information from an attacker, it
is understood that some deployments may want to keep
this information private. If this is a concern,
deployments MAY consider using instead a hash of the
device's serial number or an application-specified
unique identifier.The HMAC-* family of public host key algorithms defined
in this RFC take a hmac-key. The length of the hmac-key
SHOULD NOT be less than the output length of the associated
hash function, as discussed in Section 3 (Keys) in
. The associated
hash function for each public host key algorithm is as
follows:Note: for the Elliptical Curve algorithms, the hash
function selection is defined by Section 6.2.1 in
.The output length for each of these hash functions is
as follows:The hmac-* public host key algorithms require the application
consume the <server-id> field without being able to first
verify that it is the value the managed device sent. The
application must use the server-id value to lookup the managed
device's record in a local datastore in order to obtain the
HMAC-key needed to authenticate the HMAC. The application
must be sure to process the server-id carefully as it may have
been purposely encoded to illicit unexpected behaviour.An attacker could DoS the application using valid
"server-id" values, forcing the application to perform
computationally expensive operations, only to deduce that
the attacker doesn't posses a valid key. This is no
different than any secured service and all common
precautions apply (e.g. blacklisting the source address
after a set number of unsuccessful login attempts).Consistent with Section 8 of []
and Section 4.6 of [], this document
makes the following registrations in the Public Key Algorithm
Names registry:
The SSH public key algorithm "hmac-ssh-dss".The SSH public key algorithm "hmac-ssh-rsa".The SSH public key algorithm "hmac-rsa2048-sha256".The family of SSH public key algorithm names beginning with
"hmac-ecdsa-sha2-" and not containing the at-sign ('@').This document requests that IANA assigns a TCP port number
in the "Registered Port Numbers" range with the service name
"reverse-ssh". This port will be the default port for the
Reverse SSH protocol and will be used when the NETCONF server
needs to initiate a connection to a NETCONF client using SSH.
Below is the registration template following the rules in
.
HMAC: Keyed-Hashing for Message Authentication
Key words for use in RFCs to Indicate Requirement Levels
Harvard University
The Secure Shell (SSH) Protocol Assigned Numbers
SSH Communications Security Corp
Cisco Systems, Inc.
The Secure Shell (SSH) Protocol Architecture
SSH Communications Security Corp
Cisco Systems, Inc.
The Secure Shell (SSH) Authentication Protocol
SSH Communications Security Corp
Cisco Systems, Inc.
The Secure Shell (SSH) Transport Layer Protocol
SSH Communications Security Corp
Cisco Systems, Inc.
The Secure Shell (SSH) Connection Protocol
SSH Communications Security Corp
Cisco Systems, Inc.
Elliptic Curve Algorithm Integration
in the Secure Shell Transport Layer
Queensland University of Technology
Queen's University
YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)
Tail-f Systems
X.509v3 Certificates for Secure Shell Authentication
National Security Agency
Queensland University of Technology
NETCONF Configuration ProtocolJuniper NetworksTail-f SystemsJacobs UniversityBrocadeUsing the NETCONF Protocol over Secure Shell (SSH)Painless Security, LLCInternet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name
and Transport Protocol Port Number RegistryInternet Corporation for Assigned Names and NumbersNokia Research CenterUSC/ISIEricssonApple Inc.