Aw: debian-ssh@lists.debian.org in /usr/share/openssh/sshd_config

2017-01-22 Thread foo fighter
A further note: the value for is "no" in its default configuration. "man sshd_config" states "The default is yes.". Is this inconsistent? Yours Lopiuh     Gesendet: Sonntag, 22. Januar 2017 um 19:53 Uhr Von: "foo fighter" An: debian-ssh@lists.debian.org Betreff: 

debian-ssh@lists.debian.org in /usr/share/openssh/sshd_config

2017-01-22 Thread foo fighter
Hi, ChallengeResponseAuthentication is one of the few configuration parameters which are not uncommented in its default state. Is this intentionally or shoud the line be uncommented in order to have a consistent default config file of the openssh-server in debian? As far as I remember the

openssh-server (7.4p1-6) regression in setting PermitRootLogin (yes instead of

2017-01-22 Thread foo fighter
Hi, /etc/ssh/sshd_config reads: Shouldn't it be <#PermitRootLogin prohibit-password>? as stated in changelog of openssh (1:7.1p1-1) "PermitRootLogin option has changed from "yes" to "prohibit-password"? [...] #LoginGraceTime 2m PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions

Re: Bug#852172: dpkg: insecure use of temp file when upgrading conf file

2017-01-22 Thread Guillem Jover
Control: reassign -1 ucf Control: affects -1 openssh-server On Sun, 2017-01-22 at 11:56:59 +0100, Benoît wrote: > Package: dpkg > Version: 1.18.7 > Severity: normal > I'm upgrading openssh server and dpkg tells me about a new config file. > I usually find a .dist-something file beside the

Re: Bug#852172: dpkg: insecure use of temp file when upgrading conf file

2017-01-22 Thread Colin Watson
On Sun, Jan 22, 2017 at 12:57:38PM +0100, Guillem Jover wrote: > On Sun, 2017-01-22 at 11:56:59 +0100, Benoît wrote: > > I'm upgrading openssh server and dpkg tells me about a new config file. > > I usually find a .dist-something file beside the current file. > > I couldn't. > > Then I read

Re: Bug#852172: dpkg: insecure use of temp file when upgrading conf file

2017-01-22 Thread Ben
Hello, what if then I decide to mv it to replace mine ? what was wrong with the previous scheme (write the packaged version of the file within the same directory) ? I'm not a security expert, if you say it's safe and there's nothing to worry about, that's fine with me. 2017-01-22 13:45 GMT+01:00