SSH - The ssh application implements the Secure Shell (SSH) protocol and
provides an SSH File Transfer Protocol (SFTP) client and server.
application is an implementation of the SSH protocol in Erlang.
offers API functions to write customized SSH clients and servers as
well as making the Erlang shell available over SSH. An SFTP client,
, and server, ssh_sftpd
, are also included.
application uses the applications public_key
to handle public keys and encryption. Hence, these applications
must be loaded for the ssh
application to work. In an embedded
environment this means that they must be started with
before the ssh
application is started.
application does not have an application- specific configuration
file, as described in application(3)
. However, by default it use the
following configuration files from OpenSSH:
By default, ssh
looks for id_dsa
, and authorized_keys
and for the host key files in /etc/ssh
. These locations can be changed
by the options user_dir
Public key handling can also be customized through a callback module that
implements the behaviors ssh_client_key_api
are the users private key
files. Notice that the public key is part of the private key so the ssh
application does not use the id_<*>.pub
files. These are for the
user's convenience when it is needed to convey the user's public key.
file contains a list of approved servers and their public
keys. Once a server is listed, it can be verified without user interaction.
file keeps track of the user's authorized public keys.
The most common use of this file is to let users log in without entering their
password, which is supported by the Erlang ssh
RSA and DSA host keys are supported and are expected to be found in files named
application uses the default OTP error logger
unexpected errors or print information about special events.
The supported SSH version is 2.0.
The actual set of algorithms may vary depending on which OpenSSL crypto library
that is installed on the machine. For the list on a particular installation,
use the command ssh:default_algorithms/0
. The user may override the
default algorithm configuration both on the server side and the client side.
See the option preferred_algorithms
in the ssh:daemon/1,2,3
Supported algorithms are:
- Key exchange algorithms:
- Public key algorithms:
- MAC algorithms:
- Encryption algorithms (ciphers):
- firstname.lastname@example.org (AEAD_AES_128_GCM)
- email@example.com (AEAD_AES_256_GCM)
Following the internet de-facto standard, the cipher and mac algorithm
AEAD_AES_128_GCM is selected when the cipher firstname.lastname@example.org is
negotiated. The cipher and mac algorithm AEAD_AES_256_GCM is selected when the
cipher email@example.com is negotiated.
See the text at the description of the rfc 5647 further down
- Compression algorithms:
Unicode filenames are supported if the emulator and the underlaying OS support
it. See section DESCRIPTION in the file
manual page in Kernel for
information about this subject.
The shell and the cli both support unicode.
The following rfc:s are supported:
- RFC 4251, The Secure Shell (SSH) Protocol Architecture.
- 9.4.6 Host-Based Authentication
- 9.5.2 Proxy Forwarding
- 9.5.3 X11 Forwarding
- RFC 4252, The Secure Shell (SSH) Authentication Protocol.
- 9. Host-Based Authentication: "hostbased"
- RFC 4253, The Secure Shell (SSH) Transport Layer Protocol.
- RFC 4254, The Secure Shell (SSH) Connection Protocol.
- 6.3. X11 Forwarding
- 7. TCP/IP Port Forwarding
- RFC 4256, Generic Message Exchange Authentication for the Secure Shell
- num-prompts > 1
- password changing
- other identification methods than userid-password
- RFC 4419, Diffie-Hellman Group Exchange for the Secure Shell (SSH)
Transport Layer Protocol.
- RFC 4716, The Secure Shell (SSH) Public Key File Format.
- RFC 5647, AES Galois Counter Mode for the Secure Shell Transport Layer
There is an ambiguity in the synchronized selection of cipher and mac algorithm.
This is resolved by OpenSSH in the ciphers firstname.lastname@example.org and
email@example.com which are implemented. If the explicit ciphers and macs
AEAD_AES_128_GCM or AEAD_AES_256_GCM are needed, they could be enabled with
the option preferred_algorithms.
If the client or the server is not Erlang/OTP, it is the users responsibility to
check that other implementation has the same interpretation of AEAD_AES_*_GCM
as the Erlang/OTP SSH before enabling them. The firstname.lastname@example.org variants
are always safe to use since they lack the ambiguity.
The second paragraph in section 5.1 is resolved as:
- If the negotiated cipher is AEAD_AES_128_GCM, the mac algorithm is set to
- If the negotiated cipher is AEAD_AES_256_GCM, the mac algorithm is set to
- If the mac algorithm is AEAD_AES_128_GCM, the cipher is set to
- If the mac algorithm is AEAD_AES_256_GCM, the cipher is set to
The first rule that matches when read in order from the top is applied
- RFC 5656, Elliptic Curve Algorithm Integration in the Secure Shell
- 5. ECMQV Key Exchange
- 6.4. ECMQV Key Exchange and Verification Method Name
- 7.2. ECMQV Message Numbers
- 10.2. Recommended Curves
- RFC 6668, SHA-2 Data Integrity Verification for the Secure Shell (SSH)
Transport Layer Protocol
Comment: Defines hmac-sha2-256 and hmac-sha2-512