SebA,
You're right, saltstack is doing the same as using ssh keys.... For all
intents and purposes an ssh connection/tunnel or an stunnel.
No need to build that into xymon. Just do it externally and call it a
day. And it still has the key distribution/management issue.
That said, if/when tunnels go down... And they do, then reporting is lost
and intervention is often required.
The itch to "build in" what can be done outside, in my experience, should
almost never be scratched.
It's too easy to make things over complicated for little to no pay off.
On 3/12/19 6:50 AM, SebA wrote:
The way Salt Minions authenticate and their keys have to be accepted on
the Salt Master works pretty well. I don't believe they expire. It's been
a while since I looked at it,
so I couldn't tell you exactly how it works, but there's some
information here:
https://docs.saltstack.com/en/getstarted/system/communication.html
Anyway, that model would probably work pretty well for Xymon, so long as
the reporting client is not ephemeral.
Kind regards,
SebA
On Sat, 9 Mar 2019 at 02:10, Bruce Ferrell <user-24fbf1912cfe@xymon.invalid
<mailto:user-24fbf1912cfe@xymon.invalid>> wrote:
I'm not sure which standard is in use here, so I'll just top post
like Richard did. Please don't shoot me.
People always go for certs... And then they expire and stuff starts
breaking or alerting right and left all at once. GACK!
For real hilarity, make them expire ten years out. By that time, no
one even remembers that certs were even installed or what they're for. As
the home loan industry said right
before the big crash, IBG, UBG (I be gone, you be gone).
From one who has had to deal with such mass silliness, take it from
me, it's NO FUN and REALLY tedious to fix.
"But I'll just use the cert for tunnel authentication" I hear you
say... If in-authentic communication (even self signed) isn't denied, do we
care if it's signed really? If
we do
care then we deny communication/ignore messages. Now we've lost
reporting links and visibility.
Some form of message authentication is probably a good idea though.
Just something that doesn't expire and can be revoked as needed. gpg/pgp
keys maybe, but then we get the
issue
of gpg/pgp key distribution/signing. Key per monitored system...
Anyone want to manage THAT?
On 3/8/19 11:28 AM, Richard L. Hamilton wrote:In the ideal, esp. when the client may have a dynamic IP address
(DHCP without reserved addresses, or mobile clients, for example), it would
IMO also be really good if the
client reports could optionally be signed, with a certificate the
server could verify, to give some confidence as to their actually coming
from the client...not that that
assures that the actual client wasn't compromised, but it's better
than nothing insofar as it at least gives good odds that misleading (or
maliciously crafted) data from
elsewhere isn't being provided.On Mar 8, 2019, at 11:09, Axel Beckert <user-bc188e45dae4@xymon.invalid
<mailto:user-bc188e45dae4@xymon.invalid>> wrote:
Hi Ralph,
On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph Mitchell wrote:
I'd still like to see encrypted connections for Xymon client
messages going
to the server.
Yeah, this definitely is a feature which would be very nice to
available out of the box.
Nevertheless you can do that already now with stunnel as I
mentioned:
(And yes, I'm still hoping and waiting for IPv6 support, too,
especially in xymonnet-based checks. Reporting to IPv6-only
servers is
no issue though, if you anyways use stunnel to encrypt the
client-reporting traffic.)
Debian's xymon package ships
/usr/share/doc/xymon/README.encryption
with hints how to implement encrypted reporting with Xymon.
The current version can be found in our packaging git repository
at
https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption
although I'm thinking about renaming it to README.encryption.md <
http://README.encryption.md>; as I
wrote it in Markdown syntax.
It also refers to this more detailed documentation:
https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Guide#Encryption_and_Tunnelling
HTH!
Kind regards, Axel