[Dxspider-support] Secure node to node connection proposal

[Mikel EA2CW]

1st of all, thanks for your comments, Howard. I agree with most of them, 
but let's start:
>
>  I think to do this, you would need to setup and second network, and 
> maybe interconnect it with the current network, as like Iain said, 
> this is just way over the top for many.  I would probably participate 
> with a second node, if possible, but to force on the current nodes 
> will kill the current network and it's users to a large extent.
Well, as far as the non registered users / nodes are not allowed to 
update information, they can connect and see the secured nodes information.
I believe that this can be already implemented with the
SET/ISOLATE <node> command and the
set/var $main::reqreg = 1 variable.
No need to make more changes to allow linking between secured and 
no-secured nodes / users. If the incoming node cannot "certify" that all 
its certified users have passwords, we can allow it for reading only.
>
>  That said, you really need Dirk to weigh in on this, I believe his 
> telnet is not a standard implementation, but I just remember some past 
> comments, and this would require a redesign.   Tunneling SSH to 
> mandate everyone using it, first would be a terrible way to do it, it 
> should be part of the programs.  Second, now all hams, and all 
> software coders that write code to support hams now have to redo their 
> code to support native SSH connections.  I love SSH personally, but to 
> force it on all the various programmers and thinking it's just going 
> to fly will never work.
>
I agree with you about the complexity of ssh tunneling. Not so 
complicated for some, but a lot for others. Linux has ssh native and 
Windows has both ssh client and server as optional but installable.
The aim of using ssh in this first step is to keep the server and client 
softwares as is, with no changes. In the tests I am doing both telnet 
and ssh connections are possible, and it is the server software which 
allow the users to send information or not, based on set/isol and 
$main::reqreg
>  As I mentioned the other day, I know the N3FJP contest software uses 
> the cluster, many on my node, and it does not support passwords, so 
> again someone that has to make coding changes.  Just FYI, there is 
> also encrypted Telnet, granted I rarely see it used.
>
With this proposal, any client software will still be able to take spots 
from the net, no need for changes as long as you don't try to upload 
information anonymously -this is the goal-
>  So in closing, as also came up last week, a lot of updating has been 
> done, we now have lists of bad calls and IP's being used on the nodes, 
> it's really time to see if that cleans up stuff enough it's not such a 
> problem anymore.
Just yesterday we have had another situation more (OH5ZZ issue) despite 
these measures. The bad /call/node/ip, etc lists system is of course 
raising the security level, but if all sysops don't keep those lists 
updated (and we have already big problems to have even soft versions) 
they have only limited capabilities.
> Cheers, and 73's...
Again, thank you very much for giving us your POV!

73, Mikel