[Sugar-devel] Sugar-Server enhancement

Tony Anderson tony_anderson at usa.net
Sun Apr 17 20:46:40 EDT 2016


Sounds good. Make sure not to use the word connect - this refers to 
making a connection between the client and the server. Using it in this 
context could create confusion.

"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."

Actually, there doesn't appear to be a need to change the users 
interface at all. if the user connects to a 'new' server, this will be 
indicated by 'register'
and not 'register again' (and the network control panel would show no 
server). The user clicks register and your code adds a new entry to ssh 
and shows the FQDN in the network control panel and changes to 'register 
again'.

Tony



On 04/17/2016 05:35 PM, Manash Raja 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 
> <mailto: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 
> <mailto: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 <mailto: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 <mailto: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
>>>                     <mailto: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
>>>                 <mailto:Sugar-devel at lists.sugarlabs.org>
>>>                 http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>>
>>>             _______________________________________________
>>>             Sugar-devel mailing list
>>>             Sugar-devel at lists.sugarlabs.org
>>>             <mailto:Sugar-devel at lists.sugarlabs.org>
>>>             http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>>
>>>
>>>
>>>         _______________________________________________
>>>         Sugar-devel mailing list
>>>         Sugar-devel at lists.sugarlabs.org
>>>         <mailto:Sugar-devel at lists.sugarlabs.org>
>>>         http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>>         _______________________________________________
>>         Sugar-devel mailing list
>>         Sugar-devel at lists.sugarlabs.org
>>         <mailto:Sugar-devel at lists.sugarlabs.org>
>>         http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>>
>>
>>     _______________________________________________
>>     Sugar-devel mailing list
>>     Sugar-devel at lists.sugarlabs.org
>>     <mailto:Sugar-devel at lists.sugarlabs.org>
>>     http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
>     _______________________________________________
>     Sugar-devel mailing list
>     Sugar-devel at lists.sugarlabs.org
>     <mailto: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/20160418/f0fab239/attachment-0001.html>


More information about the Sugar-devel mailing list