Age | Commit message (Collapse) | Author |
|
#762128).
|
|
booted using systemd (closes: #756547).
|
|
|
|
Takusagawa; closes: #757059).
|
|
|
|
|
|
|
|
|
|
|
|
LaMont Jones).
|
|
|
|
|
|
|
|
|
|
(thanks, Steffen Stempel; LP: #1312928).
|
|
|
|
curve25519-sha256@libssh.org, fixing occasional key exchange failures.
|
|
Hi,
So I screwed up when writing the support for the curve25519 KEX method
that doesn't depend on OpenSSL's BIGNUM type - a bug in my code left
leading zero bytes where they should have been skipped. The impact of
this is that OpenSSH 6.5 and 6.6 will fail during key exchange with a
peer that implements curve25519-sha256@libssh.org properly about 0.2%
of the time (one in every 512ish connections).
We've fixed this for OpenSSH 6.7 by avoiding the curve25519-sha256
key exchange for previous versions, but I'd recommend distributors
of OpenSSH apply this patch so the affected code doesn't become
too entrenched in LTS releases.
The patch fixes the bug and makes OpenSSH identify itself as 6.6.1 so as
to distinguish itself from the incorrect versions so the compatibility
code to disable the affected KEX isn't activated.
I've committed this on the 6.6 branch too.
Apologies for the hassle.
-d
Origin: upstream, https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-April/032494.html
Forwarded: not-needed
Last-Update: 2014-04-21
Patch-Name: curve25519-sha256-bignum-encoding.patch
|
|
|
|
|
|
prevent a hang on re-exec (thanks, Robie Basak; LP: #1306877).
|
|
If an ssh server presents a certificate to the client, then the client
does not check the DNS for SSHFP records. This means that a malicious
server can essentially disable DNS-host-key-checking, which means the
client will fall back to asking the user (who will just say "yes" to
the fingerprint, sadly).
This patch is by Damien Miller (of openssh upstream). It's simpler
than the patch by Mark Wooding which I applied yesterday; a copy is
taken of the proffered key/cert, the key extracted from the cert (if
necessary), and then the DNS consulted.
Signed-off-by: Matthew Vernon <matthew@debian.org>
Bug-Debian: http://bugs.debian.org/742513
Patch-Name: sshfp_with_server_cert_upstr
|
|
ssh: Enable ForwardX11Trusted, returning to earlier semantics which cause
fewer problems with existing setups (http://bugs.debian.org/237021).
ssh: Set 'SendEnv LANG LC_*' by default (http://bugs.debian.org/264024).
ssh: Enable HashKnownHosts by default to try to limit the spread of ssh
worms.
ssh: Enable GSSAPIAuthentication and disable GSSAPIDelegateCredentials by
default.
sshd: Refer to /usr/share/doc/openssh-server/README.Debian.gz alongside
PermitRootLogin default.
Document all of this, along with several sshd defaults set in
debian/openssh-server.postinst.
Author: Russ Allbery <rra@debian.org>
Forwarded: not-needed
Last-Update: 2014-02-12
Patch-Name: debian-config.patch
|
|
Author: Robie Basak <robie.basak@ubuntu.com>
Forwarded: no
Last-Update: 2014-04-14
Patch-Name: sigstop.patch
|
|
|
|
|
|
without-password" without asking (LP: #1300127).
|
|
|
|
Xsession has already done so (based on work by Bruno Vasselle; LP: #1244736).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also ask a debconf question when upgrading systems with "PermitRootLogin
yes" from previous versions.
Closes: #298138
|
|
response to #370050 (closes: #341883).
|
|
|
|
If an ssh server presents a certificate to the client, then the client
does not check the DNS for SSHFP records. This means that a malicious
server can essentially disable DNS-host-key-checking, which means the
client will fall back to asking the user (who will just say "yes" to
the fingerprint, sadly).
This patch is by Damien Miller (of openssh upstream). It's simpler
than the patch by Mark Wooding which I applied yesterday; a copy is
taken of the proffered key/cert, the key extracted from the cert (if
necessary), and then the DNS consulted.
Signed-off-by: Matthew Vernon <matthew@debian.org>
Bug-Debian: http://bugs.debian.org/742513
Patch-Name: sshfp_with_server_cert_upstr
|
|
[ Matthew Vernon ]
Fix failure to check SSHFP records if server presents a certificate
(bug reported by me, patch largely by Mark Wooding) (Closes: #742513)
|
|
|
|
If an ssh server presents a certificate to the client, then the client
does not check the DNS for SSHFP records. This means that a malicious
server can essentially disable DNS-host-key-checking, which means the
client will fall back to asking the user (who will just say "yes" to
the fingerprint, sadly).
This patch means that the ssh client will, if necessary, extract the
server key from the proffered certificate, and attempt to verify it
against the DNS. The patch was written by Mark Wooding
<mdw@distorted.org.uk>. I modified it to add one debug2 call, reviewed
it, and tested it.
Signed-off-by: Matthew Vernon <matthew@debian.org>
Bug-Debian: http://bugs.debian.org/742513
Patch-Name: sshfp_with_server_cert
|
|
|
|
* New upstream release (http://www.openssh.com/txt/release-6.6).
|
|
Bug-Ubuntu: https://bugs.launchpad.net/bugs/27152
Last-Update: 2010-02-28
Patch-Name: gnome-ssh-askpass2-icon.patch
|
|
ssh: Enable ForwardX11Trusted, returning to earlier semantics which cause
fewer problems with existing setups (http://bugs.debian.org/237021).
ssh: Set 'SendEnv LANG LC_*' by default (http://bugs.debian.org/264024).
ssh: Enable HashKnownHosts by default to try to limit the spread of ssh
worms.
ssh: Enable GSSAPIAuthentication and disable GSSAPIDelegateCredentials by
default.
sshd: Refer to /usr/share/doc/openssh-server/README.Debian.gz alongside
PermitRootLogin default.
Document all of this, along with several sshd defaults set in
debian/openssh-server.postinst.
Author: Russ Allbery <rra@debian.org>
Forwarded: not-needed
Last-Update: 2014-02-12
Patch-Name: debian-config.patch
|