[arch-dev-public] [signoff] openssh-5.7p1-1
Hi everyone, OpenSSH 5.7 has just been released. Due to Guillaume's work on this package, the upgrade was quite straightforward and openssh-5.7p1-1 is now in [testing]. All tests pass on both architectures. Enjoy your shiny new ECDSA keys! (And then please signoff.) -- Gaetan Changes since OpenSSH 5.6 ========================= Features: * 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 implemented. 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. bz#1733 * 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 BugFixes: * 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; bz#1812 * 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 read/write * 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.
On Mon, 2011-01-24 at 13:09 +0100, Gaetan Bisson wrote:
Hi everyone,
OpenSSH 5.7 has just been released. Due to Guillaume's work on this package, the upgrade was quite straightforward and openssh-5.7p1-1 is now in [testing]. All tests pass on both architectures.
Enjoy your shiny new ECDSA keys!
(And then please signoff.)
-- Gaetan
Changes since OpenSSH 5.6 =========================
Features:
* 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 implemented.
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. bz#1733
* 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
BugFixes:
* 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; bz#1812
* 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 read/write
* 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.
Signoff x86_64 -- Guillaume
Am Dienstag 25 Januar 2011 schrieb Guillaume ALAUX:
On Mon, 2011-01-24 at 13:09 +0100, Gaetan Bisson wrote:
Hi everyone,
OpenSSH 5.7 has just been released. Due to Guillaume's work on this package, the upgrade was quite straightforward and openssh-5.7p1-1 is now in [testing]. All tests pass on both architectures.
Enjoy your shiny new ECDSA keys!
(And then please signoff.)
Signoff x86_64 Is it normal that PAM is not activated by default, NX stopped working here because of this change in the sshd_config file.
greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
[2011-01-26 09:42:17 +0100] Tobias Powalowski:
Is it normal that PAM is not activated by default, NX stopped working here because of this change in the sshd_config file.
Following FS#20191, we decided to ship upstream's default sshd_config. In fact, this is already in openssh-5.6p1-2 in [core]. -- Gaetan
Am 26.01.2011 10:00, schrieb Gaetan Bisson:
[2011-01-26 09:42:17 +0100] Tobias Powalowski:
Is it normal that PAM is not activated by default, NX stopped working here because of this change in the sshd_config file.
Following FS#20191, we decided to ship upstream's default sshd_config.
In fact, this is already in openssh-5.6p1-2 in [core].
I agree with that. If you want to differ from the default config, do it locally on your system. Btw, signoff 64.
Am Mittwoch 26 Januar 2011 schrieb Thomas Bächler:
Am 26.01.2011 10:00, schrieb Gaetan Bisson:
[2011-01-26 09:42:17 +0100] Tobias Powalowski:
Is it normal that PAM is not activated by default, NX stopped working here because of this change in the sshd_config file.
Following FS#20191, we decided to ship upstream's default sshd_config.
In fact, this is already in openssh-5.6p1-2 in [core].
I agree with that. If you want to differ from the default config, do it locally on your system.
Btw, signoff 64. As far as i know pam should be used for logins, anyone else who has more information on this? Some config files have defaults that are not really correct.
greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Ok here is gentoo: PAM activated PasswordAuthentication no PrintMotd no PrintLastLog no checking fedora now. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Ok fedora does this: UsePAM yes ChallengeResponseAuthentication no PasswordAuthentication yes So I would say, enable at least PAM again in default config. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
[2011-01-26 11:14:30 +0100] Tobias Powalowski:
So I would say, enable at least PAM again in default config.
I do not understand why. I am a bit more confident in the ability of openssh upstream devs to configure their software as I am in Gentoo/Fedora's. PAM is only required for "advanced" kinds of authentication, so it seems quite logical to me that users would have to enable it themselves. -- Gaetan
On Wed, 2011-01-26 at 11:24 +0100, Gaetan Bisson wrote:
[2011-01-26 11:14:30 +0100] Tobias Powalowski:
So I would say, enable at least PAM again in default config.
I do not understand why.
I am a bit more confident in the ability of openssh upstream devs to configure their software as I am in Gentoo/Fedora's.
PAM is only required for "advanced" kinds of authentication, so it seems quite logical to me that users would have to enable it themselves.
I think we are dealing with 2 issues here: - do we ship the default upstream config file? - if answer to previous is No then which option do we set as default? We reverted back to the upstream conf to follow the Arch idea. We implicitly say "Power user, do your job when installing a SSH server". I understand your concern about minimum security but user should know how to configure an openSSH server if they need one. And if they don't maybe let's add an secure example in the wiki. -- Guillaume
[2011-01-26 11:29:56 +0100] Guillaume ALAUX:
We reverted back to the upstream conf to follow the Arch idea. We implicitly say "Power user, do your job when installing a SSH server". I understand your concern about minimum security but user should know how to configure an openSSH server if they need one. And if they don't maybe let's add an secure example in the wiki.
Just to clarify: The default sshd_config from upstream *is* secure. We are just talking about enabling (or not) features by default. -- Gaetan
On Wed, 2011-01-26 at 11:38 +0100, Gaetan Bisson wrote:
[2011-01-26 11:29:56 +0100] Guillaume ALAUX:
We reverted back to the upstream conf to follow the Arch idea. We implicitly say "Power user, do your job when installing a SSH server". I understand your concern about minimum security but user should know how to configure an openSSH server if they need one. And if they don't maybe let's add an secure example in the wiki.
Just to clarify: The default sshd_config from upstream *is* secure.
We are just talking about enabling (or not) features by default.
Just to clarify: The default sshd_config from upstream *is* secure. Agree
We are just talking about enabling (or not) features by default. I think we should leave it as is but I don't really mind. -- Guillaume
Am Mittwoch 26 Januar 2011 schrieb Guillaume ALAUX:
On Wed, 2011-01-26 at 11:38 +0100, Gaetan Bisson wrote:
[2011-01-26 11:29:56 +0100] Guillaume ALAUX:
We reverted back to the upstream conf to follow the Arch idea. We implicitly say "Power user, do your job when installing a SSH server". I understand your concern about minimum security but user should know how to configure an openSSH server if they need one. And if they don't maybe let's add an secure example in the wiki.
Just to clarify: The default sshd_config from upstream *is* secure.
We are just talking about enabling (or not) features by default.
Just to clarify: The default sshd_config from upstream *is* secure.
Agree
We are just talking about enabling (or not) features by default.
I think we should leave it as is but I don't really mind. -- Guillaume Now checked ubuntu too, USEPAM is enabled in most major distros, PAM is invoked in every login in Archlinux so I don't see a reason to not enable it by default.
# Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) ChallengeResponseAuthentication no # Change to no to disable tunnelled clear text passwords #PasswordAuthentication yes # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. UsePAM yes Shall we vote about it? greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
[2011-01-26 12:17:31 +0100] Tobias Powalowski:
Shall we vote about it?
Since my opinion is not as strong as yours seems to be, as far as I am concerned, we can just re-add ChallengeResponseAuthentication no UsePAM yes to sshd_config without the need for a vote (I assume devs who have something to say on this will just post it here). Unless, of course, somebody objects. -- Gaetan
Am Mittwoch 26 Januar 2011 schrieb Gaetan Bisson:
[2011-01-26 12:17:31 +0100] Tobias Powalowski:
Shall we vote about it?
Since my opinion is not as strong as yours seems to be, as far as I am concerned, we can just re-add
ChallengeResponseAuthentication no UsePAM yes
to sshd_config without the need for a vote (I assume devs who have something to say on this will just post it here). Unless, of course, somebody objects. Thanks :)
-- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Am 26.01.2011 12:17, schrieb Tobias Powalowski:
Now checked ubuntu too, PAM is invoked in every login in Archlinux so I don't see a reason to not enable it by default.
We should clarify a bit what PAM means for Arch and where the OpenSSH defaults come from: Ad 1) In Arch (and virtually any other general-purpose Linux-based operating system), PAM handles all kinds of authentication in a unique and configurable way. That includes console login, su, sudo, login manager and all kinds of remote authentication. Even most FTP, POP, IMAP, ... daemons can use it. It prevents daemons from having to implement their own custom authentication method. Ad 2) OpenSSH is developed for OpenBSD and ported to many systems. Not all of those systems have PAM, but the default configuration file is shipped on every system. Enabling PAM by default would restrict the default configuration file to only work on a small subset of those. In all systems that tpowa looked at, PAM is the default for any authentication, and OpenSSH is configured consistently with that. My conclusions: 1) I don't have a strong opinion on enabling PAM or not. For my applications, it works with or without. 2) From the above considerations, I conclude that it makes sense to enable PAM by default. In fact, we would need a very good reason not to. Please take this into account when deciding on the issue.
participants (5)
-
Gaetan Bisson
-
Guillaume ALAUX
-
Guillaume ALAUX
-
Thomas Bächler
-
Tobias Powalowski