Announce: OpenSSH 5.7 released

    Date24 Jan 2011
    Posted ByAlex
    OpenSSH 5.7 has just been released. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. Read on for a description of the improvements, including Elliptic Curve Cryptography, sftp performance improvements, and much more.
    OpenSSH 5.7 has just been released. It will be available from the
    mirrors listed at shortly.
    OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0
    implementation and includes sftp client and server support.
    Once again, we would like to thank the OpenSSH community for their
    continued support of the project, especially those who contributed
    code or patches, reported bugs, tested snapshots or donated to the
    project. More information on donations may be found at:
    Changes since OpenSSH 5.6
     * Implement Elliptic Curve Cryptography modes for key exchange (ECDH)
       and host/user keys (ECDSA) as specified by RFC5656. ECDH and ECDSA
       offer better performance than plain DH and DSA at the same equivalent
       symmetric key length, as well as much shorter keys.
       Only the mandatory sections of RFC5656 are implemented, specifically
       the three REQUIRED curves nistp256, nistp384 and nistp521 and only
       ECDH and ECDSA. Point compression (optional in RFC5656) is NOT
       Certificate host and user keys using the new ECDSA key types are
       supported - an ECDSA key may be certified, and an ECDSA key may act
       as a CA to sign certificates.
       ECDH in a 256 bit curve field is the preferred key agreement
       algorithm when both the client and server support it. ECDSA host
       keys are preferred when learning a host's keys for the first time,
       or can be learned using ssh-keyscan(1).
     * sftp(1)/sftp-server(8): add a protocol extension to support a hard
       link operation. It is available through the "ln" command in the
       client. The old "ln" behaviour of creating a symlink is available
       using its "-s" option or through the preexisting "symlink" command
     * scp(1): Add a new -3 option to scp: Copies between two remote hosts
       are transferred through the local host.  Without this option the
       data is copied directly between the two remote hosts. 
     * ssh(1): automatically order the hostkeys requested by the client
       based on which hostkeys are already recorded in known_hosts. This
       avoids hostkey warnings when connecting to servers with new ECDSA
       keys, since these are now preferred when learning hostkeys for the
       first time.
     * ssh(1)/sshd(8): add a new IPQoS option to specify arbitrary
       TOS/DSCP/QoS values instead of hardcoding lowdelay/throughput.
     * sftp(1): the sftp client is now significantly faster at performing
       directory listings, using OpenBSD glob(3) extensions to preserve
       the results of stat(3) operations performed in the course of its
       execution rather than performing expensive round trips to fetch
       them again afterwards.
     * ssh(1): "atomically" create the listening mux socket by binding it on
       a temporary name and then linking it into position after listen() has
       succeeded. This allows the mux clients to determine that the server
       socket is either ready or stale without races. stale server sockets
       are now automatically removed. (also fixes bz#1711)
     * ssh(1)/sshd(8): add a KexAlgorithms knob to the client and server
       configuration to allow selection of which key exchange methods are
       used by ssh(1) and sshd(8) and their order of preference.
     * sftp(1)/scp(1): factor out bandwidth limiting code from scp(1) into
       a generic bandwidth limiter that can be attached using the atomicio
       callback mechanism and use it to add a bandwidth limit option to
       sftp(1). bz#1147
     * ssh(1)/ssh-agent(1): honour $TMPDIR for client xauth and ssh-agent
       temporary directories. bz#1809
     * ssh(1): avoid NULL deref on receiving a channel request on an unknown
       or invalid channel; bz#1842
     * sshd(8): remove a debug() that pollutes stderr on client connecting
       to a server in debug mode; bz#1719
     * scp(1): pass through ssh command-line flags and options when doing
       remote-remote transfers, e.g. to enable agent forwarding which is
       particularly useful in this case; bz#1837
     * sftp-server(8): umask should be parsed as octal
     * sftp(1): escape '[' in filename tab-completion
     * ssh(1): Typo in confirmation message.  bz#1827
     * sshd(8): prevent free() of string in .rodata when overriding
       AuthorizedKeys in a Match block
     * sshd(8): Use default shell /bin/sh if $SHELL is ""
     * ssh(1): kill proxy command on fatal() (we already killed it on
       clean exit);
     * ssh(1): install a SIGCHLD handler to reap expiried child process;
     * Support building against openssl-1.0.0a
    Portable OpenSSH Bugfixes:
     * Use mandoc as preferred manpage formatter if it is present, followed
       by nroff and groff respectively.
     * sshd(8): Relax permission requirement on btmp logs to allow group
     * bz#1840: fix warning when configuring --with-ssl-engine
     * sshd(8): Use correct uid_t/pid_t types instead of int. bz#1817
     * sshd(8): bz#1824: Add Solaris Project support.
     * sshd(8): Check is_selinux_enabled for exact return code since it can
       apparently return -1 under some conditions.
     - SHA1 (openssh-5.7.tar.gz) = 67cb91772a33fb3a004b39bcdb9148218365494c
     - SHA1 (openssh-5.7p1.tar.gz) = 423e27475f06e1055847dfff7f61e1ac632b5372
    Reporting Bugs:
    - Please read
      Security bugs should be reported directly to This email address is being protected from spambots. You need JavaScript enabled to view it.
    OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt,
    Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and
    Ben Lindstrom.
    You are not authorised to post comments.

    LinuxSecurity Poll

    Do you reuse passwords across multiple accounts?

    No answer selected. Please try again.
    Please select either existing option or enter your own, however not both.
    Please select minimum 0 answer(s) and maximum 2 answer(s).

    We use cookies to provide and improve our services. By using our site, you consent to our Cookie Policy.