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,
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.
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. 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. Thank you. R,-Joe Wulf
On Monday, November 2, 2020, 10:54:59 AM EST, Jakub Jelen jjelen@redhat.com 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.
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,
Joe makes a good point re: hardening. We ( a very large IT company, top 10 in size) are mandated to have sftp turned off except on specific servers. As such, we use scp extensively. It would be better off for everybody involved to "fix" scp's shortcomings as opposed to expecting the world at large to drop scp, turn on sftp, and use sftp (not to mention that command line sftp pretty much stinks re: passing the commands needed to move files.
---
Regards,
Kevin Martin
On Mon, Nov 2, 2020 at 10:14 AM Joe Wulf via users < users@lists.fedoraproject.org> 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.
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.
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.
Thank you.
R, -Joe Wulf
On Monday, November 2, 2020, 10:54:59 AM EST, Jakub Jelen < jjelen@redhat.com> 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.
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-leave@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 _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
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 jjelen@redhat.com 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.
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 mailto:users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org mailto:users-leave@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
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
-
Jakub Jelen -
Joe Wulf -
kevin martin