[Sugar-devel] Sugar-Server enhancement

[Manash Raja]

Regarding SSH. I think I have found a good solution. (I have tested it.)
Thanks @Tony for telling where exactly the problem occurs.

Commit : https://github.com/sugarlabs/sugar/pull/679/commits/930726741744ebdf6d464b84b31210aa0897124a
Commit message :
ds-backup works independently on its own by using priave/public key pair and
ignoring known_hosts by setting 'StrictHostKeyChecking no'.
Problem might arise when other applications or user try to connect ssh to
server without using private/public key. In that case known_hosts should be
maintained to avoid conflict.

Eg scenario: Client ssh into xsce1 on server_address say schoolserver
id1 of xsce1 stored at known_hosts.
Client tries for ssh into xsce2 with same server_address (schoolserver)
id2 of xsce2 does not match with id1. Hence error.

Solution: If registration is successful, we know that we have correct
server_address of the xsce, hence we take its identification using
'ssh-keyscan -H -t ecdsa server_address' and add it to known_hosts.
So when ssh is initiated, the id of the xsce server is found along with its
server_address.

It removes the use of "ssh-keygen -R" and hence will be more secured.
It might happen that multiple identification for a
particular server_address is present in the known_hosts file as
"schoolserver" is mostly used as the server address.
But ssh will take the one that matches.




On Sun, Apr 17, 2016 at 7:27 AM, Tony Anderson <tony_anderson at usa.net>
wrote:

