Deprecation of scp protocol and improving sftp client

[Blumenthal, Uri - 0553 - MITLL]

Thank you - I wasn’t aware. Will check sshdo out. 

Regards,
Uri

> On Aug 3, 2020, at 19:21, raf <ssh at raf.org> wrote:
> 
> On Mon, Aug 03, 2020 at 05:06:35PM +0000, "Blumenthal, Uri - 0553 - MITLL" <uri at ll.mit.edu> wrote:
> 
>> I hear you - but it seems that the choice is between (a) limiting
>> "scp" functionality to address the security vulnerability, and (b)
>> killing "scp" altogether.
>> 
>> I'd much prefer (a), even if it means I lose "scp remotehost:foo\* .". 
>> 
>> Especially, since (almost always) I have equal privileges on both
>> local and remote hosts, so in that case I just originate that "scp"
>> from that remote. ;-)
>> 
>> TNX
> 
> If you have equal privileges on both hosts, this isn't
> a vulnerability. It's only a vulnerability in cases
> where you have scp access to the remote host but you
> are not supposed to have general ssh access (i.e. shell
> access).
> 
> In such cases, this vulnerability can be mitigated by
> the use of an ssh-specific command whitelisting control
> such as:
> 
>  github.com/raforg/sshdo (auto learn/unlearn policy, exact cmds, no regex)
>  github.com/daethnir/authprogs (manual policy, supports regex)
> 
> Disclaimer: I made sshdo so I'm biased. But if you
> really think you need regex support and don't mind the
> extra effort and the risk, authprogs will solve the
> problem too. But I'd recommend reading the sshdo FAQ
> before choosing.
> 
> cheers,
> raf
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5874 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20200803/10f83dab/attachment.p7s>