[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Shipping non-OpenSSH scp(1) binary



On Tue, Jul 11, 2017 at 11:14:34PM +0800, Matt Johnston wrote:
> On Tue 11/7/2017, at 10:00 pm, Colin Watson <cjwatson@debian.org> wrote:
> > But I think dropbear-bin can only reasonably provide the ssh-client
> > virtual package if it ships /usr/bin/ssh, and that would also be needed
> > in order to avoid having to say "scp -S dbclient".  What do you want to
> > do about this?  I'm not sure how disruptive it would be to make
> > dropbear-bin non-coinstallable with openssh-client; quite possibly very
> > disruptive.
> 
> Can an alternative symlink provide /usr/bin/ssh -> dbclient if
> openssh-client isn't installed, but openssh-client as a higher
> priority? I'm pretty sure there are people using Dropbear for
> initramfs but OpenSSH for the main system, so making them conflict
> would be a problem there.

It's of course not impossible, but I'm quite reluctant to add
alternatives into the mix, because my experience suggests that I
basically always regret doing that if I don't have to - they make things
generally more brittle.

It sounded from the earlier discussion as though the main requirement
was to have scp alongside a Dropbear server in order to serve as the
endpoint for the scp protocol (such as it is).  Is there actually much
need for it on the client side?  Maybe such need as there is could be
addressed more easily with a script called something like "dbscp" that's
basically just:

  #! /bin/sh
  exec scp -S dbclient "$@"

After all, being /usr/bin/scp matters on the server side, but isn't
vital on the client side, and presumably people already cope with the
main client program being called "dbclient".

-- 
Colin Watson                                       [cjwatson@debian.org]


Reply to: