Le quintidi 25 messidor, an CCXXIV, Stefan Monnier a écrit :
> FWIW, I also find it disappointing that I can't do it in an etc file of
> some sort.
Yes, such an essential option should be integral to the system, not brought
by an obscure package. That the package exists is still better than nothin
On Tue 12 Jul 2016 at 17:32:22 +0200, Nicolas George wrote:
> Le quintidi 25 messidor, an CCXXIV, Brian a écrit :
> > Not really. How to change Policy is adequately described on the Debian
> > web site. How to submit a bug against openssh-server is also described.
>
> So you were talking about ch
> You could potentially just use the policyrcd-script-zg2 package, and
> then your boolean setting would be:
>
> echo -e "#!/bin/sh\nexit101;" > /etc/policy-rc.d.
>
> Or something similar. [Or if you really just want a boolean, you could
> potentially write your own package which plugged into pol
On Tue, 12 Jul 2016, Stefan Monnier wrote:
> >> I often need something like this when running inside a chroot and
> >> always have trouble finding the clean&easy way to do it
> > Here's one example that mk-sbuild uses:
> > (jessie-amd64)$ cat /usr/sbin/policy-rc.d
> > #!/bin/sh
> > while true; do
>
On Wednesday 13 July 2016 07:32:10 Henrique de Moraes Holschuh wrote:
> On Wed, 13 Jul 2016, Joe wrote:
> > On Tue, 12 Jul 2016 20:09:31 +0100
> >
> > Brian wrote:
> > > The cat from next door always looks very intently at me when I am
> > > at the keyboard. Is that normal feline behaviour?
> >
>
Le 13/07/2016 à 13:32, Henrique de Moraes Holschuh a écrit :
> On Wed, 13 Jul 2016, Joe wrote:
>> On Tue, 12 Jul 2016 20:09:31 +0100
>> Brian wrote:
>>> The cat from next door always looks very intently at me when I am at
>>> the keyboard. Is that normal feline behaviour?
>>>
>> Yes. The weight o
On Wed, 13 Jul 2016, Joe wrote:
> On Tue, 12 Jul 2016 20:09:31 +0100
> Brian wrote:
> > The cat from next door always looks very intently at me when I am at
> > the keyboard. Is that normal feline behaviour?
> >
> Yes. The weight of a cat is more than sufficient to operate most
> keyboards.
Not
On Tue, 12 Jul 2016 21:51:41 +0100
Lisi Reisz wrote:
> On Tuesday 12 July 2016 20:24:18 Brian wrote:
> > (For those who think this is about password logins in general - it
> > is not. It is about logging in as root).
>
> Thank you, Brian. You come up trumps again. I said that I hadn't
> under
On Tue, 12 Jul 2016 20:09:31 +0100
Brian wrote:
> The cat from next door always looks very intently at me when I am at
> the keyboard. Is that normal feline behaviour?
>
Yes. The weight of a cat is more than sufficient to operate most
keyboards.
--
Joe
>> I often need something like this when running inside a chroot and
>> always have trouble finding the clean&easy way to do it
> Here's one example that mk-sbuild uses:
> (jessie-amd64)$ cat /usr/sbin/policy-rc.d
> #!/bin/sh
> while true; do
> case "$1" in
> -*) shift ;;
> makedev)
On Tue, 12 Jul 2016, Stefan Monnier wrote:
> I often need something like this when running inside a chroot and
> always have trouble finding the clean&easy way to do it
Here's one example that mk-sbuild uses:
(jessie-amd64)$ cat /usr/sbin/policy-rc.d
#!/bin/sh
while true; do
case "$1" in
On Tuesday 12 July 2016 21:48:32 Stefan Monnier wrote:
> > My solution to that is physical access to the computer, actually sitting
> > in front of it - login without a password.
>
> While I don't need a strong password in such a situation, I do want some
> password because I don't like it when oth
On Tuesday 12 July 2016 20:04:32 Don Armstrong wrote:
> Considering that I maintain multiple things
> which install daemons in Debian
And most of us are very grateful.
Lisi
> No, it does not. What you show is not an option, an option would be
> something in /etc. This is editing a script in /usr/sbin, in complete
> violation of any good practice with packages managers.
FWIW, I also find it disappointing that I can't do it in an etc file of
some sort. E.g. I often n
On Tuesday 12 July 2016 20:24:18 Brian wrote:
> (For those who think this is about password logins in general - it is
> not. It is about logging in as root).
Thank you, Brian. You come up trumps again. I said that I hadn't understood
the question. I did think it was about password logging in in
> My solution to that is physical access to the computer, actually sitting in
> front of it - login without a password.
While I don't need a strong password in such a situation, I do want some
password because I don't like it when other people use my account
(usually they don't like it either bec
On Tue, 12 Jul 2016, Nicolas George wrote:
> Le quintidi 25 messidor, an CCXXIV, Don Armstrong a écrit :
> > That option already exists. See policy-rc.d. For example:
> >
> > https://jpetazzo.github.io/2013/10/06/policy-rc-d-do-not-start-services-automatically/
>
> What you show is not an option,
On Tue 12 Jul 2016 at 19:54:41 +0100, Lisi Reisz wrote:
> On Tuesday 12 July 2016 19:16:37 Brian wrote:
> >
> > The question you say was presented (and hazily recollect) was presented
> > because you were upgrading from Wheezy to Jessie.
>
> No, that is neither what I said nor what I meant. I do
Le quintidi 25 messidor, an CCXXIV, Don Armstrong a écrit :
> This is incredibly rude.
I stand by it.
> This is the endless security vs utility debate.
Indeed.
The most secure system
> That option already exists. See policy-rc.d. For example:
>
> https://jpetazzo.github.io/2013/10/06/policy-r
On Tue 12 Jul 2016 at 18:53:29 +0200, mwnx wrote:
> > So, you're blaming a perfectly good (and reasonably secure) way of
> > remote access, but somehow assume that weak passwords are ok.
> > By that logic you should not stop there. Why not blame any remote access
> > mechanism that uses PAM for pa
On Tue, 12 Jul 2016, Nicolas George wrote:
> Le quintidi 25 messidor, an CCXXIV, Don Armstrong a écrit :
> > If a services default configuration is insecure, it should be fixed.
> > File a bug.
>
> If you think about it slightly more than two seconds,
This is incredibly rude. Considering that I m
On Tuesday 12 July 2016 19:16:37 Brian wrote:
> On Tue 12 Jul 2016 at 18:09:22 +0100, Lisi Reisz wrote:
> > This was sent to me separately privately as well. I might have answered
> > differently on the list, but I am not writing a second reply to the same
> > post, so here is a copy-and-paste of
Le quintidi 25 messidor, an CCXXIV, Don Armstrong a écrit :
> If a services default configuration is insecure, it should be fixed.
> File a bug.
If you think about it slightly more than two seconds, you will realize that
if the default configuration does ANYTHING, even something that is
completely
On Tue 12 Jul 2016 at 18:09:22 +0100, Lisi Reisz wrote:
> This was sent to me separately privately as well. I might have answered
> differently on the list, but I am not writing a second reply to the same
> post, so here is a copy-and-paste of my reply.
>
> On Tuesday 12 July 2016 17:45:58 mw
On Tuesday 12 July 2016 18:39:29 Erwan David wrote:
> Le 12/07/2016 à 19:34, Lisi Reisz a écrit :
> > My solution to that is physical access to the computer, actually sitting
> > in front of it - login without a password. ALL external access, even
> > from the neighbouring computer, use a strong p
Le 12/07/2016 à 19:34, Lisi Reisz a écrit :
>
> My solution to that is physical access to the computer, actually sitting in
> front of it - login without a password. ALL external access, even from the
> neighbouring computer, use a strong password in case someone breaks into your
> network from
On Tuesday 12 July 2016 18:14:04 Stefan Monnier wrote:
> > This is different from what you originally said. By all means discuss
> > this general problem with the developers - but please don't single ssh
> > out and mess it up for a good many of the rest of us.
>
> I think we're miscommunicating:
> This is different from what you originally said. By all means discuss this
> general problem with the developers - but please don't single ssh out and
> mess it up for a good many of the rest of us.
I think we're miscommunicating: I specifically don't want to single-out
SSH but instead I want t
On Tuesday 12 July 2016 17:53:29 mwnx wrote:
> > So, you're blaming a perfectly good (and reasonably secure) way of
> > remote access, but somehow assume that weak passwords are ok.
> > By that logic you should not stop there. Why not blame any remote access
> > mechanism that uses PAM for password
This was sent to me separately privately as well. I might have answered
differently on the list, but I am not writing a second reply to the same
post, so here is a copy-and-paste of my reply.
On Tuesday 12 July 2016 17:45:58 mwnx wrote:
> On Tue, Jul 12, 2016 at 02:18:58PM +0100, Lisi Reisz wr
On Tuesday 12 July 2016 17:26:08 Stefan Monnier wrote:
> I mean, yes, I can (and have) cobbled up some hackish way to plug the
> holes I was aware of, but I think it would be better to be able to
> specifically only allow weak password authentication for some specific
> services and then stop worry
> So, you're blaming a perfectly good (and reasonably secure) way of
> remote access, but somehow assume that weak passwords are ok.
> By that logic you should not stop there. Why not blame any remote access
> mechanism that uses PAM for password checking as well?
There are many kinds of systems o
On Tue, Jul 12, 2016 at 02:18:58PM +0100, Lisi Reisz wrote:
> I was asked last time I installed open-ssh*, at installation time, but did
> not understand the question so went with the default. If you do not allow
> password log-in, what DO you allow? For ssh to be useful, one has to use it.
> Not
>> The original use case was to provide an account to my daughter who
>> was not (yet) able to remember a strong password. She wasn't going
>> to use a console login either.
> So a corner - and hopefully transitory ;-) - case.
Originally, yes, but I learned in the mean time to appreciate the
poss
On Tue, Jul 12, 2016 at 03:40:05PM +0200, to...@tuxteam.de wrote:
> On Tue, Jul 12, 2016 at 04:24:41PM +0300, Reco wrote:
> > On Tue, Jul 12, 2016 at 02:55:29PM +0200, to...@tuxteam.de wrote:
>
> [...]
>
> > > While it makes sense to keep a more general solution in sight, sshd
> > > is in many re
Le quintidi 25 messidor, an CCXXIV, Brian a écrit :
> Not really. How to change Policy is adequately described on the Debian
> web site. How to submit a bug against openssh-server is also described.
So you were talking about changing the whole policy of the project, not an
option to apt? What an u
On Tuesday 12 July 2016 14:53:41 Stefan Monnier wrote:
> The original use case
> was to provide an account to my daughter who was not (yet) able to
> remember a strong password. She wasn't going to use a console
> login either.
So a corner - and hopefully transitory ;-) - case. Set your system t
On Tue, 12 Jul 2016, Nicolas George wrote:
> That means the service ran for some time with the wrong config. Pwned.
If a services default configuration is insecure, it should be fixed.
File a bug.
--
Don Armstrong https://www.donarmstrong.com
I learned really early the dif
On Tue 12 Jul 2016 at 16:35:49 +0200, Nicolas George wrote:
> Le quintidi 25 messidor, an CCXXIV, Brian a écrit :
> > Of course it can be changed. Jost change Policy.
>
> Care to elaborate?
Not really. How to change Policy is adequately described on the Debian
web site. How to submit a bug again
2016-07-12 14:50 keltezéssel, to...@tuxteam.de írta:
Hmmm. This would still allow password auth for user 1000 (and root (!)).
No.
The default sshd config is:
PermitRootLogin prohibit-password
And openssh-server is optional package, it is not installed by default.
I think if someone decides to
Le quintidi 25 messidor, an CCXXIV, Brian a écrit :
> Of course it can be changed. Jost change Policy.
Care to elaborate?
> It's already configured. Want another configuration? Alter and restart
> the service.
That means the service ran for some time with the wrong config. Pwned.
> Stop the ser
>> This said, it doesn't quite address my need: rather than say "only allow
>> SSH access to userfoo and userbar", I'd like to do "disallow non-GDM
>> access for userfoo and userbar".
> That would include the local Linux console?
I'd be OK with either choice for console logins. The original use c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Jul 12, 2016 at 10:41:33AM -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 12 Jul 2016, mwnx wrote:
> > Currently, after installing openssh-server, anyone can gain access
> > to any user's account on the system using only the corresponding
On Tue 12 Jul 2016 at 15:06:33 +0200, Nicolas George wrote:
> Le quintidi 25 messidor, an CCXXIV, Brian a écrit :
> > The behaviour is sensible and acceptable.
>
> Yes, as long as it can be changed.
Of course it can be changed. Jost change Policy.
>
> >
> SSH access to userfoo and userbar", I'd like to do "disallow non-GDM
> access for userfoo and userbar".
Let me rephrase that: I'd like to "disallow non-GDM
use of userfoo and userbar's password for login".
E.g. I'd still like to allow non-password logins via SSH for those
users, since the only i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Jul 12, 2016 at 02:18:58PM +0100, Lisi Reisz wrote:
> On Tuesday 12 July 2016 13:50:39 to...@tuxteam.de wrote:
> > My question would be... what would be the consequences of changing
> > those defaults? Or perhaps, of asking the user at package
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Jul 12, 2016 at 09:31:41AM -0400, Stefan Monnier wrote:
[...]
> Indeed, I just saw those replies. Didn't know about AllowGroups.
>
> This said, it doesn't quite address my need: rather than say "only allow
> SSH access to userfoo and userba
On Tue, 12 Jul 2016, mwnx wrote:
> Currently, after installing openssh-server, anyone can gain access
> to any user's account on the system using only the corresponding
> user's password. As we know, people do not necessarily use the most
> secure of passwords. This will especially be the case if t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Jul 12, 2016 at 04:24:41PM +0300, Reco wrote:
> On Tue, Jul 12, 2016 at 02:55:29PM +0200, to...@tuxteam.de wrote:
[...]
> > While it makes sense to keep a more general solution in sight, sshd
> > is in many respects special.
>
> Such as?
Hm
>> Reminds me of a need I couldn't conveniently satisfy: allow known weak
>> passwords on some specific user accounts but make sure you can not use
>> them remotely (in my case I only wanted to allow GDM logins for them).
>> E.g. make it so that sshd only lets you login if your user is in the
>> "s
On Tue, Jul 12, 2016 at 02:55:29PM +0200, to...@tuxteam.de wrote:
> On Tue, Jul 12, 2016 at 03:45:06PM +0300, Reco wrote:
> > On Tue, Jul 12, 2016 at 02:20:38PM +0200, to...@tuxteam.de wrote:
> > > I still think the OP has a point. [...]
>
> > I can think of several 'solutions for the problem', bu
On Tuesday 12 July 2016 13:50:39 to...@tuxteam.de wrote:
> My question would be... what would be the consequences of changing
> those defaults? Or perhaps, of asking the user at package config
> time?
I *was* asked last time I installed open-ssh*, at installation time, but did
not understand the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Jul 12, 2016 at 09:02:23AM -0400, Stefan Monnier wrote:
> > That weak passwords are a problem in themselves or that other services
> > get started right away after install too is irrelevant to the point
> > made -- again IMHO.
>
> Reminds me o
Le quintidi 25 messidor, an CCXXIV, Brian a écrit :
> The behaviour is sensible and acceptable.
Yes, as long as it can be changed.
> Anyone who installs a daemon
> wants to use it; why install it in the first place?
Tu configure it before starting it?
T
> That weak passwords are a problem in themselves or that other services
> get started right away after install too is irrelevant to the point
> made -- again IMHO.
Reminds me of a need I couldn't conveniently satisfy: allow known weak
passwords on some specific user accounts but make sure you can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Jul 12, 2016 at 03:45:06PM +0300, Reco wrote:
> On Tue, Jul 12, 2016 at 02:20:38PM +0200, to...@tuxteam.de wrote:
> > I still think the OP has a point. [...]
> I can think of several 'solutions for the problem', but most of them are
> either u
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Jul 12, 2016 at 08:34:33AM -0400, Dan Ritter wrote:
[...]
> The easiest thing to do is to change the default config:
>
> create a group, sshlogin
>
> Add root and UID 1000 (the user created at install time) to that
> group.
>
> add this li
Hi.
On Tue, Jul 12, 2016 at 02:20:38PM +0200, to...@tuxteam.de wrote:
> On Tue, Jul 12, 2016 at 03:05:35PM +0300, Reco wrote:
> > Hi.
> >
> > On Tue, Jul 12, 2016 at 11:26:10AM +0200, mwnx wrote:
> > > Currently, after installing openssh-server, anyone can gain access
> > > to any use
On Tue, Jul 12, 2016 at 02:20:38PM +0200, to...@tuxteam.de wrote:
> On Tue, Jul 12, 2016 at 03:05:35PM +0300, Reco wrote:
> > Hi.
> >
> > On Tue, Jul 12, 2016 at 11:26:10AM +0200, mwnx wrote:
> > > Currently, after installing openssh-server, anyone can gain access
> > > to any user's account o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Jul 12, 2016 at 03:05:35PM +0300, Reco wrote:
> Hi.
>
> On Tue, Jul 12, 2016 at 11:26:10AM +0200, mwnx wrote:
> > Currently, after installing openssh-server, anyone can gain access
> > to any user's account on the system using only the c
Hi.
On Tue, Jul 12, 2016 at 11:26:10AM +0200, mwnx wrote:
> Currently, after installing openssh-server, anyone can gain access
> to any user's account on the system using only the corresponding
> user's password. As we know, people do not necessarily use the most
> secure of passwords. Thi
On Tue 12 Jul 2016 at 11:44:56 +0200, Nicolas George wrote:
> Le quintidi 25 messidor, an CCXXIV, mwnx a écrit :
> > I would like to initiate a discussion about the security
> > implications of the default sshd_config file, created after an
> > installation of the openssh-server package.
>
> I th
Le quintidi 25 messidor, an CCXXIV, mwnx a écrit :
> I would like to initiate a discussion about the security
> implications of the default sshd_config file, created after an
> installation of the openssh-server package.
I think the problem you raise is not specific to SSH: when installing
anythin
Hello,
I would like to initiate a discussion about the security
implications of the default sshd_config file, created after an
installation of the openssh-server package.
Currently, after installing openssh-server, anyone can gain access
to any user's account on the system using only the correspo
64 matches
Mail list logo
