[Dxspider-support] Secure node to node connection proposal

[Matthew Chambers]

How do you do SSH over packet radio as that's still a real use case for 
the packet cluster?

I think this proposal is throwing the baby out with the bath water and 
will kill all but a handful of nodes as there won't be hardly any 
logging programmers willing to rewrite their software to support SSH so 
a lot of users will just go somewhere else. Telnet is somewhat easy as 
it's just a TCP connection, but to have to involve keeping up with 
OpenSSL or similar and not all programming environments natively support 
SSH either.

Matthew NR0Q

On 2/26/23 04:23, Mikel EA2CW via Dxspider-support wrote:
> 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
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
-- 
----
Matthew Chambers, CBRE
Amateur Operator NR0Q
Tulsa, OK - Tulsa ARC

GridTracker Development Team Lead

SBE Certified Broadcast Radio Engineer

-- 
The content of this email is confidential and intended for the 
recipient 
specified in message only. It is strictly forbidden to share 
any part of 
this message with any third party, without a written consent
 of the 
sender. If you received this message by mistake, please reply to
 this 
message and follow with its deletion, so that we can ensure such a
 mistake 
does not occur in the future.

Please do not print this email unless it is 
necessary. Every unprinted email helps the environment.