The goal of this document is to help operational teams with the configuration of OpenSSH server and client.All Mozilla sites and deployment should follow the recommendations below.The Security Assurance and Security Operations teams maintain this document as a reference guide.

1. Openssh 6.5 Download

Security vulnerabilities of Openbsd Openssh version 6.5 List of cve security vulnerabilities related to this exact version. You can filter results by cvss scores, years and months. This page provides a sortable list of security vulnerabilities. OpenSSH version 3.6p1 ported to NetWare 6.5. This is the daemon for the SSH program. It provides secure encrypted communications between two untrusted hosts over an insecure network. This daemon listens for the connections from clients. System-wide configuration file for the SSH.

Most default OpenSSH settings that are security-related already provide good security, thus changing them is at your own risk and is not documented here. For example, these guidelines assume only SSH protocol 2 is configured in the server, and SSH protocol 1 is disabled. This also assumes that you are keeping OpenSSH up-to-date with security patches.See man sshd_config, man ssh_config for more information on specific settings if you nevertheless need to change them. |

Configuration

Different versions of OpenSSH support different options which are not always compatible. This guide shows settings for the most commonly deployed OpenSSH versions at Mozilla - however, using the latest version of OpenSSH is recommended.

Modern (OpenSSH 6.7+)

File: /etc/ssh/sshd_config

File: /etc/ssh/moduli

All Diffie-Hellman moduli in use should be at least 3072-bit-long (they are used for diffie-hellman-group-exchange-sha256) as per our Key management Guidelines recommendations. See also man moduli.

To deactivate short moduli in two commands: awk '$5 >= 3071' /etc/ssh/moduli > /etc/ssh/moduli.tmp && mv /etc/ssh/moduli.tmp /etc/ssh/moduli

Intermediate (OpenSSH 5.3)

This is mainly for use by RHEL6, CentOS6, etc. which run older versions of OpenSSH.

File: /etc/ssh/sshd_config

File: /etc/ssh/moduli

All Diffie-Hellman moduli in use should be at least 2048-bit-long. From the structure of moduli files, this means the fifth field of all lines in this file should be greater than or equal to 2047.

To deactivate weak moduli in two commands: awk '$5 >= 2047' /etc/ssh/moduli > /etc/ssh/moduli.tmp; mv /etc/ssh/moduli.tmp /etc/ssh/moduli

Multi-Factor Authentication (OpenSSH 6.3+)

Recent versions of OpenSSH support MFA (Multi-Factor Authentication). Using MFA is recommended where possible.

It requires additional setup, such as using the OATH Toolkit or DuoSecurity.

ATTENTION In order to allow using one time passwords (OTPs) and any other text input, Keyboard-interactive is enabled in OpenSSH. This MAY allow for password authentication to work. It is therefore very important to check your PAM configuration so that PAM disallow password authentication for OpenSSH.

OpenSSH 6.3+ (default)

File: /etc/ssh/sshd_config

OpenSSH 5.3+ w/ RedHat/CentOS patch (old)

File: /etc/ssh/sshd_config

PAM configuration for use with the OATH Toolkit or DuoSecurity as second authentication factor.

File: /etc/pam.d/sshd

The PAM stack in this scenario executes the following logic (in our example wefollow the flow with pam_duo.so in use)

• The pam_sepermit.so module is called which checks if the user attempting tolog in via SSH is present in the /etc/security/sepermit.conf.If the user is present in the config file, and the config asserts that the usercan only log in if SELinux is enforcing, and SELinux is not enforcing, thenthe PAM control of required prevents the user from logging in (though PAMwould continue down the stack).
• The password-auth include is commented out and skipped
• The /lib64/security/pam_duo.so module is called and the user is prompted fora duo MFA code.
  • If the code provided is correct PAM immediately permits the user access anddoesn’t continue executing.
  • If the code provided is incorrect, PAM continues down the stack
• The pam_nologin.so checks if the file /etc/nologin exists and if so blocksaccess to the user.
• If at the end of the stack, the single sufficient control of pam_duo.sodid not return a success, PAM defaults to deny and denies the login.

