[Sugar-devel] Sugar-Server enhancement

[Manash Raja]

Let me write the known_hosts file's content again with new line gaps as it
might become difficult to read in word warp. :

172.18.96.1 ecdsa-sha2-nistp256
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOasdasdSAaaaaaSomethingaaaaaaaaaa=

172.18.96.1 ecdsa-sha2-nistp256
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOLRb0jt+3bbbbbbbSomethingbbbbbbbbb=

172.18.96.1 ecdsa-sha2-nistp256
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOLRb0jt+3dsFARg2Somethingccccccccc=

172.18.96.1 ecdsa-sha2-nistp256
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOLRb0jt+3dsFARgSomethingdddddddddd=

172.18.96.1 ecdsa-sha2-nistp256
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOLRb0jt+3dsFARgSomethingeeeeeeeeee=

172.18.96.1 ecdsa-sha2-nistp256
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOLRb0jt+3dsFARgSomethingfffffffffffffffff=
On Apr 17, 2016 3:05 PM, "Manash Raja" <mpdmanash at gmail.com> wrote:

> Hi Tony,
>
> Yes, it will work.
> When the admin will register to the above said schoolservers. He/she will
> have something like the following in his/her ~/.ssh/known_hosts file:
> 172.18.96.1 ecdsa-sha2-nistp256
> AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOasdasdSAaaaaaSomethingaaaaaaaaaa=
> 172.18.96.1 ecdsa-sha2-nistp256
> AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOLRb0jt+3bbbbbbbSomethingbbbbbbbbb=
> 172.18.96.1 ecdsa-sha2-nistp256
> AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOLRb0jt+3dsFARg2Somethingccccccccc=
> 172.18.96.1 ecdsa-sha2-nistp256
> AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOLRb0jt+3dsFARgSomethingdddddddddd=
> 172.18.96.1 ecdsa-sha2-nistp256
> AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOLRb0jt+3dsFARgSomethingeeeeeeeeee=
> 172.18.96.1 ecdsa-sha2-nistp256
> AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOLRb0jt+3dsFARgSomethingfffffffffffffffff=
>
> Notice the same ip address but different identities for the school server.
>
> Whenever he will try to do: ssh xsce-admin at 172.18.96.1 , while connected
> to any of the above school server, he will not face the host identity
> mismatch error as one among the 6 contains the identity for the server.
> He will directly be prompted for the password.
>
> He just has to register with the server as normally he would do by:
>
>    1. setting the server ip 172.18.96.1 in the network control panel
>    section
>    2. clicking "Register"/ "Register again"/ "Connect to server"
>    whichever gets implemented.
>
> Upon registration, the known_host file will be updated automatically to
> have the proper server identity. It will also be secure against mitm
> attacks.
>
> He *doesn't* *have to* rm the known_host file or ssh-keygen -R for the
> host.
>
> How do you feel about this technique?
>
> On Sun, Apr 17, 2016 at 1:44 PM, Tony Anderson <tony_anderson at usa.net>
> wrote:
>
>> Hi, Manash
>>
>> After sending the previous e-mail, I got thinking the following
>> situation. An admin goes to a deployment which reports a problem. Each of
>> the deployments
>> for that admin has the schoolserver address 172.18.96.1. This is the case
>> for the three schools in Rwanda and also for the three schools in the
>> Philippines.
>> Will your technique work to register multiple servers with the same IP?
>>
>> Tony
>>
>>
>> On 04/17/2016 03:17 PM, Manash Raja wrote:
>>
>> 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/>
>>> 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>
>>> 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
>>>
>>>
>>
>>
>> _______________________________________________
>> 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/2c490dce/attachment-0001.html>