One document matched: draft-salowey-secsh-uri-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY rfc5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY rfc3629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
<!ENTITY ietf-secsh-filexfer SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-secsh-filexfer.xml">
<!ENTITY rfc4253 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4253.xml">
<!ENTITY rfc4716 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4716.xml">
<!ENTITY rfc4251 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4251.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc4395 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4395.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<rfc category="std" docName="draft-salowey-secsh-uri-00.txt"
ipr="trust200902">
<front>
<title abbrev="URI Scheme for SSH">Uniform Resource Identifier
(URI) Scheme for Secure Shell
(SSH)</title>
<author fullname="Joseph Salowey" initials="J" surname="Salowey">
<organization abbrev="">Cisco Systems</organization>
<address>
<postal>
<street>2901 3rd Ave</street>
<city>Seattle</city>
<country>US</country>
<code>98121</code>
<region>WA</region>
</postal>
<email>jsalowey@cisco.com</email>
</address>
</author>
<author fullname="Steve Suehring" initials="S" surname="Suehring">
<organization abbrev=""></organization>
<address>
<postal>
<street>PO BOX 1033</street>
<city>Stevens Point</city>
<country>US</country>
<code>54481</code>
<region>WI</region>
</postal>
<email>suehring@braingia.com</email>
</address>
</author>
<date year="2010" />
<abstract>
<t>This document describes the Uniform Resource Identifiers used to
locate resources for the
Secure Shell (SSH) protocol. The document describes the generic syntax
involved in URI definitions as well as specific definitions for the
protocol. These specific definitions include user credentials such
as username and other parameters such as host key
fingerprint. </t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section anchor="introduction" title="Introduction">
<t>This document describes the Uniform Resource Identifiers (URIs) to be
used with the Secure Shell (SSH) <xref
target="RFC4251"></xref> protocos.</t>
<t>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
<xref target="RFC2119"></xref>.</t>
</section>
<!-- ====================================================================== -->
<section title="General Syntax">
<t>A hierarchical URI shall consist of the scheme and the scheme
specific portion separated by a colon ":" followed by the hierarchical
part, as discussed in <xref target="RFC3986"></xref>. This specification
uses the definitions "port", "host", "scheme", "userinfo", "path-empty",
"path-abempty" and "authority" from <xref target="RFC3986"></xref>. This
document follows the ABNF notation defined in <xref
target="RFC5234"></xref>.</t>
</section>
<section anchor="sshuri" title="Secure Shell (SSH) URI">
<t>This section describes the SSH URI and contains the information
necessary to register the URI according to the template in <xref
target="RFC4395"></xref>.</t>
<section anchor="sshscheme" title="Scheme Name">
<t>The Secure Shell scheme name is "ssh".</t>
</section>
<section title="Status">
<t>The requested status of the SSH URI is "permanent".</t>
</section>
<section anchor="sshsyntax" title="URI Scheme Syntax">
<t>The Secure Shell (SSH) scheme shall consist of the scheme name
"ssh" followed by a colon ":" followed by hier-part defined in <xref
target="RFC3986"></xref>. The SSH URI ABNF definition follows.</t>
<t><figure>
<artwork type="abnf"><![CDATA[
sshURI = "ssh:" hier-part
hier-part = "//" authority path-abempty
authority = [ [ ssh-info ] "@" ] host [ ":" port ]
host = <as specified in [RFC3986]>
port = <as specified in [RFC3986]>
path-abempty = <as specified in [RFC3986]>
ssh-info = [ userinfo ] [";" c-param *("," c-param)]
userinfo = <as specified in [RFC3986]>
c-param = paramname "=" paramvalue
paramname = *( ALPHA / DIGIT / "-" )
paramvalue = *( ALPHA / DIGIT / "-" )
]]></artwork>
</figure></t>
<t>The following reserved characters from <xref
target="RFC3986"></xref> are used as delimiters within the SSH URI:
";", ",", ":", and "=" . They must not be escaped when used as
delimiters and must be escaped when the appear in other uses.</t>
</section>
<section anchor="sshsemantics" title="URI Semantics">
<t>The intended usage of the SSH URI is to establish an interactive
SSH terminal session with the host defined in the authority portion of
the URI. The only operation defined for the URI is to establish an SSH
terminal session with a remote host.</t>
<t>If the userinfo or connection parameters are present the at-sign
"@" shall precede the authority section of the URI. Optionally, the
authority section MAY also include the port preceded by a colon ":".
The host SHOULD be a non-empty string. If the port is not included,
the default port is assumed.</t>
<t>The ssh-info portion of the URI MAY include credentials consisting
of a username followed by optional parameters. The convention of
including the password separated from the username by a ":" in the URI
is NOT RECOMMENDED and is deprecated in accordance with <xref
target="RFC3986"></xref>.</t>
<t>One or more optional connection parameters (c-param) may be
specified within the userinfo section of the URI. These
conn-parameters are separated from the userinfo by a semi-colon ";".
The only connection parameter defined in this document is for the
host-key fingerprint described in <xref target="connparam"></xref>. It
is possible that additional parameters be defined in the future. If a
connection parameter is not understood it SHOULD be ignored.</t>
<t>The SSH URI does not define a usage for a non-empty path element.
If a non-empty path element is included in an SSH URI then it SHOULD
be ignored.</t>
</section>
<section title="Encoding Considerations">
<t>The encoding of the "host" portion of the URI is as defined in
<xref target="RFC3986"></xref>. The encoding of the connection
parameters is described in <xref target="connparam"></xref></t>
</section>
<section title="Protocols using this URI scheme">
<t>This URI scheme is used by the SSH protocol version 2 defined in
<xref target="RFC4251"></xref>.</t>
</section>
<section title="Security Considerations">
<t>See <xref target="security"></xref>.</t>
</section>
<section title="Contact">
<t>This document is discussed on the IETF SSH list: ietf-ssh@netbsd.org</t>
</section>
</section>
<section title="Parameters">
<t></t>
<section anchor="connparam" title=" SSH connection parameters ">
<t>The following parameters are associated with an SSH connection and
are applicable to SSH and SFTP. All parameters are optional and MUST
NOT overwrite configured defaults. Individual parameters are separated
by a comma (",").</t>
<t><list style="hanging">
<t hangText="fingerprint"><vspace blankLines="1" />The fingerprint
parameter contains the fingerprint of the host key for the host
specified in the URL. The fingerprint is encoded as
host-key-alg-fingerprint. Host-key-alg is host public key
algorithm defined in <xref target="RFC4253"></xref> and the
fingerprint format is <xref
target="RFC4716"></xref>. For use in a URI,
the fingerprint shall use a single dash "-" as a separator instead
of the colon ":" as described in <xref
target="RFC4716"></xref>. This parameter MUST
NOT overwrite a key that is already configured for the host. The
fingerprint MAY be used to validate the authenticity of the host
key if the URL was obtained from an authenticated source with its
integrity protected. If this parameter is not included then the
host key is validated using another method. See Security
Considerations section for additional considerations. There MUST
be only one fingerprint parameter present in a given URL.</t>
</list></t>
</section>
</section>
<section title="Examples ">
<t>The following section shows basic examples of URLs for each protocol.
This section should not be considered to include all possible
combinations of URLs for each protocol.</t>
<t><figure>
<preamble>An SSH connection to the host host.example.com on the
standard port using username user.</preamble>
<artwork><![CDATA[
ssh://user@host.example.com]]></artwork>
</figure></t>
<t><figure>
<preamble>An SSH connection to the host host.example.com on port
2222 using username user.</preamble>
<artwork><![CDATA[
ssh://user@host.example.com:2222]]></artwork>
</figure></t>
<t><figure>
<preamble>An SSH connection to the host having the specified
host-key fingerprint at host.example.com on the standard port using
username user.</preamble>
<artwork><![CDATA[
ssh://user;fingerprint=ssh-dss-c1-b1-30-29-d7-b8-de-6c-97-
77-10-d7-46-41-63-87@host.example.com]]></artwork>
</figure></t>
</section>
<section title="IANA Considerations">
<t><xref target="sshuri"></xref>
provides the information required in the URL registration template in
accordance with <xref
target="RFC4395"></xref>.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>Passwords SHOULD NOT be included within the URI as doing so poses a
security risk. URIs are usually sent in the clear with no encryption or
other security, any password or other credentials included in the
userinfo could be seen by a potential attacker.</t>
<t>Although the host-key fingerprint is not confidential information,
care must be taken in handling fingerprints associated with URIs because
URIs transmitted or stored without protection may be modified by an
attacker. In general an implementation cannot determine the source of a
URI so a fingerprint received in a URI should have no more trust
associated with it than a raw public key received in the SSH protocol
itself. If a locally configured key exists for the server already it
MUST NOT be automatically overwritten with information from the URI. If
the host is unknown then the implementation should treat the fingerprint
received with the same caution that it does with any unknown public key.
The client MAY offer the fingerprint and URI for external validation
before allowing a connection based on this information. If the client
chooses to make a connection based on the URI information and it finds
that the fingerprint in the URI and the public key offered by the server
do not match then it SHOULD provide a warning and provide a means to
abort the connection. Sections 4.1 and 9.2.4 of <xref
target="RFC4251"></xref> provide a good discussion of handling public
keys received in the SSH protocol.</t>
</section>
<section title="Acknowledgements">
<t>Ben Harris, Tom Petch and the members of the SSH working group have
provided much useful feedback in the preparation of this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc3986;
&rfc5234;
&rfc4253;
&rfc4716;
&rfc4251;
&rfc2119;
</references>
<references title="Informative References">
&rfc4395;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 12:11:40 |