Ciphers and algorithms choice

• When CHACHA20 (OpenSSH 6.5+) is not available, AES-GCM (OpenSSH 6.1+) and any other algorithm using EtM (Encrypt then MAC) disclose the packet length - giving some information to the attacker. Only recent OpenSSH servers and client support CHACHA20.
• NIST curves (ecdh-sha2-nistp512,ecdh-sha2-nistp384,ecdh-sha2-nistp256) are listed for compatibility, but the use of curve25519 is generally preferred.
• SSH protocol 2 supports DH and ECDH key-exchange as well as forward secrecy. Regarding group sizes, please refer to Key management Guidelines.

The various algorithms supported by a particular OpenSSH version can be listed with the following commands:

Configuration

If you have a file containing known_hosts using RSA or ECDSA host key algorithm and the server now supports ed25519 for example, you will get a warning that the host key has changed and will be unable to connect. This means you will have to verify the new host key.

The following configurations expect a recent OpenSSH client, as updating OpenSSH on the client side is generally not an issue.

Modern

This configuration is less compatible and you may not be able to connect to some servers which use insecure, deprecated algorithms. Nevertheless, modern servers will work just fine.

File: ~/.ssh/config

Intermediate (connects to older servers)

This configuration can connect to older OpenSSH servers which run old or intermediate configurations.

File: ~/.ssh/config

Key generation

Large key sizes are used as SSH keys are not renewed very often (see also Key management Guidelines).

Don’t hesitate to create multiple different keys for different usages. In particular, never mix your personal and Mozilla keys.

You may then want to add the new key to your SSH agent or your configuration file (or both).

Protection of user keys

• Protected by strong passphrase.
• Never copied to another system than your own workstation/personal physical disks/tokens.
• Use SSH forwarding or SSH tunneling if you need to jump between hosts. DO NOT maintain unnecessary agent forwarding when unused.

Protection of machine keys

When SSH keys are necessary for automation between systems, it is reasonable to use passphrase-less keys.

• The recommended settings are identical to the user keys.
• The keys must be accessible only by the admin user (root) and/or the system user requiring access.
• Usage of machine keys should be registered in an inventory (a wiki page, ldap, an inventory database), to allow for rapid auditing of key usage across an infrastructure.
• The machine keys should be unique per usage. Each new usage (different service, different script called, etc.) should use a new, different key.
• Only used when strictly necessary.
• Restrict privileges of the account (i.e. no root or “sudoer” machine account).
• Using a ForceCommand returning only the needed results, or only allowing the machine to perform SSH-related tasks such as tunneling is preferred.
• Disable sftp if not needed as it exposes more surface and different logging mechanisms than SSH (and thus scp) itself.

Multi-factor bypass setup for machine keys

Machine keys do not play well with multi-factor authentication as there is no human interaction.

• All logins from machine accounts should be protected by an additional authentication layer (VPN, another machine, etc.).
• All logins from machine accounts are only allowed within the private IP-space, and if possible, only the relevant machine source IPs should be accessible.

File: /etc/ssh/sshd_config (OpenSSH 6.3+)

File: /etc/ssh/sshd_config (OpenSSH 5.3+ w/ RedHat/CentOS patch)

Auditing your existing SSH keys

Existing keys are generally stored in ~/.ssh/ (Linux/OSX) or %APPDATA% (Windows). Look for id_{rsa,ed25519,ecdsa,dsa}, identity, IdentityFile, *.pem, and other identity files.

Display SSH keys information

SSH agent forwarding

ATTENTION SSH Agent forwarding exposes your authentication to the server you’re connecting to. By default, an attacker with control of the server (i.e. root access) can communicate with your agent and use your key to authenticate to other servers without any notification (i.e. impersonate you).For this reason, one must be careful when using SSH agent forwarding. Defaulting to always forwarding the agent is strongly discouraged.Note also that while the attacker can use your key as long as the agent is running and forwarded, he cannot steal/download the key for offline/later use.

