Please consider subscribing to LWN Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.

The next stable release of OpenSSH, version 6.7, is slated toarrive soon. In addition to the usual bevy of fixes and updates, thisrelease will introduce several new features, and it will be the firstrelease to showcase the project's efforts to refactor the OpenSSHcodebase.

Damien Miller put out a callfor testing on August 18, asking users to give the 'portable'version (that is, the releases notintended for OpenBSD) of the latest OpenSSH snapshots a spin on a variety ofplatforms. As is usually the case, the new release features severalchanges to the suite of available ciphers and algorithms (includingsome removals as well as adjustments to the default settings). Butthere are also several brand-new additions to OpenSSH functionalitythat will debut with the upcoming release.

How to change SSH port on Centos 6, 7, and 8. The full form of SSH is Secure Shell daemon, so it is a network protocol used for performing remotely secure logins for the Linux systems through a secured channel by an unsecured network using robust cryptography. OpenSSH will begin to install and configure itself for your system. At this point, openssh is setup and configured for your system. To try this out, open up a command prompt (cmd.exe) and try: ssh -v (For OpenSSH 6.3 and below) ssh -V (For OpenSSH 6.4 and above).

Openssh For Windows 10

Features

Among the new features is support for Unix domain socket forwarding. This featureallows a Unix domain socket on the local machine to be forward to aremote TCP port, or a remote TCP port to be forwarded to a localUnix domain socket—using the same syntax that OpenSSH supports forforwarding to TCP ports. For example, a remote PostgreSQL databaseinstance could be connected over a secure SSH channel to a Unix domain socket onthe local machine withssh -L/tmp/foo.sock:mydatabase.net:5432 someserver.It is also possible to connect two local Unix domainsockets over an SSH connection.

Several years ago, this functionality was availablein a patch set by William Ahern. The last update to Ahern's code,however, was made in 2012 for OpenSSH 6.1. The new feature is areimplementation of the same work.

A related feature was added to support the Unix domain-socketforwarding. The escape sequence %C can be used in both the LocalCommand and ControlPath arguments of aconfiguration file. It expands to a unique identifier derived fromthe SHA-1hash of(local host, remote user, hostname, port).The other escape sequences (such as %h for remote hostnameand %u for local username) are often used with theexpectation that, when expanded, they will comprise a uniqueidentifier. However, the addition of Unix domain sockets meant that somepossible use cases were bumping up against system pathname maximumlengths (UNIX_PATH_MAX); the hash value of %C is aworkaround, providing a fixed-length (40-character) identifier, although itcertainly may prove useful in other circumstances as well.

The new release will also expand OpenSSH's support for looking upSSH key fingerprints through DNS. OpenSSH's support for the DNS SSHFingerprint Publishing (originally described in RFC 4255) includedElliptic Curve DSA (ECDSA) keys (described in the RFC 6594 extension).Version 6.7 will also support keys generated with Ed25519. The Ed25519 keys arenot yet described in an official IETF RFC (although there is a draftunder development). As the name probably makes clear, the new keytype is derived from Daniel J. Bernstein's highly optimizedCurve25519,which has been the basis of so much recent cryptography work.

Fixes

Several smaller but still noteworthy changes in 6.7 include theability to resume interrupted uploads in SFTP connections, aconfiguration parameter administrators can set to disable theexecution of per-user ~/.ssh/rc configuration files, and moreinformative failure messages (logging user, source address, and portfor authentication failures). There are also several bugfixes thatmay be of interest to some users, such as the fix for a bug thatwould mistakenly rewrite localhost IP addresses in port-forwardingrequests.

Undoubtedly of more general interest, though, are the fixes thattarget unsafe algorithms and options. Three such fixes are mentionedexplicitly in Miller's call-for-testing email. First, RC4 andCipher-block chaining (CBC) mode have both been removed from the default setof available ciphers and message-authentication code algorithms insshd. They are now considered unsafe; users who need themfor backward-compatibility purposes can re-enable them withsshd_config.

Second, support for TCP wrappers (and the libwrap library) is beingremoved. Miller noted on the development list in April that the samefunctionality was already available through sshd_config'sMatch keyword—and, more importantly, usingMatch is both more flexible and (because it removes anexternal dependency) safer for the project in the long run. Duringthe April discussion, it was suggested that patching libwrap supportback into OpenSSH 6.7 should be doable without too much trouble, incase there are users who feel they cannot transition to a non-libwrap setup.

Finally, OpenSSH 6.5 and 6.6 both suffered from a bug that wouldoccasionally cause connection failures when using thecurve25519-sha256@libssh.org key-exchange method. As aresult, version 6.7 disables that key-exchange method when it connectsto either of the affected older releases. Unlike the other twobackward-incompatible fixes, however, there is no workaround in placefor OpenSSH 6.7—though why one would want to reintroduce a bugthat intermittently caused connection failures is difficult toimagine.

(Re) Factoring

In addition to the new features and bugfixes, version 6.7 will markthe first release to come from the OpenSSH project's effort torefactor the codebase—with the eventual goal of separating outthe core functionality from the client and server code, thus making anOpenSSH library available for use by other applications. The 6.7release will not be usable in such a 'libopenssh' manner; however, itis a first step along the path. Cisco duo ise anyconnect. The wire-parsing, key-handling, andkey-revocation list code has been refactored in time for the newrelease. The API those components use, though, is far from stableand should not be targeted by other applications.

The eventual goal of the refactoring work is to spare outsideapplications from having to fork a separate process in order to useOpenSSH functionality. That would make OpenSSH a viable alternativeto some existing libraries like libssh. And there are a lot of potential usesfor such a library—everything from rsync to SSHFS can make use ofSSH tunneling, and OpenSSH is the de facto option for manyusers. Furthermore, theidea itself is quite old within OpenSSH; the first bug reportto request it was opened in 2002.

The project has not set any sort of timeline for when a libraryversion might debut. At the moment, the refactoring process is stillgoing on, although there are unit tests and fuzz tests in thecodebase, so interested users can do some experimentation.

Neither is there a release date set yet for OpenSSH 6.7 itself, ofcourse. It will be released when ready. But when it does arrive, theavailability of SSH-tunneled Unix domain sockets (along with the rest of thenew feature set) will likely establish it as a release many will want tomake use of, library or not.

Index entries for this article
Security	OpenSSH

(Log in to post comments)

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.

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

Openssh For Windows

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.

Openssh 6.7p1

• 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:

Gt racing motor academy mod apk. 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: Affinity photo raw editing.

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