Download OpenSSH 9.3 Download | TechSpot

In addition, OpenSSH offers a large suite of secure tunneling capabilities, multiple authentication methods, and sophisticated configuration options.

The OpenSSH package consists of the following tools:

• Remote operations are performed using ssh, scp and sftp.
• Key management with ssh-add, ssh-keysign, ssh-keyscan and ssh-keygen.
• The service side consists of sshd, sftp server and ssh agent.

OpenSSH is developed by a few developers of the OpenBSD Project and made available under a BSD-style license.

Characteristics

• Completely open source project with free licensing
• The OpenSSH source code is freely available to anyone via the Internet. This encourages code reuse and code revision. Code review ensures that bugs can be found and fixed by anyone. This results in secure code. OpenSSH is not covered by any restrictive license. It can be used for any purpose, and that includes explicit commercial use. The license is included in the distribution. We feel the world would be a better place if routers, network appliances, operating systems and all other network devices had ssh integrated into them. All components of a restrictive nature (ie patents) have been removed from the source code. All licensed or patented components are selected from external libraries (eg LibreSSL).
• Strong cryptography (AES, ChaCha20, RSA, ECDSA, Ed25519…)
• Encryption is started before authentication, and no password or other information is transmitted in clear text. Encryption is also used to protect against counterfeit packets. A number of different ciphers and key types are available, and older options are usually phased out over a reasonable period of time.
• X11 forwarding (which also encrypts X Window System traffic)
• X11 forwarding allows encryption of external X windows traffic, so no one can snoop on external xterms or insert malicious commands. The program automatically sets DISPLAY on the server machine, and forwards any X11 connections over the secure channel. False Xauthority information is automatically generated and forwarded to the remote machine; the local client automatically examines incoming X11 connections and replaces the fake authorization data with the real data (never telling the remote machine the real information).
• Port forwarding (encrypted channels for legacy protocols)
• Port forwarding allows forwarding of TCP/IP connections to a remote machine over an encrypted channel. Insecure internet applications such as POP can be secured with this.
• Strong authentication (public keys, one-time passwords)
• Strong authentication protects against several security issues: IP spoofing, fake routes, and DNS spoofing. Some authentication methods include public key authentication, one-time password with s/key, and authentication using Kerberos (in -portable only).
• Agent forwarding
• An authentication agent, running on the user’s laptop or local workstation, can be used to hold the user’s authentication keys. OpenSSH automatically forwards the connection to the authentication agent over all connections, and there is no need to store the authentication keys on any machine on the network (except the user’s own local machine). The authentication protocols never reveal the keys; they can only be used to verify that the user agent has a particular key. Eventually, the agent could rely on a smart card to perform all authentication calculations.
• Interoperability
• Interoperability between implementations is a goal, but not a promise. As OpenSSH development progresses, older protocols, ciphers, key types, and other options that have known weaknesses are routinely disabled. Some examples can be found on the older page.
• Support for SFTP client and server.
• Complete SFTP support is included, using the sftp(1) command as a client and the sftp-server(8) subsystem as a server.
• Optional data compression
• Data compression before encryption improves performance for slow network links.

What is new

OpenSSH 9.1 was released on 2022-10-04. OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support.

• It is now possible[1] to perform selected prefix attacks against
• SHA-1 Algorithm for less than USD$50K.
• In the SSH protocol, the “ssh-rsa” signature scheme uses the SHA-1 hash algorithm in conjunction with the RSA publication key algorithm. OpenSSH will disable this signature scheme by default in the near future.
• Note that disabling “ssh-rsa” signatures does not necessarily require deprecation of RSA keys. In the SSH protocol, keys may be able to sign using multiple algorithms. In particular, “ssh-rsa” keys are capable of signing with “rsa-sha2-256” (RSA/SHA256), “rsa-sha2-512” (RSA/SHA512) and “ssh-rsa” (RSA/SHA1 ). Only the last of these is turned off by default.
• This algorithm is unfortunately still widely used despite the existence of better alternatives, and is the only remaining public key signature algorithm specified by the original SSH RFCs that is still enabled by default.

Safety

• This release contains fixes for three minor memory security issues. None are believed to be exploitable, but we report most memory security issues as potential security vulnerabilities out of caution.
• ssh-keyscan(1): fix a one-byte overflow in SSH banner processing. Reported by Qualys

Potentially incompatible changes

This release contains a number of changes that may affect existing configurations:

• ssh(1), sshd(8): this release changes the first-preference signature algorithm from ECDSA to ED25519.
• ssh(1), sshd(8): set TOS/DSCP specified in configuration for interactive use before TCP connection. The connection phase of the SSH session is time-sensitive and often explicitly interactive. The ultimate interactive/bulk TOS/DSCP will be set after authentication is complete.
• ssh(1), sshd(8): remove pre-standardization cipher [email protected]. It is an alias for aes256-cbc before it was standardized in RFC4253 (2006), has been deprecated and disabled by default since OpenSSH 7.2 (2016) and was only briefly documented in ssh.1 in 2001.
• ssh(1), sshd(8): update/replace the experimental post-quantum hybrid key exchange method based on Streamlined NTRU Prime combined with X25519.
• The previous [email protected] method has been replaced with [email protected]. According to its designers, the sntrup4591761 algorithm was replaced almost two years ago by sntrup761. (note that both the updated method and the one it replaced are disabled by default)
• ssh(1): disable CheckHostIP by default. It provides negligible benefits while making key rotation significantly more difficult, especially for hosts behind IP-based load balancers.