SSH forwarding allows you to jump between hosts while keeping your private key on your local computer. This is accomplished by telling SSH to forward the authentication requests back to the ssh-agent of your local computer. SSH forwarding works between as many hosts as needed, each host forwarding new authentication request to the previous host, until the ssh-agent that holds the private key is reached.

On each host, two environment variables are declared for the user enabling ssh-agent:

• $SSH_AUTH_SOCK declares the location of the unix socket that can be used to forward an authentication request back to the previous host.(ex: /tmp/ssh-NjPxtt8779/agent.8779). Only present if using SSH agent forwarding.
• $SSH_CONNECTION shows the source IP and port of the previous host, as well as the local IP and port. (ex: 10.22.248.74 44727 10.8.75.110 22).

To use ssh-agent, add the flag -A to your ssh commands:

You can set the following configuration parameter in your local ssh configuration at ~/.ssh/config.

Hardening the Agent forwarder

It is possible to require confirmation every time the agent is used (i.e. when you connect to a server through the SSH agent) by using the -c flag:

It is also possible to lock the key in the agent after a configurable amount of time, this can be done either for all keys when starting the agent, or per key when adding the keys to the agent with the -t flag:

For MacOSX in particular it’s possible to save the passphrase in the Keychain. If you do so it is strongly recommended to also change the keychain setting to lock itself when the computer is locked, and/or to timeout and lock the keychain. These settings are not controlled by OpenSSH.

Recommended, safer alternatives to SSH agent forwarding

OpenSSH >=7.3

OpenSSH 7.3 onwards allow users to jump through several hosts in a rather automated fashion. It has full support for scp and sftp commands as well as regular ssh.

For example to reach a host behind a bastion/jumphost:

You can also add these lines to your ~/.ssh/config

Older versions of OpenSSH

It is possible to directly forward ports for single jumps instead of forwarding the agent. This has the advantage of never exposing your agent to the servers you’re connecting to.

For example, you can add these lines to your ~/.ssh/config

This will automatically forward the SSH connection over ssh.mozilla.com when you connect to a mozilla.com SSH server.

Key material handling

Key material identifies the cryptographic secrets that compose a key. All key material must be treated as MOZILLA CONFIDENTIAL GROUP RESTRICTED data, meaning that:

• Only individual with specific training and need-to-know should have access to key material.
• Key material must be encrypted on transmission.
• Key material can be stored in clear text, but only with proper access control (limited access).

This includes:

• OpenSSH server keys (/etc/ssh/ssh_host_*key)
• Client keys (~/.ssh/id_{rsa,dsa,ecdsa,ed25519} and ~/.ssh/identity or other client key files).

Client key size and login latency

In order to figure out the impact on performance of using larger keys - such as RSA 4096 bytes keys - on the client side, we have run a few tests:

On an idle, i7 4500 intel CPU using OpenSSH_6.7p1, OpenSSL 1.0.1l and ed25519 server keys the following command is ran 10 times:

time ssh localhost -i .ssh/id_thekey exit

Results:

Client key	Minimum	Maximum	Average
RSA 4096	120ms	145ms	127ms
RSA 2048	120ms	129ms	127ms
ed25519	117ms	138ms	120ms

Keep in mind that these numbers may differ on a slower machine, and that this contains the complete login sequence and therefore is subject to variations. However, it seems safe to say that the latency differences are not significant and do not impact performance sufficiently to cause any concern regardless of the type of key used.

Reference documents

2.1 Setting Up SSH on a Server

As a prerequisite, it is recommended that you install the Apache Administration server if it wasn’t installed by default. The Apache Administration server is normally installed by default unless you installed a special-purpose server that didn’t require it, such as iLogin, DNS/DHCP, Pre-migration NetWare^®, Virtual Office, or Novell^® Branch Office.

You can install OpenSSH on a server either as an optional component during the NetWare custom installation or after installing NetWare using the following procedure:

1. Insert the NetWare 6.5 Operating System CD into the CD-ROM drive of the server where you want to install OpenSSH.

2. Start the NetWare GUI by entering startx at the system console prompt.

3. Click Novell > Install > Add.