> In the current backup system, the only involvement of the user is to
> register. The ds-backup script uses the serial-number of the XO. The
> 'known_host' check must pass in order for this to work. Normally, this is
> not a problem because a given deployed XO only ever sees one server. It is
> usually only a problem for the person setting up multiple deployments (or
> multiple servers).
>
> Adam Holt apparently contemplates setting up multiple Raspberry Pi size
> servers with an SD card for content at a single deployment. I believe that
> this environment will not support backup and so there would be no need to
> register (except possibly for ejabberd - I haven't looked at that in
> years). Possibly HaitiOS should not execute the ds_backup script. However,
> if the script fails there is consequence.  What will be required is that
> each server on a single network have a unique name to support access by url:
> http://schoolserver1, http://schoolserver2, ....
>
> I assume 10.105.57.97 is the IP address of the server. In the server
> setup, the server is set as the network gateway and provides dns
> translation from
> server name to IP. This works with one school server per network (the
> norm). In the special case of multiple school servers, one should supply
> DHCP services and be the gateway. The other school servers would need fixed
> IP addresses. Currently, the school server is set up as 172.18.96.1 with a
> netmask of 255.255.224.0. In this scheme, other school servers could be
> given fixed addresses such as 172.18.126.1, 172.18.126.2, .... I have
> attached the relevant information from the school server:
> /etc/dchpd-xs.conf.
>
> Naturally, you can save the IP address if that is more convenient.
>
> The logic of the situation is that a user should keep its Journal backup
> on a single school server. The current ds_backup would take duplicate the
> same backup on each server. I suppose Sugar could be modified to specify
> backup to a designated school server. The proposed backup would fragment
> the Journal objects since it would assume that objects have been backed up
> and so not make copies on alternate school servers.
>
> I am sure in Adam's scenario, the SD cards will not afford complete
> backups from multiple laptops on each SD card. Most likely, there would
> have to be a dedicated server for backup with an essentially empty card.
>
> On your third question, system adminstrators use ssh. This is not a
> problem because access is by password. The server is set up for
> ssh xsce-admin at schoolserver
>
> Once logged in, an adminstrator can su to root. This requires two
> independent passwords to authenticate.
>
> Tony
>
>
> On 04/17/2016 05:24 AM, Manash Raja wrote:
>
> Hi,
>
> Here are some updates.
>
> * ssh:* I found from the source code for ds-backup provided by James
> http://dev.laptop.org/git/users/quozl/ds-backup/ and while searching
> along the lines of Tony (*The script stores and retrieves using sftp with
> authentication by public/private key.*) that communication by ds-backup
> is done using this command:
> /usr/bin/ssh -o "PasswordAuthentication no" -o "StrictHostKeyChecking no"
> -i ~/.sugar/default/owner.key -l serial_number server_address
>
> as you all know that ~/.sugar/default/owner.key is the private key for
> ~/.sugar/default/owner.key.pub public key. The public key is sent to the
> server at the time of registration. The server adds this public key to
> /library/users/serial_number/.ssh/authorized_keys .
>
> I understand that ds-backup don't care about the .ssh/known_hosts on the
> client side due to "StrictHostKeyChecking no" even though the file is
> getting populated.
>
> So the ssh command is concerned of mainly the public/private key pair,
> serial and the server address. If we know the serial of the laptop that is
> registered with a server we can connect successfully with it using the
> above command. But it might fail using a normal ssh command due to
> known_host conflict. If we assume that all the server communication (sftp
> and rsync) will occur using private/public keys, then we don't even need to
> do "ssh-keygen -R hostame" or "rm ~/.ssh/known_hosts" I guess.
> The issue might have been caused when wrong serial was used to connect to
> a server which do not have it registered. Which has now been fixed in the
> patch by retaining the serial for previous registrations.
>
> I have tested that we can add to .ssh/config
> Host custom_server_name
>     HostName 10.105.57.97
>     PasswordAuthentication no
>     StrictHostKeyChecking no
>     IdentityFile ~/.sugar/default/owner.key
>     User <serial>
>
> and it works by simply calling : ssh custom_server_name
> So we can work upon it.
> A few doubts:
>
>    1. What should be used in custom_server_name?
>    2. How do we expect our codes to sftp or rsync with server? ds-backup
>    will run properly in backup if we keep setting the proper serial. But other
>    than that no application does sftp or rsync to server, so we can define the
>    proper way now.
>    3. How do we expect a human user to use ssh? the longer command or
>    .ssh/config based command? or simply ssh user at server with constant
>    modifications to known_hosts.
>
>
> *XSCE vs XS*:
>
> The patch I built uses relies on xs-authserver which is absent in xs. I
> really want to add support for XS for this feature. And I discussed on
> #schoolserver to know if there is any other way to get idmgr database info
> on client side. XS doesn't seem to support it well enough. I have
> identified a way to solve this issues by modifying "registration-server"
> and "idmanager.py" scripts of idmgr.
>
> @Jerry
>
>> I'm concerned with backwards compatibility, the original
>> 'schoolserver'(XS)
>> based on CentOS-6 doesn't offer the xs-authserver service, hence why I
>> mentioned it. I would not want to break a deployment where the older
>> server
>> version is used.
>>
> It would not break deployment, as Tony mentioned. The maximum harm that
> can be caused is to have multiple registrations for a single laptop in XS
> due to inability of XS to provide list of registered laptops to the client.
>
> A few doubts:
>
>    1. Rough percentage of XS against XSCE out there?
>    2. Scope of modifying idmgr? I am still looking for alternatives in XS
>    that doesn't need server side modification but till then I really want to
>    know what are the steps if we finally need to modify to establish a clear
>    implementation.
>    3. Even without XS support, the patch solves the issue of taking the
>    load out of teachers, just that same backup path cannot be ensured if
>    serial keeps changing. Hence, is this a significant issue to need a server
>    modification? As if not, then we can move on and wait until the XS catches
>    up.
>
> @Tony, certainly as you said things can be reorganized starting from now
> in small steps so that future features can easily fall into place. This
> registration feature may change a component here and there (like idmgr) but
> in the progress it might provide a cleaner and better framework for server
> related features. (LDAP being one of them).
>
> Thanks.
>
>
> On Sat, Apr 16, 2016 at 7:56 AM, Tony Anderson <tony_anderson at usa.net>
> wrote:
>
>> The operative code on the school server is /usr/libexec/create_user. What
>> Manash describes
>> is apparently using the db setup by idmgr to list the registered laptops.
>> I don't think you will
>> break compatibility.
>>
>> What I hope we can look at is implementing LDAP as a central
>> authentication for all of the services which
>> require a user name, password. Of the top of my head - Moodle, Khan
>> Academy Lite, OwnCloud, and Elgg.
>>
>> My brief experience with OwnCloud is that it is a shell requiring a lot
>> of configuration. I would be interested if TK has
>> actually deployed it and, if so, how he uses it. I don't know of any one
>> else who is using it at the moment.
>>
>> Tony
>>
>>
>> On 04/16/2016 10:05 AM, Jerry Vonau wrote:
>>
>>>
>>> On April 15, 2016 at 6:56 PM Manash Raja < <mpdmanash at gmail.com>
>>>> mpdmanash at gmail.com> wrote:
>>>>
>>>>
>>>> @Jerry,
>>>> I haven't modified anything for this feature on the server side. I found
>>>> that it uses both idmgr and xs-authserver. But the 5000 port is used by
>>>> xs-authserver to display a list of registered laptops. I didn't enable
>>>> it
>>>> myself, it was there. All I did was to setup my server according to the
>>>> instructions and enabled the "XO register" feature from the admin page.
>>>>
>>>> I'm concerned with backwards compatibility, the original
>>> 'schoolserver'(XS)
>>> based on CentOS-6 doesn't offer the xs-authserver service, hence why I
>>> mentioned it. I would not want to break a deployment where the older
>>> server
>>> version is used.
>>>
>>>
>>>
>>>> @Tony,
>>>> Can you tell me how ownCloud is supported by XSCE? I saw it in the
>>>> services
>>>> ready to be enabled. So can we not move the storage location of
>>>> /library/user/<some_id> inside or account based user directories to the
>>>> cloud storage locations.
>>>>
>>>> Thanks
>>>>
>>>> The ownCloud service is not enabled out of the box, same as the
>>> 'xo-services'. You can enable it and play around, figure out how and
>>> where
>>> the users' data is stored. Either idmgr or ownCloud could be altered to
>>> suit the need. Here it would be safe to rely on xs-authserver's
>>> information
>>> as there is no existing implementation of owncloud in previous releases
>>> of
>>> the server software. I can help push the server-side PR's through.
>>>
>>>
>>> Jerry
>>> _______________________________________________
>>> Sugar-devel mailing list
>>> Sugar-devel at lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
>
>
> _______________________________________________
> Sugar-devel mailing listSugar-devel at lists.sugarlabs.orghttp://lists.sugarlabs.org/listinfo/sugar-devel
>
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160417/8616367b/attachment-0001.html>