Changes

New functions

• ssh(1): this release enables UpdateHostkeys by default subject to some conservative assumptions:
  • The key was matched in UserKnownHostsFile (and not in GlobalKnownHostsFile).
  • The same key does not exist under a different name.
  • A certificate host key is not in use.
  • known_hosts does not contain a matching wildcard hostname.
  • VerifyHostKeyDNS is not enabled.
  • The default UserKnownHostsFile is in use.
  • We expect that some of these conditions will be changed or relaxed in the future.
• ssh(1), sshd(8): add a new LogVerbose configuration directive for which allows to force maximum debug logging of file/function/line pattern lists.
• ssh(1): when asking the user to accept a new host key, show any other hostnames/addresses already associated with the key.
• ssh(1): let UserKnownHostsFile=none indicate that no known_hosts file should be used to identify host keys.
• ssh(1): add an ssh_config KnownHostsCommand option that allows the client to retrieve known_hosts data from a command in addition to the regular files.
• ssh(1): add an ssh_config PermitRemoteOpen option that allows the client to restrict the destination when RemoteForward is used with SOCKS.
• ssh(1): for FIDO keys, if a signature operation fails with an “incorrect PIN” reason and no PIN was initially requested from the user, request a PIN and retry the operation. This supports some biometric devices that fall back to requiring a PIN when reading biometric errors, and devices that require PINs for all host credentials.
• sshd(8): implement client address-based rate limiting via new sshd_config(5) PerSourceMaxStartups and PerSourceNetBlockSize directives that provide more fine-grained control on a per-origin address basis than the global MaxStartups limit.

Error corrections

• ssh(1): Prefix keyboard interactive messages with “(user@host)” to make it easier to figure out what connection they’re associated with in cases like scp -3, ProxyJump, etc. bz#3224
• sshd(8): fix sshd_config SetEnv directives nested inside Match blocks. GHPR201
• ssh(1): when requesting a FIDO token touch on stderr, inform the user when the touch is registered.
• ssh(1): prevent integer overflows when ridiculously large ConnectTimeout values ​​are specified, limiting the effective value (for most platforms) to 24 days. bz#3229
• ssh(1): consider the ECDSA key subtype when ordering host key algorithms in the client.
• ssh(1), sshd(8): rename PubkeyAcceptedKeyTypes keyword to PubkeyAcceptedAlgorithms. The previous name incorrectly implied that it controls allowed keying algorithms, when this option actually specifies the signature algorithms that are accepted. The previous name remains available as an alias. bz#3253
• ssh(1), sshd(8): rename HostbasedKeyTypes (ssh) and HostbasedAcceptedKeyTypes (sshd) to HostbasedAcceptedAlgorithms.
• sftp-server(8): add missing [email protected] documentation and advertisement in server’s SSH2_FXP_VERSION hello packet.
• ssh(1), sshd(8): enforce KEX state machine more strictly by disallowing packet types when received. Fix mem leak caused by duplicate SSH2_MSG_KEX_DH_GEX_REQUEST (us-fuzz #30078).
• sftp(1): allow the full range of UIDs/GIDs for chown/chgrp on 32-bit platforms instead of being limited by LONG_MAX. bz#3206
• Minor manpage fixes (capitalization, commas, etc.) bz#3223
• sftp(1): when doing an sftp recursive upload or download of a read-only directory, make sure the directory is created with write and execute permissions in the meantime so that the transfer can actually complete, then set the directory permission as the final step. bz#3222
• ssh-keygen(1): document -Z, check the validity of the argument earlier and give a better error message if it’s not correct. bz#2879
• ssh(1): ignore comments at the end of config lines in ssh_config, similar to what we already do for sshd_config. bz#2320
• sshd_config(5): mentions that DisableForwarding is valid in an sshd_config Match block. bz3239
• sftp(1): fix wrong sorting of “ls -ltr” in some circumstances. bz3248.
• ssh(1), sshd(8): fix potential integer truncation of (unlikely) timeout values. bz#3250
• ssh(1): make host-based authentication send the signature algorithm in its SSH2_MSG_USERAUTH_REQUEST packets instead of the key type.
• This causes HostbasedAcceptedAlgorithms to do what they are supposed to – filter by signature algorithm and not key type.

Portability

• sshd(8): add a number of platform-specific syscalls to the Linux seccomp-bpf sandbox. bz#3232 bz#3260
• sshd(8): remove debug message from sigchld handler which can cause deadlock on some platforms. bz#3259
• Sync contribution/ssh-copy-id with upstream.
• unittests: add a hostname function for systems that don’t have it. Some systems do not have a hostname command (it is not required by POSIX). They have uname -n (which is), but not all of them report the FQDN.