4. In the Source Path dialog box, type the path or browse to the CD.

5. Select the postinst.ni response file, then click OK.

6. On the Install Components page, select Secure Shell from the products list.

7. Click Next.

8. When prompted, enter the administrator username, password, and context.

9. Follow the remaining prompts.

10. Click OK.

IMPORTANT:After upgrading from a NetWare 5.1 server with eDirectory™ 7.x to a NetWare 6.5 server (which upgrades eDirectory to version 8.7), User objects don’t have a uniqueid attribute, which is used by sshd for authentication. As a result, sshd falls back to the CN attribute, which is no longer public after the upgrade. The admin user must then make the CN attribute public in ConsoleOne^® or iManager.

2.1.1 Completing Post-Installation Configuration

After the installation, you need to complete some additional configuration before you or your users can access files on the server.

1. Load the sshd.nlm file at the server.

2. (Optional) Edit the sys:etcsshsshd_config file to change any settings from the default.

3. (Optional) Add users and public keys into sshd.bag.

IMPORTANT:OpenSSH often reports an error trying to configure the product during a remote upgrade. To fix the configuration problems, edit sys:etcsshsshd_config and update the default <Your-Context> tag with the admin user’s context. You must also ensure that admin users have the Supervisor trustee right to the NCP™ Server object for each server in the tree that they administer. A local post-install of the OpenSSH product (from the GUI on the server) also corrects the configuration issues.

Understanding the Components

After you set up OpenSSH on your NetWare server, it should contain the components listed in Table 2-1 in the indicated locations.

Table 2-1 OpenSSH Component Locations

File	Location	Description
sshd.nlm	sys:/system	OpenSSH version 3.6p1 ported to NetWare 6.5 This is the daemon for the SSH program. It provides secure encrypted communications between two untrusted hosts over an insecure network This daemon listens for the connections from clients
sshd_config	sys:/etc/ssh	System-wide configuration file for the SSH daemon. The daemon reads the configuration file and executes the commands it receives based on the file's settings You can edit this file manually or through the Web administration utility. For more information, see Editing the Configuration File
ssh_host_key	sys:/etc/ssh	Private host key used to authenticate the server for the SSH protocol versions 1.3 and 1.5
ssh_host_rsa_key	sys:/etc/ssh	Private host key used to authenticate the server for the SSH protocol version 2.0 using RSA encryption
ssh_host_dsa_key	sys:/etc/ssh	Private host key used to authenticate the server for the SSH protocol version 2.0 using DSA encryption
sshjni.nlm	sys:/system	Secure Shell JNI Web support
sshlogd.nlm	sys:/system	Secure Shell log daemon that generates the sshd.log file, which contains all errors sent from all ssh-type NLM™ programs such as sshd, ssh, sftp, and scp This NLM is not a standard ssh file. This ssh module only exists on the NetWare platform
ssh-pubuadd	sys:/system	Adds a user plus the user’s public key to the local secret store bag
ssh-pubudel	sys:/system	Deletes a user from the local secret store bag
ssh-pubulist	sys:/system	Lists users in the local secret store bag

Editing the Configuration File

The sshd_config file is located in sysetcssh. You can edit this file manually with any text editor. If your server has been set up with a DNS name, you can make changes to the file using the OpenSSH Admin utility.

We recommend making changes to the configuration using the OpenSSH Manager (OpenSSH Admin) utility because it eliminates syntax errors that you might make editing the file manually. If you manage OpenSSH on multiple servers, we recommend using this utility to import the configuration file to the eDirectory 8.7.3 mode and then also managing the configuration with the utility.

IMPORTANT:The Apache Admin utility must be installed and set up in order to use the OpenSSH Admin utility.

To access this utility from a browser (Netscape* 6.x or later or IE 5.5 or later):

1. Enter https://ip_address or server_dns_name:2200, then click the SSHD Admin link under the OpenSSH Server heading.

2. Type the password information.

