[Sugar-devel] Sugar-Server enhancement

[Manash Raja]

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/67c521a7/attachment-0001.html>