Re: RedShift
On 6/25/21 5:19 AM, ToddAndMargo via users wrote: Hi All, Fedora 34 Xfce 4.14 redshift-1.12-11.fc34.x86_64 redshift-gtk-1.12-11.fc34.x86_64 Hi All, Red Shift is all screwed up again: Unable to connect to GeoClue. Unable to get location from provider: https://github.com/jonls/redshift/issues/318#issuecomment-865667340 is back in full force. Is there an alternatives to Red Shift? Gnome integrated this in its own settings as a "Night Light" couple of years back and I am using that to satisfaction. But I assume it will not solve your issues on xfce ... https://www.addictivetips.com/ubuntu-linux-tips/gnome-night-light-mode/ Regards, -- Jakub Jelen Crypto Team, Security Engineering Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Deprecating SCP
On 11/5/20 7:49 PM, Michael Hennebry wrote: On Wed, 4 Nov 2020, George N. White III wrote: On Wed, 4 Nov 2020 at 11:39, Michael Hennebry < henne...@web.cs.ndsu.nodak.edu> wrote: In this particular case, I'd think the client could tell that a .BAT file was not a .c file. Downloading 1000's of files resulting from some HPC calculation it would be easy to overlook an unwanted file. To be clear, I'd meant the client could to it automatically. To be clear, the scp client does finename matching already by default. But if there is a recursive download (or a regex matching the malicious file), this might not help either. Not even using sftp, if the file is sneaked inside of the downloaded directory. But breaking scp protocol to do that is a matter of inserting one command, while SFTP requires significantly more work and the downloads can be properly audited (unlike scp, which is just a command on the server). Regards, -- Jakub Jelen Senior Software Engineer Crypto Team, Security Engineering Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Deprecating SCP
On 11/2/20 4:57 PM, francis.montag...@inria.fr wrote: Hi. On Mon, 02 Nov 2020 15:44:39 +0100 Jakub Jelen wrote: Is this something you would like to see in Fedora soon? No. I prefer a lot to use rsync, because scp: - has no dry-run mode - is not incremental - follows symlinks when used with the -r option - has too few options: no --chown --chgrp Then you are indeed not the target group. Do you have something against this? No: users should be free to continue using it (but not with the -r option IMO). The vulnerability of the -r was not the only issue found in scp over last years. And recursive copying of files is handy so I do not think it is a good idea to axe just one commandline switch. Is your use case missing? With scp no, but I use sshfs for years. This is IMO something to promote. Ex: Example: a simple 3-way copy, assuming you have root SSH access (with keys) mkdir /mnt/hostA sshfs -o transform_symlinks root@hostA:/ /mnt/hostA rsync -a --delete /mnt/hostA/etc/skel/ root@hostB:/etc/skel sshfs is using sftp internally so you are already using the sftp. Congratulations. Regards, -- Jakub Jelen Senior Software Engineer Crypto Team, Security Engineering Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Deprecating SCP
On 11/2/20 5:13 PM, Joe Wulf via users wrote: Improving the state of security for SCP is overdue. Like you've said, Jakub, the code just hasn't been worked on in a long time, nor been well-maintained. I am curious to better understand if the scp binary, as implemented, has security-related issues of concern here (along with old code), or if the protocol being used is the significant issue; or maybe a mixture of both. It is a mixture of both. There were issues where malicious servers could write any file on the client, including .ssh/known_hosts or authorized_keys while downloading other files. These were labeled as CVE-2019-6111, CVE-2019-6110, CVE-2019-6109. These were issues of design of the SCP protocol (based on RCP, which is almost 40 years old) and implementation. There was another issue CVE-2020-15778, which could allow remote code execution and there might be more to be found. The above were fixed, but CVE-2019-6111 already caused some backward incompatible changes. At this point, almost any direction to improve scp is welcome and appreciated by many. One challenge for adoption of the method you are proposing (and working on), is that conflict between the easy/casual use of scp via established channels where ssh is already accepted (keys, etc) versus those environments (or set of systems) where an sftp server running is forbidden due to security hardening requirements. If there are policies preventing the use of sftp, while allowing scp, they are bogus and need to be reconsidered. Even though SFTP is more complex, it supports much more fine-grained access configuration, including readonly access, which is not possible with scp at all. Similarly, if something was not possible with scp (change permissions, create directory), one could connect through ssh, which usually works and do it in the terminal. SFTP provides access control around these operations too. Security hardening is a scrupulous effort in many places. Reduce the attack surface, is but one mantra. As others have pointed out, the ease with which to quickly move some files will never go away, and in that regard, scp has been 'good enough' both from a functionality, as well as security-hardening, perspectives. Proposing/discussing how to approach the deprecation of scp-as-we-know-it-today would help, too. I would suggest to re-evaluate the hardening requirements as a start. What will happen with scp as we know today is still open question and I do not expect it will be gone in 5 years, but people and policies should start to learn the difference and advantage of the sftp now. Regards, Jakub Thank you. R, -Joe Wulf On Monday, November 2, 2020, 10:54:59 AM EST, Jakub Jelen wrote: On 11/2/20 4:36 PM, Kamil Dudka wrote: > On Monday, November 2, 2020 3:44:39 PM CET Jakub Jelen wrote: >> Hi Fedora users! >> >> Over the last years, there were several issues in the SCP protocol, >> which lead us into discussions if we can get rid of it in upstream [1]. >> Most of the voices there said that they use SCP mostly for simple ad-hoc >> copy and because sftp utility does not provide simple interface to copy >> one or couple of files back and forth and because of people are just >> used to write scp rather than sftp. >> >> Some months ago, I wrote a patch [2] for scp to use SFTP internally >> (with possibility to change it back using -M scp) and ran it through >> some successful testing. The general feedback from upstream was also >> quite positive so I would like to hear also opinions from our users. >> >> It still has some limitations (missing -3 support, it will not work if >> the server does not run sftp subsystem, ...), but it should be good >> enough for most common use cases. >> >> Today, I set up a copr repository with the current openssh from Fedora + >> the patch [2] for anyone to test and provide feedback, either here on >> the mailing list, or in the github PR according to ones preferences. >> >> I am looking for any kind of feedback from the idea through the >> usability, implementation. Is this something you would like to see in >> Fedora soon? Do you have something against this? Is your use case missing? >> >> [1] >> https://lists.mindrot.org/pipermail/openssh-unix-dev/2020-June/038594.html >> [2] https://github.com/openssh/openssh-portable/pull/194/ >> [3] https://copr.fedorainfracloud.org/coprs/jjelen/openssh-sftp/ > > How is the "compatibility scpd to support old clients" going to differ > from the current implementation? I can think of a solution that in the end, there will be just the server parts of the current scp and the client code branches will be gone or support sftp only. But this can change as we are not there yet. > libcur
Re: Deprecating SCP
On 11/2/20 4:09 PM, Ian Pilcher wrote: On 11/2/20 8:44 AM, Jakub Jelen wrote: I am looking for any kind of feedback from the idea through the usability, implementation. Is this something you would like to see in Fedora soon? Do you have something against this? Is your use case missing? What impact will this have on compatibility with other operating systems (Windows 10, etc.)? If you are able to run sftp server on Windows, you will be able to connect to it as before. Regards, -- Jakub Jelen Senior Software Engineer Crypto Team, Security Engineering Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Deprecating SCP
On 11/2/20 4:36 PM, Kamil Dudka wrote: On Monday, November 2, 2020 3:44:39 PM CET Jakub Jelen wrote: Hi Fedora users! Over the last years, there were several issues in the SCP protocol, which lead us into discussions if we can get rid of it in upstream [1]. Most of the voices there said that they use SCP mostly for simple ad-hoc copy and because sftp utility does not provide simple interface to copy one or couple of files back and forth and because of people are just used to write scp rather than sftp. Some months ago, I wrote a patch [2] for scp to use SFTP internally (with possibility to change it back using -M scp) and ran it through some successful testing. The general feedback from upstream was also quite positive so I would like to hear also opinions from our users. It still has some limitations (missing -3 support, it will not work if the server does not run sftp subsystem, ...), but it should be good enough for most common use cases. Today, I set up a copr repository with the current openssh from Fedora + the patch [2] for anyone to test and provide feedback, either here on the mailing list, or in the github PR according to ones preferences. I am looking for any kind of feedback from the idea through the usability, implementation. Is this something you would like to see in Fedora soon? Do you have something against this? Is your use case missing? [1] https://lists.mindrot.org/pipermail/openssh-unix-dev/2020-June/038594.html [2] https://github.com/openssh/openssh-portable/pull/194/ [3] https://copr.fedorainfracloud.org/coprs/jjelen/openssh-sftp/ How is the "compatibility scpd to support old clients" going to differ from the current implementation? I can think of a solution that in the end, there will be just the server parts of the current scp and the client code branches will be gone or support sftp only. But this can change as we are not there yet. libcurl implements its own SCP client over libssh. Will this implementation continue to work after OpenSSH gets updated on servers? With the above update, everything will work as before -- it affects only the client scp binary. Applications often allow users to pass arbitrary URLs to libcurl. So one can, for example, use scp:// URLs to specify a kickstart for Anaconda. The fact that scp utility will be reimplemented over SFTP does not help much in this case. Each build of libcurl that supports scp:// supports sftp:// as well. But libcurl will not transmit scp:// requests over sftp:// in case SCP is not supported by the remote server any more. As Simo wrote, I think it is something that will have to happen sooner or later inside of libcurl or libssh or in users configurations. But again, the above change should not have any effect on this. Regards, -- Jakub Jelen Senior Software Engineer Crypto Team, Security Engineering Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: [Fedora] Deprecating SCP
On 11/2/20 3:57 PM, Walter Cazzola wrote: Hi, I don't know if and how the internet protocol scp: is related to the scp command. But I suppose it is. Hi, SCP is not an internet protocol -- it is simple protocol that is used inside of encrypted SSH session, similarly to SFTP protocol. The name comes from RCP which actually was unencrypted internet protocol and which is hopefully gone. I'm using scp: a lot to edit remote files with vim and I'm pretty sure that many remote admins are doing the same. So I'm wondering how this change will affect my use case scenario and if you have considered it when moving to sftp. That is a good question! When I try to use scp://host/file I am getting errors that vim is trying to use `rcp` command (yuck!). But using the same with sftp://host/file works like a charm. I believe vim is using just scp to fetch the file so if the connection to the server will work also with sftp, it should continue to work (but I recommend using sftp protocol anyway). The simplest way to try is to try with sftp:// or try the previously mentioned package, but my best bet is that it will keep on working as before (even though I never used this inside of vim up until today). Regards, Jakub Thank you Walter On Mon, 2 Nov 2020, Jakub Jelen wrote: Hi Fedora users! Over the last years, there were several issues in the SCP protocol, which lead us into discussions if we can get rid of it in upstream [1]. Most of the voices there said that they use SCP mostly for simple ad-hoc copy and because sftp utility does not provide simple interface to copy one or couple of files back and forth and because of people are just used to write scp rather than sftp. Some months ago, I wrote a patch [2] for scp to use SFTP internally (with possibility to change it back using -M scp) and ran it through some successful testing. The general feedback from upstream was also quite positive so I would like to hear also opinions from our users. It still has some limitations (missing -3 support, it will not work if the server does not run sftp subsystem, ...), but it should be good enough for most common use cases. Today, I set up a copr repository with the current openssh from Fedora + the patch [2] for anyone to test and provide feedback, either here on the mailing list, or in the github PR according to ones preferences. I am looking for any kind of feedback from the idea through the usability, implementation. Is this something you would like to see in Fedora soon? Do you have something against this? Is your use case missing? [1] https://lists.mindrot.org/pipermail/openssh-unix-dev/2020-June/038594.html [2] https://github.com/openssh/openssh-portable/pull/194/ [3] https://copr.fedorainfracloud.org/coprs/jjelen/openssh-sftp/ Thanks, -- Jakub Jelen Senior Software Engineer Crypto Team, Security Engineering Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Deprecating SCP
Hi Fedora users! Over the last years, there were several issues in the SCP protocol, which lead us into discussions if we can get rid of it in upstream [1]. Most of the voices there said that they use SCP mostly for simple ad-hoc copy and because sftp utility does not provide simple interface to copy one or couple of files back and forth and because of people are just used to write scp rather than sftp. Some months ago, I wrote a patch [2] for scp to use SFTP internally (with possibility to change it back using -M scp) and ran it through some successful testing. The general feedback from upstream was also quite positive so I would like to hear also opinions from our users. It still has some limitations (missing -3 support, it will not work if the server does not run sftp subsystem, ...), but it should be good enough for most common use cases. Today, I set up a copr repository with the current openssh from Fedora + the patch [2] for anyone to test and provide feedback, either here on the mailing list, or in the github PR according to ones preferences. I am looking for any kind of feedback from the idea through the usability, implementation. Is this something you would like to see in Fedora soon? Do you have something against this? Is your use case missing? [1] https://lists.mindrot.org/pipermail/openssh-unix-dev/2020-June/038594.html [2] https://github.com/openssh/openssh-portable/pull/194/ [3] https://copr.fedorainfracloud.org/coprs/jjelen/openssh-sftp/ Thanks, -- Jakub Jelen Senior Software Engineer Crypto Team, Security Engineering Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: EXTERNAL: Re: sshd on F31 : strange problem with login with keys's
On Thu, 2019-11-28 at 16:27 +, Wells, Roger K. via users wrote: > On 11/26/19 8:32 AM, Ed Greshko wrote: > > On 2019-11-26 20:27, Jouk Jansen wrote: > > > I'm trying to setup an ssh-server on F31 which logs a user in > > > without a > > > password, but with a key-exchange. I generated all the keys and > > > placed them > > > in the right locations. It still asks for the password. > > > > > > Than comes the strange : I stoped the service by "systemctl stop > > > sshd" and > > > did run "as root" /usr/sbin/sshd. And than it just worked. (tried > > > to stop > > > and start with systemctl again made the passwordless login fail > > > again) > > > > > > Question : why does is work with just running "/usr/sbin/sshd" > > > but not with > > > "systemctl start sshd" ? > > One thing you should check is the permissions on the ~/.ssh on the > > machine you're trying to connect > > to. If it is not 700 you will get the behavior you cite. > I've seen this on several fedora updates. Something changes > permissions > on ~/.ssh and then what you see happens Nothing changes permissions on updates on itself. The .ssh directory was copied from somewhere else and it retained its SELinux context or wrong modes. Regards, -- Jakub Jelen Senior Software Engineer Security Technologies Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Fedora 32 Firefox and DNS over HTTPS
On Wed, 2019-11-27 at 15:17 -0800, Kevin Fenzi wrote: > On Wed, Nov 27, 2019 at 04:43:06PM -0500, Robert Moskowitz wrote: > > In the upcoming Fedora 32, is Firefox defaulting to DNS over HTTPS > > (RFC > > 8484)? > > No. firefox in fedora will not default enable this. > > https://bugzilla.redhat.com/show_bug.cgi?id=1751410#c2 Great to hear that Fedora is shielding us from these half-baked ideas (or contracts?). Last time it was unsolicited browser extension, now it is DoH to CloudFlare servers. What will be next? I recommend the following thread: https://twitter.com/paulvixie/status/1198013742493028353 Many users are used to Firefox now. But was there some discussion about providing some more privacy-focused browser? Regards, -- Jakub Jelen Senior Software Engineer Security Technologies Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: (fedora) Re: sshd on F31 : strange problem with login with keys's
On Wed, 2019-11-27 at 13:47 +0100, Jouk Jansen wrote: > Jakub Jelen wrote on 27-NOV-2019 13:20:25.09 > > > On Tue, 2019-11-26 at 13:27 +0100, Jouk Jansen wrote: > [snip] > > > Question : why does is work with just running "/usr/sbin/sshd" > > > but > > > not with > > > "systemctl start sshd" ? > > This sounds like an issue with selinux permissions on the > > authorizied > > keys file or path to it. Configure sshd to run in debug mode by > > setting > > LogLevel DEBUG3 in sshd_config, restart the service and retry. The > > logs > > will show up in journal and in /var/log/secure pointing the reason > > why > > your key was rejected. > > You are right. I switched selinux off (setenforce 0) and the problem > is > gone. I could not find an entry in the journalctl -e output (but > maybe I > overlooked (too many records)). Perhaps I should look in the selinux > logs, > but where do I find them? Hello. I would start with sshd logs as I described above. The selinux denials are in /var/log/audit/audit.log but they sometimes do not give enough information what is wrong. Regards, -- Jakub Jelen Senior Software Engineer Security Technologies Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: sshd on F31 : strange problem with login with keys's
On Tue, 2019-11-26 at 13:27 +0100, Jouk Jansen wrote: > Hi All, > > I'm trying to setup an ssh-server on F31 which logs a user in without > a > password, but with a key-exchange. I generated all the keys and > placed them > in the right locations. It still asks for the password. > > Than comes the strange : I stoped the service by "systemctl stop > sshd" and > did run "as root" /usr/sbin/sshd. And than it just worked. (tried to > stop > and start with systemctl again made the passwordless login fail > again) > > Question : why does is work with just running "/usr/sbin/sshd" but > not with > "systemctl start sshd" ? This sounds like an issue with selinux permissions on the authorizied keys file or path to it. Configure sshd to run in debug mode by setting LogLevel DEBUG3 in sshd_config, restart the service and retry. The logs will show up in journal and in /var/log/secure pointing the reason why your key was rejected. Regards, -- Jakub Jelen Senior Software Engineer Security Technologies Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: SSH after upgrade
On Mon, 2019-10-07 at 14:13 +0200, Marko Vojinovic wrote: > On Mon, 07 Oct 2019 10:38:32 +0200 > Jakub Jelen wrote: > > > On Mon, 2019-10-07 at 02:53 +0200, Marko Vojinovic wrote: > > > On Mon, 7 Oct 2019 10:21:03 +1100 > > > Cameron Simpson wrote: > > > > On 07Oct2019 01:00, Marko Vojinovic wrote: > > > > > On Sun, 06 Oct 2019 18:05:02 +0200 > > > > > alcir...@gmail.com wrote: > > > > > > It could it be related to this change: > > > > > > https://fedoraproject.org/wiki/Releases/31/ChangeSet#Disable_Root_Password_Login_in_SSH > > > > > > > > > > As a side question --- I remember that this was the default > > > > > for > > > > > upstream OpenSSH since 2015, but was not adopted in Fedora > > > > > because > > > > > people who install Fedora on headless machines (or remotely) > > > > > would > > > > > have no other way of logging in after initial installation. > > > > > So > > > > > why > > > > > the change of heart now, what happened to the headless login > > > > > issue? > > > > > > > > Because one can generally set up a normal user, log in as them, > > > > then > > > > su or sudo. > > > > > > Was this not possible back in 2015? > > > > > > I guess I am asking what technically changed between then and > > > now, > > > so that we didn't block root back then and we are doing it now? > > > > Please, read the whole fedora change page. It answers all your > > questions. > > Well, the relevant sentence from the change page says: > > "Fedora was for many practical reasons keeping the old configuration > since then, but the difference is no longer bearable" > > Can you please elaborate what were the "many practical reasons" that > prevented this from being changed for the last 5 years? And why are > they not equally practical now? Mostly the unwillingness of people who were used to use root accounts in Fedora and not enough alternatives how to override or set up alternative during installation. The initial change was half-baked proposed 5 years ago: https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no but never accepted by FeSCO (note sure if it was even proposed) and started long discussions on mailing lists as linked from there. Since then, we did not change the value to "no", but we disabled only the password logins, we added a simple way how to override this in anaconda installer and there are simple ways how to override it in kickstarts or add a public ssh keys to authorized_keys files. > Don't get me wrong, I fully support this change, disabling ssh root > login is the very first thing I do every time I install a new system. > And each time I ask myself why on earth isn't this the default, but I > sort-of remember (from various discussions on this mailing list back > in > 2015 or so) that people had good reasons to keep it that way. I think it was mostly testing and scratch boxes that needed root logins (specific use cases), making sure that there is some other account that is allowed to login after installation (installation problems). But I think I did not manage to read that thread this year again. > And now > that I see the default is going to be changed, I'm curious what were > those reasons and what happened to them --- how come they were > good enough for the last five years, and are not good enough now? 5 years ago, there were no simple workarounds for the installation. Even this year, the agreement was not really smooth and updating installer was one of the requirements for the change to be approved: https://pagure.io/fesco/issue/2133 This change request is in Fedora actually for more than 15 years: https://bugzilla.redhat.com/show_bug.cgi?id=89216 Back in that time, this was not default even in upstream and many people were using root accounts. > What > changed? Or else, why wasn't this done already back in 2015? I think that over the years, the security practices shifted to better solutions, people learned to use normal users, sudo and ssh keys, which allowed us to do this finally. Originally the change would be a surprise for users, but recently, people were surprised by the root login allowed in Fedora, which also started to be dangerous. Regards, Jakub > Best, :-) > Marko > > > > > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/
Re: SSH after upgrade
On Mon, 2019-10-07 at 02:53 +0200, Marko Vojinovic wrote: > On Mon, 7 Oct 2019 10:21:03 +1100 > Cameron Simpson wrote: > > > On 07Oct2019 01:00, Marko Vojinovic wrote: > > > On Sun, 06 Oct 2019 18:05:02 +0200 > > > alcir...@gmail.com wrote: > > > > It could it be related to this change: > > > > https://fedoraproject.org/wiki/Releases/31/ChangeSet#Disable_Root_Password_Login_in_SSH > > > > > > As a side question --- I remember that this was the default for > > > upstream OpenSSH since 2015, but was not adopted in Fedora > > > because > > > people who install Fedora on headless machines (or remotely) > > > would > > > have no other way of logging in after initial installation. So > > > why > > > the change of heart now, what happened to the headless login > > > issue? > > > > Because one can generally set up a normal user, log in as them, > > then > > su or sudo. > > Was this not possible back in 2015? > > I guess I am asking what technically changed between then and now, so > that we didn't block root back then and we are doing it now? Please, read the whole fedora change page. It answers all your questions. You can always install public keys for root during kickstart (it might not have been that easy before) or allow password root logins from Anaconda (which is new feature in F31). Regards, -- Jakub Jelen Senior Software Engineer Security Technologies Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: [SOLVED] SSH after upgrade
On Sun, 2019-10-06 at 11:15 -0500, Mike Chambers wrote: > On Sun, 2019-10-06 at 18:05 +0200, alcir...@gmail.com wrote: > > On Sun, 2019-10-06 at 10:46 -0500, Mike Chambers wrote: > > > Upgraded server from Fedora 30 to 31 (updated to present), and > > > ssh > > > into > > > that server works fine as normal user, but no longer lets me > > > login > > > as > > > root. I can login as root from the server machine itself, and > > > can > > > login via su - but just cant' from ssh. > > > > > > Any ideas what changed or got replaced so revert it back? > > > > It could it be related to this change: > > https://fedoraproject.org/wiki/Releases/31/ChangeSet#Disable_Root_Password_Login_in_SSH > > Had to add the below line to my sshd.conf file and works now. > > PermitRootLogin yes > > Guess it changed or got removed when I did the upgrade (upgraded via > dnf, not a clean install), but added that line and it works now. No, this IS intentional change of Fedora 31 to disable password root logins. This account is very frequent target of brute-force attacks (and this change was made by upstream OpenSSH years ago). Please, do not advise this as a general solution. The correct solution is to setup public key authentication or use different user and sudo for the administrative tasks. Regards, -- Jakub Jelen Senior Software Engineer Security Technologies Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Volume/mute/brightness keys stopped working
On Tue, 2019-08-13 at 03:23 -0500, Ian Pilcher wrote: > I have a Dell Precision 5520 laptop (basically an XPS 15). The > volume, > mute, and brightness "function" keys have always just worked on this > laptop with no additional configuration required ... until now. > > Something has changed in the last week or two, and the keys no longer > have any effect (except that the brightness increase key now toggles > the maximized state of terminal windows). > > Anyone else seen this recently? > > Assuming no, anyone have any hints on how to debug this? I'm not > really > sure how these function keys work (i.e. are they keypresses, ACPI > events, something else?). > > Any thoughts appreciated. Thanks! I think something like this happened to my Thinpad also during last weeks, but after some time, it started to work again. Did you try to reboot? Regards, -- Jakub Jelen Senior Software Engineer Security Technologies Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: OSM??
On Tue, 2019-05-21 at 14:52 -0700, Clifford Snow wrote: > What exactly are you trying to accomplish? I've never heard of an > .iso. > There is a java based editor, JOSM. I believe their might be a repo > for it, > but I find just downloading the new JAR file every once in a while > works > satisfactorily. Josm is packaged in Fedora so dnf install josm is enough. > The OSM database, we call the plant, is quite large. It needs to be > downloaded from planet.openstreetmap.org. GeoFribrik at > download.geofabrik.de has extracts for parts of the world. And HOTOSM > has > an export tool, https://export.hotosm.org/en/v3/, to grab areas for > download. > > If you want to duplicate the website, look on github. > > Gnome does have a extension with an OSM map which I find out of date > so I > don't use it. > > Best, > Clifford AKA Glassman on OSM > > > > On Tue, May 21, 2019 at 10:26 AM Beartooth > wrote: > > > Can dnf get me OSM? I tried osm, OSM, and openstreetmap. I > > don't > > doubt there's some sort of .iso on their own site, but with a > > program so > > vast ... > > > > -- > > Beartooth Staffwright, Not Quite Clueless Power User > > Remember I know little (precious little!) of where up is. > > ___ > > users mailing list -- users@lists.fedoraproject.org > > To unsubscribe send an email to users-le...@lists.fedoraproject.org > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > > > > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org -- Jakub Jelen Senior Software Engineer Security Technologies Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: update failed
On Mon, 2019-02-25 at 09:33 -0500, Frank McCormick wrote: > Tried to update my Fedora 29 this morning. It failed > > with this error: > > > [SKIPPED] google-chrome-stable-72.0.3626.119-1.x86_64.rpm: Already > downloaded > Package ffmpeg-4.1.1-7.fc29.x86_64.rpm is not signed > Package ffmpeg-libs-4.1.1-7.fc29.x86_64.rpm is not signed > Package libavdevice-4.1.1-7.fc29.x86_64.rpm is not signed > The downloaded packages were saved in cache until the next > successful > transaction. > You can remove cached packages by executing 'dnf clean packages'. > Error: GPG check FAILED > > > Is there a work around or should I just wait ? $ dnf info google-chrome-stable Error: No matching Packages to list There is no chrome package in Fedora. If you have issues with updates from third party repositories, it is probably better to ask where you got these repositories from. Note, that chromium works fine. Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Extremely slow Josm
Hello, do you have the same version from Fedora repositories on both? You can try also to run the jnlp from https://josm.openstreetmap.de/ or even flatpack https://flathub.org/apps/details/org.openstreetmap.josm The speed of running can be also caused by the hardware (you did not point out if the hardware is similar or completely different). There are many possibilities. Do you have some josm plugins installed? Cleaning up some configuration directories might also help, but I never had a problem with JOSM performance (except for the fact that it is a java application). Regards, Jakub On Thu, 2019-01-03 at 22:05 +0100, Robin Lee wrote: > Hi > > I have a desktop and a laptop, both with fully updated Fedora 29. The > laptop is a fresh installation while the desktop has been upgraded > from > previous versions of Fedora. And I have Josm installed on both. > > Now the problem is that on the desktop Josm has become really slow. > You > need some serious patience to use it. On the laptop it works fine as > it > did on the desktop before. I've tried to reinstall Josm, but that > didn't help. > > Josm is a Java application. > > Any idea what could be wrong? > > Cheers > Robin > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org -- Jakub Jelen Software Engineer Security Technologies Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: scp over wireless is slow
On Sun, 2018-09-02 at 22:16 -0600, Chris Murphy wrote: > Fedora 28 Server > Fedora 28 Workstation > dd-wrt 802.11n Broadcom based router > Connected wirelessly 5GHz, wired ethernet cable is physically > disconnected from Server > > File transfer from Workstation to Server > > scp: scp itself reports ~620KB/s; where nload on the server reports > ~4.9Mbit/s > smb: GNOME reports 4.9MB/s; where nload on the server reports > ~39.8Mbit/s > > Why? That's rather unexpected. > > Command is > scp test.bin f28s.local:/srv/scratch > > Using nc, I get speeds slightly faster than smb. OK so encryption? If > I connect wired, and then 'nmcli c down ' to disconnect the > wireless connection: > > scp: 12MB/s, nload ~101Mbit/s > smb: nload ~96Mbit/s > > So, it's not encryption. Why would scp be this much slower only > with a wireless connection? And using: > > rync -avzhe ssh test.bin f28s.local:/srv/scratch > > Over wireless, this is just as bad as scp. SCP protocol is really slow, especially on networks with high latency (wireless). The reason why is mostly the size of buffers, which is very small and SCP waits for every part to be confirmed by the remote host before sending another part. You can google "scp speed" and you will get a lot of answers, sometimes wrongly accusing the encryption or the compression, but really, the RTT and buffers are the fault as I write here: https://superuser.com/a/1101203/466930 SCP should be really used only as fast hack for copying files in fast local networks. For all other cases, use SFTP or rsync if you need something more complex. Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: SSH private keys?
On Sat, 2018-06-23 at 16:35 -0400, Jeffrey Ross wrote: > > On 06/22/2018 03:45 PM, Gordon Messmer wrote: > > On 06/22/2018 04:37 AM, Jeffrey Ross wrote: > > > Fast forward to today, the system had been reinstalled (new > > > hardware, > > > new disks, etc) and I no longer have that ability. I'm > > > currently > > > runn Fedora 28 and the desktop is "Gnome", I'm sure it is just a > > > matter of installing/configuring/running the correct > > > application > > > but which one? > > > > That's handled by gnome-keyring and, as of this version of GNOME, > > ssh-agent. As far as I can tell, those are both required > > components, > > so they're probably not missing on your workstation. The problem > > *might* be that GNOME keyring will only automatically unlock > > private > > keys if there is a valid public key with the same name, and a .pub > > suffix. So, you might not have the public keys. Or, you might have > > a > > .pub file that's *really* old and no longer valid. > > > > There is an open bug concerning the fact that if there is an > > invalid > > .pub file in .ssh, GNOME keyring won't automatically unlock *any* > > keys, so remove any old key files. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1568895 > > my .ssh directory has my private key in a file called "id_rsa" > nothing > with .pub on the end and if I understand correctly running ssh will > look > for the private key in a few different file names, none of which end > with .pub. Or use AddKeysToAgent option in ssh_config, which will automatically add the keys to the agent on first use. -- Jakub Jelen Software Engineer Security Technologies Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/message/YZZPIEZ6UVESJQDJ7E6DQ5CRCFNITMJR/
Re: Scroll Bars with Arrows Wanted
On Wed, 2018-01-24 at 16:47 -0500, fred roller wrote: > have you tried [shift]+[wheel] for horizontal scroll? > > -- Fred In Firefox, it scrolls through the history, which is not very useful. Regards, Jakub ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
HEADS UP: OpenSSH 7.6p1 in Fedora 27
Hello all, The OpenSSH 7.6p1 was submitted for testing in Fedora 27 [1]. Unfortunately I didn't manage to get it out before freeze since all the thing/bugs/upstream release somehow pilled up. On the other side, this package was already tested quite extensively during recent months by myself, using automated test cases and was in rawhide for last two weeks, where we caught last issues. If you have some "special" use case, please make sure it works for you after the update and leave a karma. [1] https://bodhi.fedoraproject.org/updates/FEDORA-2017-96d1995b70 Thank you, -- Jakub Jelen Software Engineer Security Technologies Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: rsync from F27 box causes higher (30x) cpu on F26 box?
Hello, this might be related to https://fedoraproject.org/wiki/Changes/OpenSSH_Server_Crypto_Policy Can you check what ciphers, macs were used in your Fedora 26 and what is used now? We can probably blame the change of the default cipher, from ChaCha20 to AES256, but I don't have the exact numbers. Can you try to uncomment last line of /etc/sysconfig/sshd to overwrite system-wide policy: CRYPTO_POLICY= If it has so significant performance impact, we should adjust the policy to prefer ChaCha20. Regards, Jakub Jelen On Thu, 2017-11-16 at 19:44 +0100, Kasper Pedersen wrote: > I have been poking at this for some hours, and by now I could use > a second opinion. Or clue. Thirteen black candles? > > > Somehow, when I sit on a F27 machine and pull from a F26 machine > using > rsync, something extremely inefficient happens in the F26 machine. > > If I sit on a F26 machine and pull from the F26 machine, it is fast. > > > The good state: > --- > I had 3 reasonable machines, all on F26: > > Server - 1.8Ghz Haswell-celeron dualcore > Desktop - 3.2GHz Haswell > Backup - 2.4GHz Core2Q > > Backup runs rsync, and pulls from Server and Desktop using ssh. > Nothing fancy, it copies and shuts itself down. > When Backup was reading from Server, Server would have about > > - 30% cpu to rsync > - 60% cpu to ssh > > and deliver 100MB/s reliably. So does Desktop. > > > The bad state: > -- > After one such rsync run, I upgraded Backup to F27. > When Backup pulls from Server, Server shows: > > - 99% cpu to rsync > - 6% cpu to ssh > > and it delivers **11MB/s**, one tenth of what it did before. > So, 30x higher cpu load per byte delivered. > > So, somehow, the rsync running on F27, which by the way reports > the same version and capabilities as the one on F26, triggers > something in the spawned process that behaves differently. > > > > On the server, the ssh-spawned rsync process looks the same whether > it is Backup or Desktop pulling from it: > > On Server, with Backup as client, 11MB/s: > root 25042 34.4 0.0 124996 5620 ?Rs 18:54 0:40 > rsync > --server --sender -vlogDtpre.iLsfxC . > /bulk/mux/media/xbn-2017_10_29_010103.m.ts > /bulk/mux/media/xbn-2017_11_04_235600.m.ts > /bulk/mux/media/xbn-2017_11_12_005938.m.ts > /bulk/mux/media/xbn-2017_11_12_011442.m.ts > /bulk/mux/media/xbn-2017_11_12_015031.m.ts > > > On server, with Desktop as client, 100MB/s: > root 25152 31.9 0.0 122344 3000 ?Rs 18:56 0:05 > rsync > --server --sender -vlogDtpre.iLsfxC . > /bulk/mux/media/xbn-2017_10_29_010103.m.ts > /bulk/mux/media/xbn-2017_11_04_235600.m.ts > /bulk/mux/media/xbn-2017_11_12_005938.m.ts > /bulk/mux/media/xbn-2017_11_12_011442.m.ts > /bulk/mux/media/xbn-2017_11_12_015031.m.ts > > The command being run on Backup or Desktop is: > rsync -av -e 'ssh -i id_ecdsa' --exclude XA/ --exclude video2/ > root@10.5.5.1:/bulk/mux/media/xbn* . --progress > > > > > Things I did: > - > Tried the still-installed F26 and F25 kernels > Desktop (F26) can rsync to and from Server(F26) at full speed. > All machines get 110MB/s when running iperf, all six ways. > The Sky2 nic in Backup is not spewing errors > iperf shows no dropped. > Swapped switchports between Desktop and Backup > Switch does not report errors > > Things to do: > - > swap nics > upgrade a sacrificial F26 machine to F27 and try from that ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: Cannot install bugzilla on F26: wrong error saying /var/lib/bugzilla/data/params.json file does not exist but it exists
On Thu, 2017-11-02 at 16:13 +0100, Frédéric wrote: > Hi, > > I am trying to install bugzilla. checksetup.pl is happy, the http > server is running (http://localhost shows something) but > http://localhost/bugzilla shows this strange message: > > The /var/lib/bugzilla/data/params.json file does not exist. You > probably need to run checksetup.pl. at Bugzilla/Config.pm line 334. > Compilation failed in require at /usr/share/bugzilla/index.cgi line > 15. > BEGIN failed--compilation aborted at /usr/share/bugzilla/index.cgi > line 15. > > However file /var/lib/bugzilla/data/params.json do exist! Does that file have proper permissions and SELinux context? Do you see some AVCs in audit log? Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: tcp_wrappers deprecation
On Fri, 2017-08-18 at 13:15 -0500, Jason L Tibbitts III wrote: > For the record, denyhosts currently relies upon the tcp_wrappers > functionality in openssh to function. While it's possible to make it > manipulate the firewall as well, the whole situation is kind of a > mess. > (Does it talk to firewalld? What if you're not running firewalld?) Unfortunately this is not as straightforward as it could be. Checking how Archlinux does it now, they probably go without denyhosts. There is a also a tool sshguard [1], which does quite much the same as fail2ban using configurable backend (firewalld, iptables, ...). The denyhosts got last update also 10 years ago [2] and we already have quite much 2 alternatives that can do the same using firewalls, so it might be also a time to go for denyhosts. Or not, but clearly document that OpenSSH will not be using hosts.deny anymore. > Sadly I know how terrible tcp_wrappers is and so I know it needs to > go > away. It's just unfortunate that there's no replacement for it > besides > firewalling, and dealing with the firewall is unfortunately so > complicated. > > So that's three of my packages that use tcp_wrappers in some way > (denyhosts, apcupsd and cyrus-imapd) though I suspect two of those > just > need the build dependencies dropped. That would be great if you could review the dependencies if it is used and drop the bogus dependencies. [1] https://wiki.archlinux.org/index.php/sshguard [2] https://sourceforge.net/projects/denyhosts/files/ Thanks, -- Jakub Jelen Software Engineer Security Technologies Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: tcp_wrappers deprecation
On Tue, 2017-08-15 at 13:58 +0200, Jakub Jelen wrote: > Hello Fedora devels and users, > > more than three years ago, the same topic started discussion if we > want > this package in Fedora or not and how [1]. The discussion resulted > mostly in flames and in the removal of the dependency on tcp_wrappers > from systemd. But it was quite agreed that it is considered as a > security layer for some users, if they use it correctly, or something > that is or should be replaced by firewalls. > > So can we discuss it now once more without the affiliation to > systemd? > The fact is that we still do not have any other replacement except > firewalls. But do we need one? > > The complete removal of the package is probably not a wise step, even > though we can not find tcp_wrappers in recent SuSE anymore [2]. It is > still available in Arch [3] without other tools depending on it. To > be > fair, Debian [4] is still building tools (for example openssh) with a > build-time support for it. > > My primary concern is OpenSSH, which upstream dropped support for > tcp_wrappers three years ago (late 2014) [5] and since then we are > maintaining one more downstream patch. But this effort should be > coordinated among other components to simplify the transition for > users > who insist on using it (using tcpd). > > Removing the dependency will also allow us to trim the default > install for few more Kb. > > If there will be no significant drawbacks, I will progress with > filling > a system wide change for Fedora 28 and I will pull the maintainers of > other tolls using libwrap into the round and discussion. Hello, In Fedora 26, there is over 50 packages using tcp_wrappers as a build- time dependency: $ dnf repoquery --whatrequires 'libwrap.so.0()(64bit)'|grep x86_64 389-ds-base-snmp-0:1.3.6.6-2.fc26.x86_64 rmeggins aeskulap-0:0.2.2-0.27.beta1.fc26.x86_64 jenslody apcupsd-0:3.14.14-5.fc26.x86_64 tibbs apcupsd-cgi-0:3.14.14-5.fc26.x86_64 apcupsd-gui-0:3.14.14-5.fc26.x86_64 apt-cacher-ng-0:0.9.0-3.fc26.x86_64 kenjiro audit-0:2.7.7-1.fc26.x86_64 sgrubb bacula-client-0:7.4.7-1.fc26.x86_64 slaanesh bacula-director-0:7.4.7-1.fc26.x86_64 bacula-libs-0:7.4.7-1.fc26.x86_64 bacula-storage-0:7.4.7-1.fc26.x86_64 bacula2-client-0:2.4.4-24.fc26.x86_64limb conserver-0:8.2.1-3.fc24.x86_64 jkastner ctk-devel-0:0.1-0.2.20151015gitbdc8cac.fc26.x86_64 bizdelnick ctk-dicom-0:0.1-0.2.20151015gitbdc8cac.fc26.x86_64 cyrus-imapd-0:3.0.1-7.fc26.x86_64landgraf dcmtk-0:3.6.1-4.fc24.x86_64 ignatenkobrain dovecot-1:2.2.31-3.fc26.x86_64 mhlavink exim-0:4.89-1.fc26.x86_64dwmw2 flow-tools-0:0.68.5.1-18.fc26.x86_64 stingray foghorn-0:0.1.6-12.fc26.x86_64 rohara gsi-openssh-server-0:7.5p1-1.fc26.x86_64 ellert libvirt-snmp-0:0.0.3-7.fc24.x86_64 mprivozn libyaz-0:5.14.11-6.fc26.x86_64 guidograzioli lldpd-0:0.9.7-5.fc26.x86_64 jhogarth net-snmp-1:5.7.3-15.fc26.x86_64 jsafrane net-snmp-agent-libs-1:5.7.3-15.fc26.x86_64 nfs-utils-1:2.1.1-5.rc4.fc26.x86_64 steved ngircd-0:24-2.fc26.x86_64ixs nrpe-0:3.0.1-4.fc26.x86_64 smooge nut-0:2.7.4-7.fc26.x86_64mhlavink ocserv-0:0.11.8-1.fc26.x86_64nmav openhpi-subagent-0:2.3.4-28.fc26.x86_64 sharkcz openldap-servers-0:2.4.44-10.fc26.x86_64 mhonek opensips-snmpstats-0:2.2.3-1.fc26.x86_64 ivaxer openssh-server-0:7.5p1-2.fc26.x86_64 jjelen pptpd-0:1.4.0-11.fc26.x86_64 jskarvad prelude-manager-0:3.1.0-2.fc26.x86_64totol proftpd-0:1.3.6-1.fc26.x86_64itamarjp ptpd-0:2.3.1-4.fc24.x86_64 pbrobinson pulseaudio-libs-0:10.0-4.fc26.x86_64 lennart quagga-0:1.1.1-2.fc26.x86_64 mruprich quota-rpc-1:4.03-8.fc26.x86_64 ppisar redir-0:2.2.1-16.fc26.x86_64 itamarjp rpcbind-0:0.2.4-7.rc2.fc26.x86_64steved rwhoisd-0:1.5.9.6-6.fc26.x86_64 ppisar sendmail-0:8.15.2-14.fc26.x86_64 jskarvad slapi-nis-0:0.56.1-2.fc26.x86_64 abbra sslh-0:1.18-2.fc26.x86_64jhogarth stunnel-0:5.41-1.fc26.x86_64 tmraz syslog-ng-0:3.9.1-1.fc26.x86_64 marcusk tcp_wrappers-devel-0:7.6-85.fc26.x86_64 jjelen tftp-server-0:5.2-20.fc26.x86_64 jsynacek up-imappro
tcp_wrappers deprecation
Hello Fedora devels and users, more than three years ago, the same topic started discussion if we want this package in Fedora or not and how [1]. The discussion resulted mostly in flames and in the removal of the dependency on tcp_wrappers from systemd. But it was quite agreed that it is considered as a security layer for some users, if they use it correctly, or something that is or should be replaced by firewalls. So can we discuss it now once more without the affiliation to systemd? The fact is that we still do not have any other replacement except firewalls. But do we need one? The complete removal of the package is probably not a wise step, even though we can not find tcp_wrappers in recent SuSE anymore [2]. It is still available in Arch [3] without other tools depending on it. To be fair, Debian [4] is still building tools (for example openssh) with a build-time support for it. My primary concern is OpenSSH, which upstream dropped support for tcp_wrappers three years ago (late 2014) [5] and since then we are maintaining one more downstream patch. But this effort should be coordinated among other components to simplify the transition for users who insist on using it (using tcpd). Removing the dependency will also allow us to trim the default install for few more Kb. If there will be no significant drawbacks, I will progress with filling a system wide change for Fedora 28 and I will pull the maintainers of other tolls using libwrap into the round and discussion. [1] https://lists.fedoraproject.org/pipermail/devel/2014-March/196913.h tml [2] https://www.rpmfind.net/linux/rpm2html/search.php?query=tcpd =Search+...== [3] https://www.archlinux.org/packages/community/x86_64/tcp-wrappers/ [4] https://packages.debian.org/sid/openssh-server [5] http://www.openssh.com/txt/release-6.7 Thank you for comments and constructive ideas. Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: SSH problem from BasicLinux floppy booted 486 to Fedora 25
On 03/13/2017 07:02 AM, Philip Rhoades wrote: People, I get an error trying to ssh from a BasicLinux floppy booted 486 (I want to sort out HD problems on the old Adaptec 1542 controlled SCSI drive that has RH5.2 on it!) when trying to connect to my Fedora 25 x86_64 workstation. On the F25 machine in /var/log/secure I get lines like: Mar 13 16:25:47 phil sshd[7562]: Unable to negotiate with 192.168.1.40 port 1034: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth] You are connecting from very old OpenSSH client (3.5), which does not support any of the currently secure cryptography algorithms. You should really consider updating that BasicLinux. Otherwise you can enable the legacy kex and ciphers in the Fedora OpenSSH server by following these instructions: http://www.openssh.com/legacy.html Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: ssh/screen question - thread
On 11/14/2016 02:17 AM, bruce wrote: I think I'm getting closer to an actual soln... ** Notice the backticks around the remote cmd to be run -without the ticks, the cmd doesn't appear to work ssh crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup ls -al /crawl_tmp/* > aa.tmp`" ' ssh crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup sleep 10`" ' ssh crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup sleep 10`" & ' If the backticks are required, ok the final part of the solution is to make the whole thing run the cmd in the screen session, but return back to the calling term, once the screen session/cmd starts. The backticks makes your command run in your local sub-shell, not the remote one. Also if you want interactive session, you need to use -t switch to the ssh command. In other words I want the long running/remote process to start running in the screen session and return the control to the calling term without waiting for the completion of the process. With the basic tests using the sleep func.. it appears that my current attempts aren't quite there yet. I don't want to put the remote/running cmd in the background, as that would disable the ability to see/view the display output of the process. Tried to put the screen process in the background.. no luck.. Thoughts/comments??? THanks On Sun, Nov 13, 2016 at 1:00 PM, Patrick O'Callaghan <pocallag...@gmail.com> wrote: On Sun, 2016-11-13 at 10:09 -0500, bruce wrote: The goal, to be able to reattach to a remote screen session, and to run a cmd in the remote screen session, and have the cmd return to the calling term Maybe take a look at expect (dnf info expect). poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org -- Jakub Jelen Software Engineer Security Technologies Red Hat ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: Annoying audit messages
On 09/27/2016 02:22 AM, Alex wrote: Hi, On Mon, Sep 26, 2016 at 2:53 PM, Patrick O'Callaghan <pocallag...@gmail.com> wrote: On Mon, 2016-09-26 at 14:46 -0400, Alex wrote: Hi all, I recall seeing an rsyslog entry to prevent these messages from filling my messages logs, but it no longer appears to work with f24. Is there a more specific method to disable audit messages? Sep 26 14:40:56 alex kernel: audit: type=2404 audit(1474915256.442:724): pid=3297 uid=0 auid=4294967295 ses=4294967295 msg='op=destroy kind=server fp=SHA256:c3:77:02:0b:2c:82:43:05:c5:50:ff:e6:99:f1:3f:1a:1d:6a:51:b7:a4:cb:45:55:37:66:95:46:51:9b:80:d2 direction=? spid=3297 suid=0 exe="/usr/sbin/sshd" hostname=? addr=107.155.77.2 terminal=? res=success' I'm not using selinux, and have enabled rsyslog. They're just not helpful to me. Edit /etc/default/grub. Look for the line beginning GRUB_CMDLINE_LINUX. Add "audit=0" to the end of that line. Run: grub2-mkconfig --output /boot/grub2/grub.cfg Audit will be turned off when you reboot. To turn it off without rebooting, do: auditctl -e 0 Thanks very much, very helpful. What is the reason this is enabled by default? Don't other people find it obnoxious and unhelpful? How does this information help the average sysadmin? Audit is not just a log. For that reason, it is not dumped to the same files (/var/log/secure, /var/log/messages) as other logs, but into separate file (/var/log/audit/audit.log), when you have auditd running (if you stop that, it is dumped into the messages, which might be confusing). It keeps track of actions that were performed somewhere on lower level than "average sysadmin" might need. In first place, they are needed for the certifications in some environments. In second place, it is helpful when you seek for more specific actions that were performed in the past. Your example shows an event, when the server private key was zeroed before exit or before changing to unprivileged process, who should not see the content of the private keys. Regards, -- Jakub Jelen Associate Software Engineer Security Technologies Red Hat ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: Slightly OT - connecting from Fedora to Windows 7 sftp/ssh using public keys
I would check https://github.com/PowerShell/Win32-OpenSSH Windows guys did some work and the openssh should work on Windows in some way. I didn't try that yet, but it seems working for some people. If you see authentication failures, there might be something unseful in the logs. On 03/22/2016 01:27 PM, Gary Stainburn wrote: I need a way to rebustly copy files from a Fedora server to a Windows box. As my usual environment is Linux by first thought was SCP, using Perl and Net::SCP. I first tried an OpenSSH install from the WinSCP site and had managed to connec to the Windows box using passwords, but could not get public keys to work either way. I then downloaded OpenSSH for Windows using the installer found at http://www.mls-software.com/opensshd.html Using this setup I can ssh from the Windows box to my Fedora server and it logs in successfully using keys. However, I still cannot connect from Fedora to Windows. Oddly, I do get the banner.txt file appear in the login attempt. Also oddly, the attemp doesn't drop down to passwords when the keys fail even though it has ... Regards, -- Jakub Jelen Associate Software Engineer Security Technologies Red Hat -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: sshd logging changed?
On 03/12/2016 02:26 PM, Tom Horsley wrote:
I noticed I got a sshd update recently. Now I have bazillions
of messages about disconnects:
Disconnected from NN.NN.NN.NN port 41236 : 1 time(s)
Received disconnect from NN.NN.NN.NN port 39642:11: disconnected by user : 1
time(s)
Logging in and logging out are are normal activities
in a working ssh. How the devil can I stop this logging
of utterly useless information? (Which for me happens
every 5 minutes due to a cron job I have running at
work that phones home :-).
I don't think these messages were not there before. But the format
changed a bit (added port number) and it is not handled by Logwatch as
it should be.
Sorry I didn't notice earlier before pushing that into F23. But this
needs to be fixed in Logwatch at least for F24. There is patch for the
second line, but I have no idea why the first was not visible before.
Can you please fill a bug on logwatch?
Kind regards,
--
Jakub Jelen
Security Technologies
Red Hat
--- /usr/share/logwatch/scripts/services/sshd.old 2015-08-25 10:53:58.0 +0200
+++ /usr/share/logwatch/scripts/services/sshd 2015-08-25 10:53:58.0 +0200
@@ -383,7 +383,7 @@
$RefusedConnections{$1}++;
} elsif ( my ($Reason) = ($ThisLine =~ /^Authentication refused: (.*)$/ ) ) {
$RefusedAuthentication{$Reason}++;
- } elsif ( my ($Host,$Reason) = ($ThisLine =~ /^Received disconnect from ([^ ]*): (.*)$/)) {
+ } elsif ( my ($Host,$Reason) = ($ThisLine =~ /^Received disconnect from ([^ ]*) port [^ ]*: (.*)$/)) {
# Reason 11 (SSH_DISCONNECT_BY_APPLICATION) is expected, and logged at severity level INFO
if ($Reason != 11) {$DisconnectReceived{$Reason}{$Host}++;}
} elsif ( my ($Host) = ($ThisLine =~ /^ROOT LOGIN REFUSED FROM ([^ ]*)$/)) {
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
Re: [HEADS UP]: OpenSSH 7.2 to Fedora 23
On 03/03/2016 09:31 AM, Corinna Vinschen wrote:
Hi Jakub,
On Mar 2 17:48, Jakub Jelen wrote:
Hi there,
I just pushed openssh-7.2 update [1] into Fedora 23 testing. There are no
incompatible changes except these:
As I reported to the openssh-unix-dev list, as well as in
https://bodhi.fedoraproject.org/updates/openssh-7.2p1-1.fc23,
this release silently removes the /usr/bin/slogin symlink pointing to
/usr/bin/ssh, because upstream removed the Makefile commands creating
it at install time. Same for slogin.1 -> ssh.1.
This will break lots of installations (scripts, keyboard shortcuts, etc).
For the Cygwin distro I now added the missing rules to the spec file,
along the lines of
cd ${DESTDIR}/usr/bin
ln -s ./ssh.exe slogin
cd ${DESTDIR}/usr/share/man/man1
ln -s ./ssh.1 slogin.1
Please create slogin in the rpm spec file as well.
Thanks for the notice. My bad that I thought that symlink is just
ancient stuff from old times. I will respin update with restored symlink
for Fedora 23.
Do you think that we need to carry this symlink even to Fedora 24? Do
you have some examples of scripts using slogin? They should probably
also get fixed.
Upstream also probably didn't see it as a big deal:
https://anongit.mindrot.org/openssh.git/commit/?id=69fead5d7cdaa73bdece9fcba80f8e8e70b90346
--
Jakub Jelen
Associate Software Engineer
Security Technologies
Red Hat
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
[HEADS UP]: OpenSSH 7.2 to Fedora 23
Hi there, I just pushed openssh-7.2 update [1] into Fedora 23 testing. There are no incompatible changes except these: * the minimum modulus size supported for diffie-hellman-group-exchange was increased to 2048 bits, * several legacy cryptographic algorithms and MD5-based and truncated HMAC algorithms were disabled on client side. which might be some trouble when connecting to old systems. If you need to use some of these fancy ciphers or HMACs, you need to configure your client to use them explicitly, for example: ssh -o Ciphers=+blowfish-cbc -o MACs=+hmac-md5-96 your_host or store appropriate values to the ~/.ssh/config. SSH should now also yield reasonable messages when it was not able to negotiate particular algorithms. My tests passed and the package is already for few days in rawhide and f24, but another testing would be appreciated, especially quick check if some of your common use cases are not disturbed. And there are also some fancy features you might want to give a try such ad-hoc adding keys to ssh-agent or new keyword restrict to use in authorized_keys file [2]. Thanks for attention and have a great day, [1] https://bodhi.fedoraproject.org/updates/openssh-7.2p1-1.fc23 [2] http://www.openssh.com/txt/release-7.2 -- Jakub Jelen Security Technologies Red Hat -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