3. Ensure the information automatically inserted into the following fields is applicable to the user and server that you want to log in to:

   • User Name

   • LDAP Provider Domain Name

   • Port Number 636 (or whatever it has been changed to)

   • The Use SSL Connection check box (checked)

     If this check box is not checked, your password to log in to sshd will be exposed in clear text.

   • The initial LDAP context

Changing the Options

The following table shows the options that you can change in the sshd_config file and the links that you can use for them in the OpenSSH Admin utility. All keyword purposes and options are specified in the sshd_config man pages unless they are specific to a NetWare implementation.

Table 2-2 sshd_config Options

Option	Description	Link in Admin Utility
AllowSSHSessions	Specifies whether or not sshd should allow SSH console session access. The default is Yes.	Security
AuthorizedKeyFile	Path to the file that contains the authorized keys. The default is .sshauthorized _keys.	Ignored
ChallengeResponseAuthentication	Challenges the user to supply authentication credentials. If the user responds with correct credentials, authentication is allowed. This is currently the only way to authenticate to a NetWare server with OpenSSH. The default is Yes.	Authentication
ClientAliveCountMax	Number of client alive messages that can be sent without sshd requiring any messages back from the client. If this threshold is reached while client alive messages are being sent, sshd disconnects the client, terminating the session. This is very different from KeepAlive. The client alive messages are sent through the encrypted channel and, therefore, are not spoofable. Messages sent by KeepAlive are spoofable. The client alive mechanism is valuable when the client or server depends on knowing when a connection has become inactive. If ClientAliveCountMax is set to 2, unresponsive SSH clients are disconnected after approximately 30 seconds. If ClientAliveInterval is set to 15, and ClientAliveCountMax is left at the default, unresponsive SSH clients are disconnected after approximately 45 seconds. The default is 3.	Connection
ClientAliveInterval	Timeout interval (in seconds) after which, if no data has been received from the client, sshd sends a message through the encrypted channel to request a response from the client. The default is 0 (no messages sent). This option applies to protocol version 2 only.	Connection
Compression	Enables or disables compression, which reduces traffic on a low-bandwidth connection. The default is Yes (enabled).	Connection
DOSFTPMultiServerNavigation	Enables or disables multi-server navigation. If set to Yes, a server name is added to the path, as in /servername/volume/dir_path. If set to No, the path is /volume/dir_path. The default is Yes (enabled).	File System
eDirNameContext	Search context. Use this to expand or limit access to the tree. To enable users in this context only to authenticate to sshd: o=org To allow users in this context and all subcontexts to authenticate to sshd: o=org?scope=subtree To search for a user in multiple contexts: context context?scope=subtree This setting is unique to a NetWare implementation.	eDirectory
HostKey	These keys are generated during the OpenSSH installation on NetWare: etcsshssh_host_key etcsshssh_host_rsa_key etcsshssh_host_dsa_key	Host Keys
IgnoreRemoteHomeDir	Specifies whether sshd should ignore the user’s home directory unless on the destination server. The default is No.	File System
IgnoreUserKnownHosts	Specifies whether sshd should ignore the user’s $home/.ssh/known_hosts file during RhostsRSAAuthentication or HostbasedAuthentication. This file contains a copy of the key that the host sent the last time a connection was made. If the file is not ignored, the server prompts the user every time that user attempts to connect, asking whether the key should be accepted. The default is No.	Authentication
KeepAlive	Specifies whether the system should send TCP keepalive messages to the other side. If they are sent, events such as the termination of the connection or the crash of one of the machines are noticed. However, this means that connections terminate if the route is down temporarily. The client detects whether the network goes down or the remote host crashes. The default is Yes.	Connection
KeyRegenerationInterval	Time (in seconds) between regeneration of keys. This prevents decrypting captured sessions by later breaking into the machine and stealing the keys. The key is never stored anywhere. If the value is 0, the key is never regenerated. The default is 3600.	Authentication
ListenAddress	Address for the SSH client to listen on. The default is 0.0.0.0	Listen Address
LoginBannerFile	Path to a file that contains a greeting or specific banner text that displays when the user logs in to the server using an SSH client. Recommended path: sys:etcssh The default is None.	Connection
LoginGraceTime	Time interval (in seconds) before the server disconnects if the user has not successfully logged in. If the value is set to 0, there is no time limit. The default is 600.	Connection
LogLevel	Verbosity level that is used when logging messages from sshd. The default is Info.	Log Preferences
LogMaxFileSize	Size (in MB) for the log files. The default is 4. This setting is unique to a NetWare implementation.	Log Preferences
LogMaxRotateFiles	Maximum time (in hours) for logging to occur in one file if the default size is not reached. The default is 7. This setting is unique to a NetWare implementation.	Log Preferences
LogPath	Path to the log file. The recommended location is sys:etcsshlogs. This setting is unique to a NetWare implementation.	Log Preferences
LogRotationInterval	Maximum time (in hours) for logging to occur in one file if the default size is not reached. The default is 24. This setting is unique to a NetWare implementation.	Log Preferences
PasswordAuthentication	Uses a username and password to verify a user’s identity. This is currently the only way to authenticate to a NetWare server with OpenSSH. Even if you do not select Yes to enable Password Authentication, Password Authentication is still used for NetWare servers. The default is Yes.	Authentication
Port	Port for SSH to listen on. The default is Port 22.	Listen Ports
Protocol	Versions of the SSH protocol that are supported.	Miscellaneous
ProxyName username ProxyPassword password	Specifies the proxy user and password for LDAP searches. This is useful when anonymous binds are disabled. The username must be in fully-qualified LDAP format; for example, cn=admin,o=novell.	Authentication
PubKeyAuthentication	Uses cryptographic keys to verify a user’s identity. A public key is stored on the server. When a user attempts to authenticate, that user’s private key is verified against the public key to authenticate the user. This is currently the only way to authenticate to a NetWare server with OpenSSH. The default is Yes.	Authentication
RSAAuthentication	Allows/disables authentication using identity keys encoded with the Rivest-Shamir-Adleman (RSA) algorithm. This is currently the only way to authenticate to a NetWare server with OpenSSH. The default is Yes. This option applies to protocol version 1 only.	Authentication
ServerKeyBits	Number of bits in the ephemeral protocol version 1 server key. The larger the number of bits, the more secure the key is. If the server detects a change in this number, there could possibly be a security breech. The default is 768.	Authentication
VerifyReverseMapping	Specifies whether sshd should try to verify the remote hostname and whether the authentication request is coming from the IP address it claims to be coming from. The default is No.	Authentication

