Bill Harris writes:
> Lisi Reisz writes:
>
>> I would do the dist-upgrade first and clear up any mess remaining afterwards.
> I'll report back, assuming that the results of this adventure don't
> brick my machine /and/ my network. :-)
Well, I didn't quite brick it, but it didn't work too great
>> 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,
ArchLinux has an up-to-date wiki for hybrid graphics:
https://wiki.archlinux.org/index.php/PRIME . Maybe you can find some hints for
making use of the discrete GPU there.
Would be nice to hear if and how it works for your laptop.
Regards,
jvp.
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 Tue 12 Jul 2016 at 18:55:13 +0200, Pavel Kosina wrote:
> Brian napsal(a) dne 12.7.2016 v 16:25:
> >
> >Would see what comes up in the log with searches for "usbfs" and
> >"claimed"?
>
> :~$ journalctl --no-pager | grep usbfs
> čec 12 18:49:13 linuxbox kernel: usbcore: registered new interface
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
Brian napsal(a) dne 12.7.2016 v 16:25:
Would see what comes up in the log with searches for "usbfs" and
"claimed"?
:~$ journalctl --no-pager | grep usbfs
čec 12 18:49:13 linuxbox kernel: usbcore: registered new interface
driver usbfs
:~$ journalctl --no-pager | grep claimed
čec 12 18:49:41
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
Am 12.07.2016 um 17:32 schrieb Michael Biebl:
> So, what you copied from the bug report was simply not what you were
> looking at.
looking for, obviously.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description:
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
Am 11.07.2016 um 15:22 schrieb MI:
> Hi,
>
> Attached is the output. (BTW, findmnt is cool; I didn't know about it).
>
Thank you. I just wanted to be sure that you weren't using
tmpfs-for-/tmp by default, which isn't the case.
Now to your issue. You said you wanted time based clean-up (remove f
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
On Tue 12 Jul 2016 at 16:04:46 +0200, peekaa wrote:
> Yes, I tried this option - the result was the same :-( - not scanning.
> Not sure If we do have to uninstall previously installed driver from debian
> repositories before installing this epson package.
>
> Pavel
>
> Dne 12.7.2016 v 13:57 Curt
On Tue 12 Jul 2016 at 15:59:35 +0200, peekaa wrote:
> Dne 12.7.2016 v 12:55 Brian napsal(a):
>
> You are right. First run OK, any other run gives:
> $ scanimage -L
>
> No scanners were identified. If you were expecting something different,
> check that the scanner is plugged in, turned on and de
Yes, I tried this option - the result was the same :-( - not scanning.
Not sure If we do have to uninstall previously installed driver from
debian repositories before installing this epson package.
Pavel
Dne 12.7.2016 v 13:57 Curt napsal(a):
On 2016-07-12, peekaa wrote:
No scanners were id
Dne 12.7.2016 v 12:55 Brian napsal(a):
:~$ scanimage -L
device `epson2:libusb:001:005' is a Epson PID 08A1 flatbed scanner
sane reckons the epson2 backend will be up to doing the job.
This command has to give this output *consistently*. Running it 10 or 20
times on the run will enable you to
>> 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
On 2016-07-11, Juan R. de Silva wrote:
> On Mon, 11 Jul 2016 12:25:00 +0200, Andre Majorel wrote:
>
...
>
> It is obvious indeed. :-)
>
> The number were taken from Daily usage tab in gkrelm. Before making the
> test I had purposely not accessed Internet that day (except loading the
> page wit
-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 2016-07-12, peekaa wrote:
>
> No scanners were identified. If you were expecting something different,
> check that the scanner is plugged in, turned on and detected by the
> sane-find-scanner tool (if appropriate). Please read the documentation
> which came with this software (README, FAQ, manp
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
On Tue 12 Jul 2016 at 07:53:46 +0200, peekaa wrote:
> Hoping text formatting will be fine, now.
Much better. Thanks.
> -
> as a user: /in fact - i would need to use it as a user, even not sudo users
> - there are 4 users on comp/
> :~$ sane-fin
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
On 2016-07-12, der.hans wrote:
>>
>>;s The installation proceeded smoothly to the end and I tried to log in.
>> That's where the wheels came off. The os wouldn't take the password no
>> matter how many tries there were.
>
> Have you tried from a virtual terminal as well as from X?
Did he try from
69 matches
Mail list logo
