Thanks for your input Gary.
> The only way I would trust something like this on my network is if the
> payload is signed, by a central authority/user. The signature can be
> verified with a public key, and it should be able to verify that the
> payload was not altered since the signature was applied. [...]
SSH solves this problem. You have public keys on each target machine.
You have passphrase-protected private keys on the control machine. All
comms are encrypted, signed, and verified - on both ends. If someone
doesn't trust SSH with what it already does, well, I can't help.
Now if I have one box to manage, I'd unlock my SSH agent, ssh in, use
sudo (or doas) to escalate privileges, type in my passphrase, and do
admin stuff. This is already two authentication factors on the control
machine (well at least one, if you choose unencrypted private keys, or
plain password login); and one authentication factor on the remote
machine (unless you choose to disable it).
I want a tool that is usable, saves time, and makes life easier, without
creating a higher security risk than what is already present. Adding a
complex authn scheme on the target machine will increase the attack
surface, and will leave more room to mis-configure something. If, at the
same time, you'd leave another door open, people will just use whatever
is more usable, rendering the complex scheme redundant.
> The only way I would trust something like this on my network is [...]
If you're allowing SSH on your network, you're allowing Judo on your
network as well ;) as it's merely a shellout to SSH. All the potential
to wreak havoc is already there. If you want extra seatbelts, cool. I'd
like Judo to play nice with people's existing (sane) seatbelts. No more,
no less.
> This can be as simple as a .signature file delivered with or before
> the payload. If it can be guaranteed delivered last, then it can also
> act as a semaphore to allow the client to know the transfer is
> actually complete, and to not waste cycles trying to verify things
> before the transfer is done.
Judo already runs the entire thing in a sort-of transaction. mktemp(1)
creates a directory structure for each run. scp(1) happens next. Then,
the script is executed via ssh(1). Failure at any stage means to abort.
Cleanup is triggered in all cases (but I guess a debug mode would be
useful). As you can see, the flow is dead simple:
https://github.com/rollcat/judo/blob/d66229c/libjudo/host.go#L36
Judo is 100% client-less, and I want it to stay that way. I have a
library of portable shell functions (aka "executable unix rosetta
stone") that I put on each machine - using Judo itself, so it shouldn't
depend on it.
> The obvious requirement for participating in the existing suckless.org
> project space is knowing C well enough to keep it succinct and
> readable. Adding a new project in not-C is going to have some
> chilling effect on existing community members. [...]
I'm not looking to put any of my projects under the suckless umbrella.
Rather, I'm asking around for ideas / inspiration to solve a *design*
problem, that has nothing to do with the implementation language. This
community is well known for coming up with radically simple designs,
that work well in the real world - exactly the kind of insight I need,
to build a better tool for my job, after spending 2.5 years wrestling a
moloch full of poor ideas.
<3,K.
Received on Wed Sep 27 2017 - 09:52:29 CEST