2.1.2 Public/Private Key Security Risks

Supporting public/private key authentication in OpenSSH introduces some security issues that you need to be aware of.

One User Can Masquerade as Another

A user could use SSH to send his key with the Fully Distinguished Name (FDN) of another user to gain access to the system as the other user.

For example, say you are user Sally on Linux system Foo and you want to ssh into NetWare system Bar with the intent of gaining admin permissions. On Foo, you generate ssh keys as Sally. On Bar, you add those keys into the local secret store with the Admin user’s FDN using the following command:

ssh-pubuadd -n cn=admin,o=novell -k ./sally.pub

This example assumes that the administrator of Bar has previously added Admin into the secure bag and that the password was set in a previous session.

Now, on Foo, you can enter the following command to gain the eDirectory permissions of the Admin user:

sftp cn=admin,o=novell@bar

To counter this threat, NetWare administrators must do the following:

• Verify that the user’s FDN matches the name of the user before adding the FDN and key into the secure bag.

• Secure the console so that commands such as ssh-pubuadd can not be run by unauthorized users.

Secure Bag Maintenance

The ssh daemon secure bag, sshd.bag, can not be copied to another server. It is good practice to save a copy of the sshd.bag file for migration to other servers or in the unlikely case of bag file corruption.

Openssh 6.5 Download

• To export the secure bag information to a backup text file, enter the following command:

  ssh-pubulist -b > sshd-bag.bak

  The resulting text file does not contain passwords. They will have to be re-entered in another interactive session.

• To import entries from the backup file into a new secure bag, enter the following command:

  ssh-pubuadd -b ./sshd-bag.bak