c4c-dev team mailing list archive

[KI7MT <ki7mt@xxxxxxxxx>]

Hi Eric, All,

For the user, it's a very simple task. They would simplly add the SSH
key (or new key) to their Key ring, package we'll write up could take
care of. For a pre-built system, it would already be installed as part
of the setup process.

For the server admins, they have to perform two tasks (both of which an
admin package / script could perform):

1. Generate the New Key Pair
2. Add the Key to the servers Authorized Key file on the server.

The only manual step ( I think ) would be to email the user the Keys
once they have been generated, in the acase of lost or regeneration need.

The other option would be to code this completely on the web-server, but
that would take some whizbang PHP or Python script or some other
scripting language knowledge to provide a pretty interface. There may be
Opensource code available for this already.

best regards,

Greg

On 05/19/2015 01:43 PM, Eric Bradshaw wrote:
> Addendum - I didn't want to give the impression that I don't want what was just described to work. On the contrary - it sounds great. I just want it to be and "seem" easy to the end-user. We give away computers (and God willing others will give away computers) to lots of folks without *any* real computer experience whatsoever and I don't want them to feel it's too complicated for them to start.
> 
> Eric
> 
> --
> Thank You,
> God Bless You,
> Computers4Christians
> http://Computers4Christians.org/
> 
> Israel <israel@xxxxxxxxxx> wrote:
> 
>> Hi,
>> I think this is brilliant!
>> This thoroughly covers every thing possible, adds more security, adds
>> strict compliance with the ambiguous 'for c4c use only' and makes me
>> feel generally a lot better about the whole deal.
>> Please do this!
>>
>> On 05/19/2015 02:04 AM, KI7MT wrote:
>>> Hello All,
>>>
>>> I've been thinking about this authentication thing a little bit.
>>>
>>> There appears to be two use case situations:
>>>
>>> [1] PC's that are pre-built and pre-imaged with C4C
>>> [2] ISO Installation by the user
>>>
>>>
>>> Situation [1]
>>>
>>> From a server content delivery standpoint, an easy way to administer
>>> this would be through the use of SSH Key pairs (private & public). Each
>>> system built and delivered to the receiver ( the person getting the
>>> computer ), would get a unique key pair generated off a MB serial
>>> number, chipset serial number or something that would be unique on every
>>> machine. Those key pairs will determine if they that system has access
>>> to the media or not. This is how we all access servers through SSH for
>>> web-hosting, VPS server administration, even our launchpad code work.
>>>
>>> Those keys would be installed on the system before delivery, and added
>>> to the server's authorized Key list. *That can be your control point*.
>>> If they re-install the system, loose their key or whatever, they would
>>> be required to request a new set, and thus agreeing to the EULA again
>>> before they are sent to them.
>>>
>>> This of course would restrict access to the server via SSH to Key access
>>> only, which is a good thing anyway. Debian has this implemented for all
>>> their access for us Maintainers.
>>>
>>>
>>> Situation [2]
>>>
>>> This is much the same as a user loosing their key pair and having to
>>> request a new set. The end user, if they want to use the Download
>>> facility (for media ) would have to request a Key pair. When they do,
>>> they must agree to the EULA. To get the initially, they would have to
>>> request them via email, web-interface or whatever.
>>>
>>>
>>> Conclusions
>>>
>>> While it's not perfect, it does provide a high level of containment, and
>>> it's used throughout the Internet as a stand means of access. All this
>>> can easily be shell scripted.
>>>
>>> You could take this one step further, and add passwords to the Keys as
>>> well, which I would advise. Those PW's should never be given back out.
>>> If they forget it, to bad, so sad, request a new key pair.
>>>
>>> There is only one issue with this, Zsync does not work over SSH, Rsync
>>> does, SCP does, Curl does.
>>>
>>> Zsync is more efficient, no question about that, but rsync is a *very
>>> good* file transfer protocol. It's used to backup servers all over the
>>> web, every day. That, coupled with 7Z compression, should work quite
>>> well. Not to mention, binary data (music files, video's etc) do not
>>> compress, so we're pretty much stuck with whatever the file sizes are
>>> anyway.
>>>
>>> Rsync commands are simple: rsync -avr pointA/ pointB/
>>>
>>> Over SSH one simply adds the User and IP Addy to the string. Point A and
>>> B can be any combination of IP addresses, Network Addresses, or Local
>>> Disk paths.
>>>
>>> The only thing you'd have to do really, is add the key pairs to the
>>> servers auth list when issuing new pairs. Would be a good idea to keep a
>>> log of the data and what not, but that's pretty easy.
>>>
>>>
>>> Thoughts ??
>>>
>>>
>>> best regards,
>>>
>>> Greg
>>>
>>>
>>> On 05/18/2015 03:34 PM, Israel wrote:
>>>> Hi again,
>>>> zenity is a gtk application, and AFAIK there is no real Qt equivalent..
>>>> but I have only used KDE a handful of times, and the same goes for LXQt.
>>>>
>>>> So, if we want to make an installer we would need to do a few different
>>>> things.
>>>> a) make Qt and GTK installers
>>>> b) use a different toolkit (I am very familiar with FLTK using c++)
>>>> c) look into Qt dialog programs (do they exist, how good are they?)
>>>>
>>>> A bash script is going to be the quickest and easiest way for me to
>>>> sketch out a program we can test, and use.
>>>>
>>>> @Greg do you know any programming languages?
>>>>
>>>> I don't have much experience using curl/rsync so my vote is for zsync,
>>>> as it is used for ISO downloads
>>>>
>>>> I think as a further precaution we need to look into some sort of
>>>> passkey type thing for use with the binary files, in order to further
>>>> protect things, or some other way of verifying that the zsynced files
>>>> are going solely to a c4c machine (or someone installing c4c-music or
>>>> whatever)
>>>> I don't have any real suggestions for this right now... but just the
>>>> thought that we should do this
>>>>
>>>>
>>>> On 05/18/2015 12:12 PM, KI7MT wrote:
>>>>> HI Eric,
>>>>>
>>>>> You don't need the QT Opensource Installer .. that's for QT application
>>>>> development, which we are not doing at this point; it was just an
>>>>> example of lengthy downloads and accepting the EULA.
>>>>>
>>>>> Everything we need QT wise will be provided by the base Installation
>>>>> ISO. We don't need to be concerned about those packages.
>>>>>
>>>>> best regards,
>>>>>
>>>>> Greg.
>>>>>
>>>>>
>>>>>
>>>>> On 05/18/2015 11:07 AM, Eric Bradshaw wrote:
>>>>>> Guys,
>>>>>>
>>>>>> Again, no expertise - but, my thought is we may want to use the QT Open
>>>>>> Source installer simply because Lubuntu is transitioning to LXQt
>>>>>> (supposedly) by 15.10 - so maybe we'd be prepared? Apologies if one
>>>>>> would have nothing to do with the other.
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>> On 05/18/2015 09:14 AM, KI7MT wrote:
>>>>>>> Hi Israel, All,
>>>>>>>
>>>>>>> Yes, zsync, rsync or even curl could do that job easily. A simple shell
>>>>>>> script could do what is needed here.
>>>>>>>
>>>>>>> If you have ever used MSYS/MinGW, this is exactly how their installer
>>>>>>> works for pulling packages to install form the SF server. The same for
>>>>>>> the QT Open Source installer, and it pull a is HUGE amount of data at
>>>>>>> install.
>>>>>>>
>>>>>>>
>>>>>>> best regards,
>>>>>>>
>>>>>>> Greg.
>>>>>>>
>>>>>>> On 05/18/2015 07:43 AM, Israel wrote:
>>>>>>>
>>>> ...
>>>>
>>
>>
>> -- 
>> Regards
>>
>> -Israel
>> ToriOS Team
>>
>>
>> -- 
>> Mailing list: https://launchpad.net/~c4c-dev
>> Post to     : c4c-dev@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~c4c-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
>>