Re: Wheezy to Jessie update problem: packages with bugs
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, either. I'm in the "clear up any mess" phase. :-) I couldn't get any menus or task / status bars in Gnome after the dist-upgrade, and I'm stuck with the Wheezy kernel. I finally discovered I could get classic Gnome, and that's what I'm using now. A bit of scattered Googling turned up that some 3.2.16 kernels fail for various reasons, and I need to figure out how to see what's causing it grief (udev? Something else?). I'm hopeful that getting the kernel fixed might be enough to make Gnome happy, too. Tips on where to look are welcome. Bill
Re: openssh-server's default config is dangerous
>> 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) exit 0;; > x11-common) exit 0;; > *) exit 101;; > esac > done Pretty far from my ideal of having some boolean setting under /etc somewhere. > In this particular case, the issue isn't dpkg, but the package > maintainer scripts. Those all operate using invoke-rc.d, and are > blissfully unaware of whether they are operating inside of a chroot or > outside. [Indeed, there's no reliable way of identifying whether you're > actually in a chroot or not unless you're root and can compare your root > to init's root.] It's actually worse: in some of my chroots (such as LilDebi's) I do want daemons to be started&stopped, while in others (typically when I mount some external disk that holds some other machine's (broken) root filesystem, in order to fix it) I don't. So even if we could reliably identify that we're in a chroot jail, it wouldn't tell us whether daemons should be started/stopped. Stefan
Re: openssh-server's default config is dangerous
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 -*) shift ;; makedev) exit 0;; x11-common) exit 0;; *) exit 101;; esac done For future reference, this is all covered in Debian Policy §9.3.3 "Interfacing with the initscript system" and invoke-rc.d(8). > (IIUC dpkg should figure out on its own that it's running in a chroot, > but it doesn't seem to work reliably enough in my experience, or maybe > I misunderstood how "running in chroot" is expected to affect dpkg's > behavior by default). In this particular case, the issue isn't dpkg, but the package maintainer scripts. Those all operate using invoke-rc.d, and are blissfully unaware of whether they are operating inside of a chroot or outside. [Indeed, there's no reliable way of identifying whether you're actually in a chroot or not unless you're root and can compare your root to init's root.] -- Don Armstrong https://www.donarmstrong.com If it jams, force it. If it breaks, it needed replacing anyway. -- Lowery's Law
Re: openssh-server's default config is dangerous
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 other people use my account > (usually they don't like it either because they find I have weird > preferences, but sometimes they'd be too lazy to switch to some other > account unless they're forced by the presence of a password prompt). Horses for courses again. :-) I hadn't thought of that risk. Lisi
Re: openssh-server's default config is dangerous
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
Re: openssh-server's default config is dangerous
> 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 need something like this when running inside a chroot and always have trouble finding the clean&easy way to do it (IIUC dpkg should figure out on its own that it's running in a chroot, but it doesn't seem to work reliably enough in my experience, or maybe I misunderstood how "running in chroot" is expected to affect dpkg's behavior by default). Stefan
Re: openssh-server's default config is dangerous
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 general. Lisi
Re: openssh-server's default config is dangerous
> 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 because they find I have weird preferences, but sometimes they'd be too lazy to switch to some other account unless they're forced by the presence of a password prompt). Stefan
Re: openssh-server's default config is dangerous
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, 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. So install policyrcd-script-zg2 which allows you to have "something in /etc". -- Don Armstrong https://www.donarmstrong.com "What, now?" "Soon equates to good, later to worse, Uagen Zlepe, scholar. Therefore, immediacy." -- Iain M. Banks _Look to Windward_ p 213
Re: Want to get Radeon HD 8970M working with Debian 8.4 on MSI GX70 laptop
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.
Re: openssh-server's default config is dangerous
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 not have ssh on any > of > my systems unless I need it. So the last twice I did > > # aptitude install openssh-client openssh-server > > I think once on Wheezy and once on Jessie, but am not absolutle certain that > that was the order in which I did it, so it could have been the two Jessie > computers that I did last. I have installed ssh recently on one Wheezy > computer and two Jessie ones. I did not write the question down, but I was > asked it. Just to make this crystal clear. If you upgrade from Wheezy to Jessie you will be asked whether you want to disable SSH password authentication for root. That is the *only* time the question will be asked. The question will never be asked again. It will never be asked if you install Jessie. (For those who think this is about password logins in general - it is not. It is about logging in as root).
Re: openssh-server's default config is dangerous
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-rc-d-do-not-start-services-automatically/ 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. signature.asc Description: Digital signature
Re: openssh-server's default config is dangerous
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 password checking as well? > > There are many kinds of systems on which weak passwords are OK. For There is no system which justifies having a weak password (whatever "weak" means). You might like to give an example of an ok weak password. > instance, a home PC has no need whatsoever for a strong password. If Whatever "strong" means this could make sense. On the other hand, it could be total nonsense. > someone breaks into my home, they have access to my data anyway; and Burglars carry Debian Live CDs these days? The ones round here just kick the door in, load the goods into their cars and fence it > the password is for local use only. If some malware gets into my > computer, it can get the root password through keylogging. I wondered when we would get to malware. You need a new thread for this. I hope you make a better job of it than the post which started this discussion. > Note: this weak password can still be useful to protect my privacy > from guests. The cat from next door always looks very intently at me when I am at the keyboard. Is that normal feline behaviour?
Re: openssh-server's default config is dangerous
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 maintain multiple things which install daemons in Debian, I've thought about this for significantly more than two seconds. > you will realize that if the default configuration does ANYTHING, even > something that is completely harmless in 99.99% of the cases, then > there will be some cases where this is a serious issue, where the > administrator really did not want it to happen. Even if it is only > 0.01% of the cases, that is still too many. This is the endless security vs utility debate. The most secure system is a system which is completely useless. Discussing this issue in the abstract isn't particularly useful. Discussing it in particular cases (like openssh-server's configuration) is useful, and then it becomes a question of where to draw the line. There's a reason why many daemons that do start only listen on localhost. Or only listen on sockets. Or don't do anything but serve static files out of very specific directories. > I am flabbergasted too see how many people oppose the obviously > correct solution to that kind of issue: have a global option "Start > services after installing? always / ask / never". 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/ -- Don Armstrong https://www.donarmstrong.com in Just- spring when the world is mud- luscious the little lame baloonman whistles far and wee -- e.e. cummings "[in Just-]"
Re: openssh-server's default config is dangerous
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 my reply. > > > > On Tuesday 12 July 2016 17:45:58 mwnx wrote: > > > 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. Note that it is not installed by default, > > > > one has to actively choose to have it. > > > > > > Before writing the original post, I checked on an Ubuntu 16.04 live > > > CD and was not asked any questions during installation of > > > openssh-server. > > > > My reaction to that is "well, if you will use Ubuntu, what do you expect? > > Ubuntu is hopelessly insecure." > > Your reaction is unwarranted and unsubstantiated. Yes, probably. It was my reaction, and has been my experience in general - but I did not test this. I was annoyed that mwnx had gone personal in that way. Mea culpa. > mwnx relates an > experience which can easily be tested. Not that anyone will; this > is -user! In fact. there is no need to install because a glance at > the templates file in the openssh-server package should be enough. > > Unconvinced? Do > > dpkg-reconfigure openssh-server > > Any output? Why not is left as an exercise to the user. > > > > I also tried right now on a debian jessie system, > > > and again, was not asked anything. What version of debian are you > > > running? > > > > Jessie and Wheezy. > > 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 not have ssh on any of my systems unless I need it. So the last twice I did # aptitude install openssh-client openssh-server I think once on Wheezy and once on Jessie, but am not absolutle certain that that was the order in which I did it, so it could have been the two Jessie computers that I did last. I have installed ssh recently on one Wheezy computer and two Jessie ones. I did not write the question down, but I was asked it. > > > > My idea was that to be able to use ssh, you should configure it > > > first, in some way or another. A very basic configuration > > > (specifically, whether to allow password auth or not) could be done > > > through a prompt during installation. > > > > It was, last time I installed it. (ssh-server) > > No question would be seen with a fresh install of openssh-server. The > question in essence is > > Disable SSH password authentication for root? No it was an a or b choice. > > Firstly, this has nothing to do with the original posting. Secondly, > disabling it is the default for a new install so there is no need to > ask any question. It wasn't I who wanted it. Though I want password access, so if the default is now no password access I am glad to have the information you give above. Lisi > > So nwnx is correct. Not that his substantial first post finds any > favour in these parts. > > > > > Where you are administering systems where you can expect users on > > > > your system to have weak passwords, change the defaults to suit. On > > > > my network there are no weak passwords. At least, I have chosen all > > > > passwords on the system and I go out of my way to try and make them > > > > reasonably secure. It is also (I hope) fairly difficult for anyone > > > > else to break in in the first place. I don't want *my* life made any > > > > harder!! > > > > > > You're looking at this from a sysadmin point of view, but many > > > debian users (I'm including Ubuntu users here) have no or little > > > knowledge of system administration. > > > > a) I am not. I have a small home network. And b) then they shouldn't be > > using ssh. Especially Ubuntu users. Ubuntu is hopelessly insecure in so > > many ways it is one of the main reasons why I don't like it. > > > > Weak passwords are a no-no in my opinion. If you use weak passwords and > > it causes problems, that is your problem. Don't foist a self-created > > problem on the rest of us. If your network is insecurely open to the > > world, that is also your problem. If you are administering a large > > network, then you are a sys-admin and can configure ssh to suit yourself. > > Precisely. The original post sets up an Aunt Sally.
Re: openssh-server's default config is dangerous
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 harmless in 99.99% of the cases, then there will be some cases where this is a serious issue, where the administrator really did not want it to happen. Even if it is only 0.01% of the cases, that is still too many. I am flabbergasted too see how many people oppose the obviously correct solution to that kind of issue: have a global option "Start services after installing? always / ask / never". signature.asc Description: Digital signature
Re: openssh-server's default config is dangerous
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 mwnx wrote: > > 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. Note that it is not installed by default, one has to actively > > > choose to have it. > > > > Before writing the original post, I checked on an Ubuntu 16.04 live > > CD and was not asked any questions during installation of > > openssh-server. > > My reaction to that is "well, if you will use Ubuntu, what do you expect? > Ubuntu is hopelessly insecure." Your reaction is unwarranted and unsubstantiated. mwnx relates an experience which can easily be tested. Not that anyone will; this is -user! In fact. there is no need to install because a glance at the templates file in the openssh-server package should be enough. Unconvinced? Do dpkg-reconfigure openssh-server Any output? Why not is left as an exercise to the user. > > I also tried right now on a debian jessie system, > > and again, was not asked anything. What version of debian are you > > running? > > Jessie and Wheezy. The question you say was presented (and hazily recollect) was presented because you were upgrading from Wheezy to Jessie. > > My idea was that to be able to use ssh, you should configure it > > first, in some way or another. A very basic configuration > > (specifically, whether to allow password auth or not) could be done > > through a prompt during installation. > > It was, last time I installed it. (ssh-server) No question would be seen with a fresh install of openssh-server. The question in essence is Disable SSH password authentication for root? Firstly, this has nothing to do with the original posting. Secondly, disabling it is the default for a new install so there is no need to ask any question. So nwnx is correct. Not that his substantial first post finds any favour in these parts. > > > Where you are administering systems where you can expect users on your > > > system to have weak passwords, change the defaults to suit. On my > > > network there are no weak passwords. At least, I have chosen all > > > passwords on the system and I go out of my way to try and make them > > > reasonably secure. It is also (I hope) fairly difficult for anyone else > > > to break in in the first place. I don't want *my* life made any harder!! > > > > You're looking at this from a sysadmin point of view, but many > > debian users (I'm including Ubuntu users here) have no or little > > knowledge of system administration. > > a) I am not. I have a small home network. And b) then they shouldn't be > using ssh. Especially Ubuntu users. Ubuntu is hopelessly insecure in so > many ways it is one of the main reasons why I don't like it. > > Weak passwords are a no-no in my opinion. If you use weak passwords and it > causes problems, that is your problem. Don't foist a self-created problem on > the rest of us. If your network is insecurely open to the world, that is > also your problem. If you are administering a large network, then you are a > sys-admin and can configure ssh to suit yourself. Precisely. The original post sets up an Aunt Sally.
Re: openssh-server's default config is dangerous
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 password in case someone > > breaks into your network from outside. > > > > Lisi > > Note that there are computers to which no user has physical access. Of course. But anyone who is administering such a computer can be assumed to be at least knowledgeable enough to reconfigure ssh to suit his/her needs/likes/wants! And I would never advocate passwordless entry, nor a weak password, in such a situation. > > "ALL external access, even > > from the neighbouring computer, use a strong password in case someone > > breaks into your network from outside." Lisi
Re: openssh-server's default config is dangerous
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 outside. > > Lisi Note that there are computers to which no user has physical access.
Re: epson L210 scan
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 driver > usbfs > :~$ journalctl --no-pager | grep claimed > čec 12 18:49:41 linuxbox realmd[2194]: claimed name on bus: > org.freedesktop.realmd > > Hoping its this. I'm afraid not. We were looking for some sign that the interface that scanimage wanted to use had already been claimed by the usblp module. This can be a cause of what you observe and is not uncommon. Whether Epson all-in-one devices are more prone to it I do not know. My RX-420 is affected but I can get it to work. Plan A is in ruins. If journalctl had indicated the usblp module as the culprit the solution is modprobe -r usblp I suppose you could try this but it shouldn't work. (If I am correct your device does not use memory cards?) Time for Plan B. Delete every line in /etc/sane.d/dll.conf apart from epson and epson2. You can get the file back again by reinstalling libsane-common. Comment out epson2. epson # epson2 Unattach and reattach the device. Try 'scanimage -L'. Look at journalctl after reattching the scanner and each use of the command. Also replace epson with epson2 and repeat.
Re: openssh-server's default config is dangerous
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: I specifically don't want to single-out > SSH but instead I want to single out GDM. And I think this should be > done in PAM. Yes, we are miscommunicating, and I'll go along with that. > > > But why do you need weak passwords? I think we may have an x-y problem > > here, and weak passwords may not be the only/optimum solution to the > > problem you are trying to solve by having them. Weak passwords are a bad > > idea per se. > > Quite likely. I only pointed out this need of mine as being related to > the OP's request. > > Here are some uses of weak passwords in GDM I can remember offhand: > - For accounts of people unable to remember a more complex password. > - For guest accounts > - For mere convenience (when I'm in front of my desktop at home, it's > handy not to have to type my full password, under the assumption that > physical access to the machine means that a strong password wouldn't > make much difference (as long as the disk isn't encrypted, say)). 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 outside. Lisi
Re: openssh-server's default config is dangerous
> 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 to single out GDM. And I think this should be done in PAM. > But why do you need weak passwords? I think we may have an x-y problem here, > and weak passwords may not be the only/optimum solution to the problem you > are trying to solve by having them. Weak passwords are a bad idea per se. Quite likely. I only pointed out this need of mine as being related to the OP's request. Here are some uses of weak passwords in GDM I can remember offhand: - For accounts of people unable to remember a more complex password. - For guest accounts. - For mere convenience (when I'm in front of my desktop at home, it's handy not to have to type my full password, under the assumption that physical access to the machine means that a strong password wouldn't make much difference (as long as the disk isn't encrypted, say)). Stefan
Re: openssh-server's default config is dangerous
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 checking as well? > > There are many kinds of systems on which weak passwords are OK. For > instance, a home PC has no need whatsoever for a strong password. If > someone breaks into my home, they have access to my data anyway; and > the password is for local use only. If some malware gets into my > computer, it can get the root password through keylogging. > > Note: this weak password can still be useful to protect my privacy > from guests. Then it is up to you to reconfigure anything that this attitude leaves insecure that you want secure. (Why? The break in scenario still applies.) Lisi
Re: openssh-server's default config is dangerous
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 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. Note that it is not installed by default, one has to actively > > choose to have it. > > Before writing the original post, I checked on an Ubuntu 16.04 live > CD and was not asked any questions during installation of > openssh-server. My reaction to that is "well, if you will use Ubuntu, what do you expect? Ubuntu is hopelessly insecure." > I also tried right now on a debian jessie system, > and again, was not asked anything. What version of debian are you > running? Jessie and Wheezy. > > My idea was that to be able to use ssh, you should configure it > first, in some way or another. A very basic configuration > (specifically, whether to allow password auth or not) could be done > through a prompt during installation. It was, last time I installed it. (ssh-server) > > Where you are administering systems where you can expect users on your > > system to have weak passwords, change the defaults to suit. On my > > network there are no weak passwords. At least, I have chosen all > > passwords on the system and I go out of my way to try and make them > > reasonably secure. It is also (I hope) fairly difficult for anyone else > > to break in in the first place. I don't want *my* life made any harder!! > > You're looking at this from a sysadmin point of view, but many > debian users (I'm including Ubuntu users here) have no or little > knowledge of system administration. a) I am not. I have a small home network. And b) then they shouldn't be using ssh. Especially Ubuntu users. Ubuntu is hopelessly insecure in so many ways it is one of the main reasons why I don't like it. Weak passwords are a no-no in my opinion. If you use weak passwords and it causes problems, that is your problem. Don't foist a self-created problem on the rest of us. If your network is insecurely open to the world, that is also your problem. If you are administering a large network, then you are a sys-admin and can configure ssh to suit yourself. Lisi
Re: epson L210 scan
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 linuxbox realmd[2194]: claimed name on bus: org.freedesktop.realmd Hoping its this.
Re: openssh-server's default config is dangerous
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 worrying about which other services might still > use those weak password (su? telnetd? which other ones? how could > I find out?) 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. But why do you need weak passwords? I think we may have an x-y problem here, and weak passwords may not be the only/optimum solution to the problem you are trying to solve by having them. Weak passwords are a bad idea per se. Lisi
Re: openssh-server's default config is dangerous
> 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 on which weak passwords are OK. For instance, a home PC has no need whatsoever for a strong password. If someone breaks into my home, they have access to my data anyway; and the password is for local use only. If some malware gets into my computer, it can get the root password through keylogging. Note: this weak password can still be useful to protect my privacy from guests. -- mwnx GPG: AEC9 554B 07BD F60D 75A3 AF6A 44E8 E4D4 0312 C726
Re: openssh-server's default config is dangerous
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. > Note that it is not installed by default, one has to actively choose to have > it. Before writing the original post, I checked on an Ubuntu 16.04 live CD and was not asked any questions during installation of openssh-server. I also tried right now on a debian jessie system, and again, was not asked anything. What version of debian are you running? My idea was that to be able to use ssh, you should configure it first, in some way or another. A very basic configuration (specifically, whether to allow password auth or not) could be done through a prompt during installation. > Where you are administering systems where you can expect users on your system > to have weak passwords, change the defaults to suit. On my network there are > no weak passwords. At least, I have chosen all passwords on the system and I > go out of my way to try and make them reasonably secure. It is also (I hope) > fairly difficult for anyone else to break in in the first place. I don't > want my life made any harder!! You're looking at this from a sysadmin point of view, but many debian users (I'm including Ubuntu users here) have no or little knowledge of system administration. -- mwnx GPG: AEC9 554B 07BD F60D 75A3 AF6A 44E8 E4D4 0312 C726
Re: openssh-server's default config is dangerous
>> 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 possibility of offering an account with a simple/trivial password on my machine. It comes in handy more often than "once per offspring". > Set your system to use key-pairs. I don't understand what that means (or how that helps). Do you mean I should disallow password access via SSH altogether? That doesn't solve the issue of "only allow password access via GDM", in the sense that there are still other ways in beside GDM and SSH. 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 worrying about which other services might still use those weak password (su? telnetd? which other ones? how could I find out?) Stefan
Re: How to prevent /tmp files from being deleted at reboot
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: OpenPGP digital signature
Re: openssh-server's default config is dangerous
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 respects special.
> >
> > Such as?
>
> Hm. Given its task, it runs as root. And is designed to run arbitrary
> commands from "outside" whenever the credentials are right. In my
> view, this puts some weight on those credentials.
Indeed it does all that. But consider this:
- By its design checks for local user's password (again, it can do
kerberos, but let's not go in there).
- Such check is done by PAM in Debian, hence it's PAM, not openssh
should be blamed for any fallacies in password check.
- While it's certainly possible to write a custom authentication scheme
in PAM configuration for sshd only - I don't know any Linux (or
non-Linux) distribution which does so.
- And sshd is only one example of remote access program which is running
with uid=0 privileges, although possibly the most common one.
Hence 'sshd allows for weak credentials' problem could be solved in more
correct way - simply prohibit setting weak passwords for any OS user,
root included.
For example, Debian could adopt RedHat approach (it would not be the
first such case after all), and force using pam_cracklib by default.
> > > And how about changing the default to "PasswordAuthentication no"?
>
> > 2) Keypair type.
> >
> > As of jessie stock sshd allows 6 ('ssh -Q key | grep -v cert') keypair
> > types, and of those one is secure - ed25519.
>
> C'mon. This is just a choice of defaults which can be improved on.
By default ssh-keygen generates an rsa keypair (at least the man page
says so). It's important for compatibility with legacy systems (Solaris
comes to mind immediately), but falls into 'nothing to write home about'
category by today's standards.
Changing ssh-keygen default keypair type will require a patch for
openssh, and we're still seeing the fallout from '06 openssl Debian
patch failure ;)
Reco
Re: How to prevent /tmp files from being deleted at reboot
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 files older then 30 days) but *not* remove them on boot. You've created a file /etc/tmpfiles.d/tmp.conf which overrides the default that is shipped in /usr/lib/tmpfiles.d/tmp.conf So far so good. What you used in /etc/tmpfiles.d/tmp.conf is: D /tmp 1777 root root 30d Let's see the tmpfiles.d man page [1]: >D >Similar to d, but in addition the contents of the directory will be >removed when --remove is used. During boot systemd-tmpfiles-setup.service is run: $ systemctl cat systemd-tmpfiles-setup.service | grep ExecStart ExecStart=/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev So, you actually requested that /tmp is cleaned up during boot. What you want is the 'd' option. Again, have a look at the tmpfiles.d man page [2]: >d >Create a directory. The mode and ownership will be adjusted if > specified and the directory already exists. Contents of this directory are > subject to time based cleanup if the time >argument is specified. So, what you copied from the bug report was simply not what you were looking at. Always consult the man pages. The ones shipped by systemd are actually pretty decent. I think that should solve your misteries. Regards, Michael [1] https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html#D [2] https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html#d -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: openssh-server's default config is dangerous
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 useless remark. > All services are started with safe defaults. You have not understood a single thing about the issue at the origin of this thread, have you. EOT signature.asc Description: Digital signature
Re: openssh-server's default config is dangerous
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 to use key-pairs. (Is that what you are advocating that the rest of us should have imposed???) Then change it back when your daughter is old enough to use a strong password - if age is the problem. People do after all outgrow being too young. My being too old can only get worse. ;-) Lisi
Re: openssh-server's default config is dangerous
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 difference between knowing the name of something and knowing something -- Richard Feynman "What is Science" Phys. Teach. 7(6) 1969
Re: openssh-server's default config is dangerous
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 against openssh-server is also described. > > 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 service etc. > > That means the service ran for some time while you did not want it to. > Pwned. All services are started with safe defaults.
Re: openssh-server's default config is dangerous
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 install it he/she should know the consequences also.
Re: openssh-server's default config is dangerous
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 service etc. That means the service ran for some time while you did not want it to. Pwned. > That's two examples being awaited. Well, that makes also two times your system got pwned. signature.asc Description: Digital signature
Re: epson L210 scan
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 napsal(a): > >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, manpages). > >In the event there is no open source alternative, it seems that Epson > >does provide a deb for scanning with your device here: > > > >http://support.epson.net/linux/en/iscan_c.php?version=1.0.1 > > > >Good luck. Epson's iscan depends on libsane. If that doesn't work neither will iscan.
Re: epson L210 scan
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 detected by the > sane-find-scanner tool (if appropriate). Please read the documentation > which came with this software (README, FAQ, manpages). > > "no scanner frontend will work reliably " - what does it mean? Means that > we can not scan if we need? Or do we have just "give a try"? :-( We hope not. But we can only try and see. > >If you get this again as a user please post the last few lines shown by > >'journalctl'. > > here: > > čec 12 15:52:15 linuxbox /usr/lib/gdm3/gdm-x-session[12322]: Activating > service name='org.gnome.Terminal' > čec 12 15:52:15 linuxbox /usr/lib/gdm3/gdm-x-session[12322]: Successfully > activated service 'org.gnome.Terminal' > čec 12 15:52:15 linuxbox org.gnome.Shell.desktop[12415]: Gjs-Message: JS > LOG: [pixel-saver]: Can't find original state for dady@linuxbox: ~ with id > 0x1a000 > čec 12 15:52:15 linuxbox org.gnome.Shell.desktop[12415]: > (gnome-shell:12415): Gtk-WARNING **: Allocating size to ShellEmbeddedWindow > 0x36787d0 without call > čec 12 15:53:32 linuxbox scanimage[12734]: io/hpmud/pp.c 627: unable to read > device-id ret=-1 Would see what comes up in the log with searches for "usbfs" and "claimed"?
Re: epson L210 scan
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 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, manpages). In the event there is no open source alternative, it seems that Epson does provide a deb for scanning with your device here: http://support.epson.net/linux/en/iscan_c.php?version=1.0.1 Good luck.
Re: epson L210 scan
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 make a judgement. Without a consistent output xsane will not work reliably. In fact, no scanner frontend will work reliably, including what you have from Epson. 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 detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). "no scanner frontend will work reliably " - what does it mean? Means that we can not scan if we need? Or do we have just "give a try"? :-( :~$ sudo scanimage -L No scanners were identified. If you were expecting something different, If you get this again as a user please post the last few lines shown by 'journalctl'. here: čec 12 15:52:15 linuxbox /usr/lib/gdm3/gdm-x-session[12322]: Activating service name='org.gnome.Terminal' čec 12 15:52:15 linuxbox /usr/lib/gdm3/gdm-x-session[12322]: Successfully activated service 'org.gnome.Terminal' čec 12 15:52:15 linuxbox org.gnome.Shell.desktop[12415]: Gjs-Message: JS LOG: [pixel-saver]: Can't find original state for dady@linuxbox: ~ with id 0x1a000 čec 12 15:52:15 linuxbox org.gnome.Shell.desktop[12415]: (gnome-shell:12415): Gtk-WARNING **: Allocating size to ShellEmbeddedWindow 0x36787d0 without call čec 12 15:53:32 linuxbox scanimage[12734]: io/hpmud/pp.c 627: unable to read device-id ret=-1 Thank you again Pavel
Re: openssh-server's default config is dangerous
>> 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 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. Stefan
Re: openssh-server's default config is dangerous
-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 > > user's password. As we know, people do not necessarily use the most > > secure of passwords. This will especially be the case if the user > > does not expect his computer to be accessible in any way from the > > outside. > > Well, arguably, we could restrict ssh to key-based access by default > (which has a side effect of not allowing anyone in until keys are > deployed), or at least ask about it. > > We could have it behave differently when installed from within > debian-installer (where it is used to complete the installation > remotely, and needs to be password-based). > > Feel free to file a *wishlist* bug about it against the openssh-server > package, it would be a much better place to discuss its defaults. Ultimately you are right, of course: but as I understood mwnx was looking for input, and quite a few valid points have been made. Changing the default right away seems too simplistic and would put many users in the rain. Some more thinking is needed, I guess. Me, I just wanted to avoid the OP being driven away by all too dismissive reactions. (S)he has a point, although perhaps the solution is a bit difficult. regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAleE9ssACgkQBcgs9XrR2kbssQCfRq9oMcVfP4ey/62XhsPYNxyQ ma0An2z6Rx5Smc2KyDmE6XvKepImIh78 =z/Vo -END PGP SIGNATURE-
Re: openssh-server's default config is dangerous
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. > > > Anyone who installs a daemon > > wants to use it; why install it in the first place? > > Tu configure it before starting it? It's already configured. Want another configuration? Alter and restart the service. > To have it at hand and be able to start it occasionally? Stop the service etc. > To use auxiliary programs that come in the same package? Auxiliary programs probably need the daemon but an example would help. That's two examples being awaited. > To prepare a filesystem for another host in a chroot? > > You sure lack imagination. Sometimes I imagine that posts like the first one in this thread lead somewhere. The topic has been done to death in the past. > (Fortunately, systemd brought a solution for the fourth situation, since it > does not start services in chroots.)
Re: openssh-server's default config is dangerous
> 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 issue is that those users's password are known to be weak. Another approach would be to specify different passwords depending on the use case. I.e. specify different passwords (for these specific users) when login via GDM than via other means. But that seems to require more serious changes since I'd want `passwd' and other such tools to modify the GDM password of those users (so they can change their weak password without having to worry about (or even know) about the existence of other passwords to access their account). Stefan
Re: openssh-server's default config is dangerous
-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 config > > time? > > 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. > > Note that it is not installed by default, one has to actively choose to have > it. Thanks for this input, Lisi. So the installer *already asks*, but has the "other" default. And it would have made your life harder otherwise. Besides, the question seems obscure. Any ideas on how to make it more understandable? As for the default... ultimately Henrique is right, one should file a bug. I'm still trying to get a grasp of the tradeoffs involved (and perhaps looking for better ideas). regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAleE9W0ACgkQBcgs9XrR2kZMPQCfaZ3ZXH77SkjXciAcrbIgXpCw 9NgAn0vUqC0ivqy6fFY4i3UexVxs6Ley =iVxO -END PGP SIGNATURE-
Re: openssh-server's default config is dangerous
-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 userbar", I'd like to do "disallow non-GDM > access for userfoo and userbar". That would include the local Linux console? > The main issue is the difference between SSH and non-GDM: how do I make > sure non-GDM/non-SSH accesses are also disallowed? > > It's really something that should be addressed in PAM rather than in > SSH's config. Sounds about right, if I understood you correctly. Regards - -- t -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAleE88IACgkQBcgs9XrR2kbxPwCaAn6VKsXq6cYezuoy/YSKhFbR HnQAn1MroKdtG4sFsS5PbhZVISxLA7Xn =zmnI -END PGP SIGNATURE-
Re: openssh-server's default config is dangerous
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 the user > does not expect his computer to be accessible in any way from the > outside. Well, arguably, we could restrict ssh to key-based access by default (which has a side effect of not allowing anyone in until keys are deployed), or at least ask about it. We could have it behave differently when installed from within debian-installer (where it is used to complete the installation remotely, and needs to be password-based). Feel free to file a *wishlist* bug about it against the openssh-server package, it would be a much better place to discuss its defaults. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: openssh-server's default config is dangerous
-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. Given its task, it runs as root. And is designed to run arbitrary
commands from "outside" whenever the credentials are right. In my
view, this puts some weight on those credentials.
[...]
> > And how about changing the default to "PasswordAuthentication no"?
>
> There are several things that can go wrong here:
>
> 1) Headless systems.
>
> PasswordAuthentication=no implies providing either public key or
> certificate to the host (let's not go into kerberos-based setups for now).
> Doing so via preseed file during the install is tricky, doing so after
> the install would require a serial console or physical access to the
> local storage. To sum it up - a complication at best.
Absolutely. That's why I wouldn't propose to do it right away, but to
*think* about it. In my workflow, for example (I always use keys whenever
I have any say on the server) is to do ssh-copy-id to the server; this
only works if, for this very first time, there's another way of auth!
And think Lisi, who in the other post says she isn't using keys: whatever
solution must not make her life unnecessarily more difficult.
So this can only be part of a solution, if at all. I know that.
> 2) Keypair type.
>
> As of jessie stock sshd allows 6 ('ssh -Q key | grep -v cert') keypair
> types, and of those one is secure - ed25519.
C'mon. This is just a choice of defaults which can be improved on.
Regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAleE8zUACgkQBcgs9XrR2kam+wCfZmmjRdrKpDAMOL1qsjdnL8OC
QGAAn0F10F147jXxySn5NjBwVLtC3Irs
=yDXS
-END PGP SIGNATURE-
Re: openssh-server's default config is dangerous
>> 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 >> "ssh-able" group or some such, just like we do for sudo. > I think that is what AllowGroups and DenyGroups (and their twins > - -Users) in the sshd_config are for. 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 userbar", I'd like to do "disallow non-GDM access for userfoo and userbar". The main issue is the difference between SSH and non-GDM: how do I make sure non-GDM/non-SSH accesses are also disallowed? It's really something that should be addressed in PAM rather than in SSH's config. Stefan
Re: openssh-server's default config is dangerous
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', but most of them are
> > either unrealistic or redundant:
> >
> > 1) Change Debian Policy which mandates starting a daemon on package
> > install.
>
> I think this is the wrong alley: Making this a problem of "all daemons"
> renders the problem practically intractable.
>
> While it makes sense to keep a more general solution in sight, sshd
> is in many respects special.
Such as?
> > 2) Add 'AllowGroups ssh' to the stock sshd_config.
> >
> > 3) Add a debconf template to openssh-server package which allows to
> > choose local users for 'AllowUsers' stanza of sshd_config.
> >
> > 4) Block all incoming connections to tcp port 22 by default.
>
> And how about changing the default to "PasswordAuthentication no"?
There are several things that can go wrong here:
1) Headless systems.
PasswordAuthentication=no implies providing either public key or
certificate to the host (let's not go into kerberos-based setups for now).
Doing so via preseed file during the install is tricky, doing so after
the install would require a serial console or physical access to the
local storage. To sum it up - a complication at best.
2) Keypair type.
As of jessie stock sshd allows 6 ('ssh -Q key | grep -v cert') keypair
types, and of those one is secure - ed25519.
Assuming that we don't trust the end user to choose a reasonably strong
password we can safely assume that given the choice the same user will
choose worst keypair type possible (dsa) and "forgets" to
password-encrypt the private key.
Reco
Re: openssh-server's default config is dangerous
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 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. Note that it is not installed by default, one has to actively choose to have it. Where you are administering systems where you can expect users on your system to have weak passwords, change the defaults to suit. On my network there are no weak passwords. At least, I have chosen all passwords on the system and I go out of my way to try and make them reasonably secure. It is also (I hope) fairly difficult for anyone else to break in in the first place. I don't want *my* life made any harder!! Lisi
Re: Potentialy OT: Firefox downloads over 6 GB of data streaming < 1 GB movie.
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 with the movie certainly). Thus gkrelm only showed a couple of > dozens of MB due to some minor local network activity, which I ignored. > > I've already submitted a bug to Mozilla but was interesting to listen to > community. If I've experienced some abnormal Firefox behaviour is not > very likely that mine was totally unique experience. > > I'd hate to switch to Google Chrome from Firefox, since the last is my > favourite. > In about:config you could try setting network.prefetch-next to false.
Re: openssh-server's default config is dangerous
-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 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 > "ssh-able" group or some such, just like we do for sudo. I think that is what AllowGroups and DenyGroups (and their twins - -Users) in the sshd_config are for. Some proposals in this thread go in that direction. regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAleE64AACgkQBcgs9XrR2kZGowCfVcYyJycfRzPAx6DilG5Rha5A RnYAnRmQeH5VcjTUHCG1pBL01fMyosxI =j+xi -END PGP SIGNATURE-
Re: openssh-server's default config is dangerous
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? To have it at hand and be able to start it occasionally? To use auxiliary programs that come in the same package? To prepare a filesystem for another host in a chroot? You sure lack imagination. (Fortunately, systemd brought a solution for the fourth situation, since it does not start services in chroots.) Regards, -- Nicolas George signature.asc Description: Digital signature
Re: openssh-server's default config is dangerous
> 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 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 "ssh-able" group or some such, just like we do for sudo. Stefan
Re: openssh-server's default config is dangerous
-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 unrealistic or redundant: > > 1) Change Debian Policy which mandates starting a daemon on package > install. I think this is the wrong alley: Making this a problem of "all daemons" renders the problem practically intractable. While it makes sense to keep a more general solution in sight, sshd is in many respects special. > 2) Add 'AllowGroups ssh' to the stock sshd_config. > > 3) Add a debconf template to openssh-server package which allows to > choose local users for 'AllowUsers' stanza of sshd_config. > > 4) Block all incoming connections to tcp port 22 by default. And how about changing the default to "PasswordAuthentication no"? regards - -- t -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAleE6MEACgkQBcgs9XrR2kbj1wCfZ4b+s3JyR/LdySApPMKQsAxU UZwAnR1vcj9CdMAf0RQG0A1iBaiRPFd+ =q1// -END PGP SIGNATURE-
Re: openssh-server's default config is dangerous
-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 line to /etc/ssh/sshd_config: > AllowGroup sshlogin > > from man sshd_config: > > If specified, login is allowed only for users whose primary group or > supplementary group list matches one of the patterns. Only group names > are valid; a numerical group ID is not recognized. By default, login > is allowed for all groups. The allow/deny directives are processed > in the following order: DenyUsers, AllowUsers, DenyGroups, and finally > AllowGroups. > > and finally, update the documentation to reflect this. > > The downside is that this is a major change in behavior; the > upside is that it is consistent with other things that Debian > does. Hmmm. This would still allow password auth for user 1000 (and root (!)). I think OP's concern was exactly that. My question would be... what would be the consequences of changing those defaults? Or perhaps, of asking the user at package config time? regards - -- t -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAleE558ACgkQBcgs9XrR2kYmrgCfbtv1IoZWgTrLtpNl44JqEeK8 uGgAmQGuKQ/6CxeCqJbNxES4aG1e/dV4 =CqQn -END PGP SIGNATURE-
Re: openssh-server's default config is dangerous
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 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 the user > > > does not expect his computer to be accessible in any way from the > > > outside. > > > > 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? > > I still think the OP has a point. I don't know how a solution might look > which makes sense (a default config with password disabled seems a bit > strong, TBH), but IMHO it's worth thinking about the problem instead > of dismissing it off-hand. I can think of several 'solutions for the problem', but most of them are either unrealistic or redundant: 1) Change Debian Policy which mandates starting a daemon on package install. 2) Add 'AllowGroups ssh' to the stock sshd_config. 3) Add a debconf template to openssh-server package which allows to choose local users for 'AllowUsers' stanza of sshd_config. 4) Block all incoming connections to tcp port 22 by default. But I still fail to understand why one should consider openssh 'dangerous' (when openssh merely does what it's intended to do), but assume that dropbear, vsftpd and telnetd (to name a few) are somehow 'safe'. Using openssh in a public environment requires (IMO) paranoid custom configuration anyway. Using openssh in a trusted LAN requires (duh!) trust on all participants of such LAN. Reco
Re: openssh-server's default config is dangerous
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 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 the user > > > does not expect his computer to be accessible in any way from the > > > outside. > > > > 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? > > I still think the OP has a point. I don't know how a solution might look > which makes sense (a default config with password disabled seems a bit > strong, TBH), but IMHO it's worth thinking about the problem instead > of dismissing it off-hand. 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 line to /etc/ssh/sshd_config: AllowGroup sshlogin from man sshd_config: If specified, login is allowed only for users whose primary group or supplementary group list matches one of the patterns. Only group names are valid; a numerical group ID is not recognized. By default, login is allowed for all groups. The allow/deny directives are processed in the following order: DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups. and finally, update the documentation to reflect this. The downside is that this is a major change in behavior; the upside is that it is consistent with other things that Debian does. -dsr-
Re: openssh-server's default config is dangerous
-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 corresponding > > user's password. As we know, people do not necessarily use the most > > secure of passwords. This will especially be the case if the user > > does not expect his computer to be accessible in any way from the > > outside. > > 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? I still think the OP has a point. I don't know how a solution might look which makes sense (a default config with password disabled seems a bit strong, TBH), but IMHO it's worth thinking about the problem instead of dismissing it off-hand. 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. regards - -- t -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAleE4JYACgkQBcgs9XrR2kaTLQCfWSYLS3FE7Q/oZW3tCwYvAQ9E +MsAmQEDTqNlkQ2LWVvAb49ZCHM1rUdU =F3W6 -END PGP SIGNATURE-
Re: openssh-server's default config is dangerous
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. This will especially be the case if the user > does not expect his computer to be accessible in any way from the > outside. 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? Reco
Re: epson L210 scan
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, manpages). In the event there is no open source alternative, it seems that Epson does provide a deb for scanning with your device here: http://support.epson.net/linux/en/iscan_c.php?version=1.0.1 Good luck. -- Même l’avenir n’est plus ce qu’il était. Paul Valéry
Re: openssh-server's default config is dangerous
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 think the problem you raise is not specific to SSH: when installing > anything that looks like a deamon, apt will start the daemon with its > default configuration immediately. There are hackish ways of working around > it, and I do not even know if they work with systemd. > > I always found that behaviour very bad, for many reasons. IMHO, starting > daemons after installing them should be an option. The behaviour is sensible and acceptable. Anyone who installs a daemon wants to use it; why install it in the first place? If the defaults were unsafe it would be a bug. A single example of such an unsafe configuration would be nice to have.
Re: epson L210 scan
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-find-scanner > ># sane-find-scanner will now attempt to detect your scanner. If the ># result is different from what you expected, first make sure your ># scanner is powered up and properly connected to your computer. > ># No SCSI scanners found. If you expected something different, make sure > that ># you have loaded a kernel SCSI driver for your SCSI adapter. > > could not open USB device 0x1d6b/0x0003 at 002:001: Access denied > (insufficient permissions) > found USB scanner (vendor=0x04b8 [EPSON], product=0x08a1 [EPSON L210 Ok up to there. The scanner has been found. That does not mean it can be used. Only 'scanimage -L' will tell us if there is a backend driver for this model. [...Snip...] > :~$ 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 make a judgement. Without a consistent output xsane will not work reliably. In fact, no scanner frontend will work reliably, including what you have from Epson. > --- > as a root: > :~$ sudo sane-find-scanner [...Snip...] > :~$ sudo scanimage -L > > No scanners were identified. If you were expecting something different, If you get this again as a user please post the last few lines shown by 'journalctl'.
Re: openssh-server's default config is dangerous
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 anything that looks like a deamon, apt will start the daemon with its default configuration immediately. There are hackish ways of working around it, and I do not even know if they work with systemd. I always found that behaviour very bad, for many reasons. IMHO, starting daemons after installing them should be an option. Regards, -- Nicolas George signature.asc Description: Digital signature
openssh-server's default config is dangerous
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 corresponding user's password. As we know, people do not necessarily use the most secure of passwords. This will especially be the case if the user does not expect his computer to be accessible in any way from the outside. But wait, why would someone install openssh-server if he does not plan on having his account being accessible through a network? Well, there are several possible scenarios: - The user is unsure what package he should install to e.g. get access to an ssh client, and so installs several related looking packages. - The user installs it by mistake by using e.g. a regex sudo apt-get install ^openssh not knowing there is an openssh-server package. - The user installs it to perform a task temporarily, e.g. to make a backup via rsync, and forgets to remove it. - Someone maliciously instructs the user to install the package. The user thinks this is safe since the package is part of the official repository. - But the main cause will be all of openssh-server's reverse dependencies. They can be listed with apt-cache rdepends openssh-server The worse offender I can see is the 'ssh' package: many people wanting an ssh client will likely just do a sudo apt-get install ssh and unwittingly end up with the server as well. - And so on... In any case, I feel that the mere installation of a package should never expose the system to new vulnerabilities, save in the case of an unknown bug of course. Furthermore, it would be considered bad security practice by pretty much any competent system administrator to use password authentication for ssh anyway. Why do the debian packagers feel it is okay to have bad security be the default? I have found that even I –a reasonably seasoned debian user– have accidentally exposed some machines on my network. Indeed, the reason, I started writing this is that I very recently found an affected device on my home network using nmap. And I dearly hope I have not left such a gaping security hole in a family member or a friend's laptop on which I helped install Ubuntu, which has the same problem by the way. I believe the current behaviour to be extremely dangerous, and that it could be (and probably has been) used to attack laptops, especially on public wifi, employees' computers on corporate networks, and personal computers on home networks (especially with IPv6 and no or poorly configured firewall). I do not know if this is the best place to start this discussion, but hopefully some changes can come of it. -- mwnx GPG: AEC9 554B 07BD F60D 75A3 AF6A 44E8 E4D4 0312 C726
Re: password problem
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 a display manager? He says no matter how many tries, so I suppose many thousands of attempts have been made, which is praise-worthy from an obstination perspective (I'm just kidding). No, you're right, go to the console if that hasn't already been done and give it a try (while verifying that there isn't some sort of keymap problem, which happened to me once or twice). > I'm certain you know how to get there, but just in case you don't remember... > > > > > ciao, > > der.hans > >> I've run into this before and it always ended in a reinstall, which >> didn't always solve the problem. >> -- Même l’avenir n’est plus ce qu’il était. Paul Valéry
