<div dir="ltr"><div><div><div><div><div><div>Hi Tony,<br><br></div>Yes, it will work.<br></div>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:<br>172.18.96.1 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOasdasdSAaaaaaSomethingaaaaaaaaaa=<br>172.18.96.1 ecdsa-sha2-nistp256 
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOLRb0jt+3bbbbbbbSomethingbbbbbbbbb=<br>172.18.96.1 ecdsa-sha2-nistp256 
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOLRb0jt+3dsFARg2Somethingccccccccc=<br>172.18.96.1 ecdsa-sha2-nistp256 
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOLRb0jt+3dsFARgSomethingdddddddddd=<br>172.18.96.1 ecdsa-sha2-nistp256 
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOLRb0jt+3dsFARgSomethingeeeeeeeeee=<br>172.18.96.1 ecdsa-sha2-nistp256 
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHS52tbpYsMRj24QhsDac9viwiv9pbCyFUYGknxlpsUWvgOxVCBg+vOLRb0jt+3dsFARgSomethingfffffffffffffffff=<br><br></div>Notice the same ip address but different identities for the school server.<br><br></div>Whenever he will try to do: ssh <a href="mailto:xsce-admin@172.18.96.1">xsce-admin@172.18.96.1</a> , 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.<br></div>He will directly be prompted for the password.<br><br></div>He just has to register with the server as normally he would do by:<br><ol><li>setting the server ip 172.18.96.1 in the network control panel section</li><li>clicking "Register"/ "Register again"/ "Connect to server" whichever gets implemented. </li></ol><p>Upon registration, the known_host file will be updated automatically to have the proper server identity. It will also be secure against mitm attacks.<br></p><p>He <b>doesn't</b> <b>have to</b> rm the known_host file or ssh-keygen -R for the host. <br></p><p>How do you feel about this technique?<br></p></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 17, 2016 at 1:44 PM, Tony Anderson <span dir="ltr"><<a href="mailto:tony_anderson@usa.net" target="_blank">tony_anderson@usa.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Hi, Manash<br>
    <br>
    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 <br>
    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.<br>
    Will your technique work to register multiple servers with the same
    IP?<span class="HOEnZb"><font color="#888888"><br>
    <br>
    Tony</font></span><div><div class="h5"><br>
    <br>
    <div>On 04/17/2016 03:17 PM, Manash Raja
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr"><span style="font-family:arial,helvetica,sans-serif">Regarding SSH.
          I think I have found a good solution. (I have tested it.)
          Thanks @Tony for telling where exactly the problem occurs.<br>
          <br>
        </span>
        <pre><span style="font-family:arial,helvetica,sans-serif">Commit : <a href="https://github.com/sugarlabs/sugar/pull/679/commits/930726741744ebdf6d464b84b31210aa0897124a" target="_blank">https://github.com/sugarlabs/sugar/pull/679/commits/930726741744ebdf6d464b84b31210aa0897124a</a>
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.</span></pre>
        <pre><span style="font-family:arial,helvetica,sans-serif">It removes the use of <span><span>"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.</span></span></span></pre>
        <pre></pre>
        <br>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Sun, Apr 17, 2016 at 7:27 AM, Tony
            Anderson <span dir="ltr"><<a href="mailto:tony_anderson@usa.net" target="_blank">tony_anderson@usa.net</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"> 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). <br>
                <br>
                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:<a href="http://schoolserver1" target="_blank">http://schoolserver1</a>,
                <a href="http://schoolserver2" target="_blank">http://schoolserver2</a>, ....<br>
                <br>
                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 <br>
                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.<br>
                <br>
                Naturally, you can save the IP address if that is more
                convenient. <br>
                <br>
                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. <br>
                <br>
                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.<br>
                <br>
                On your third question, system adminstrators use ssh.
                This is not a problem because access is by password. The
                server is set up for <br>
                ssh xsce-admin@schoolserver <br>
                <br>
                Once logged in, an adminstrator can su to root. This
                requires two independent passwords to authenticate.<span><font color="#888888"><br>
                    <br>
                    Tony</font></span>
                <div>
                  <div><br>
                    <br>
                    <div>On 04/17/2016 05:24 AM, Manash Raja wrote:<br>
                    </div>
                    <blockquote type="cite">
                      <div dir="ltr">
                        <div>
                          <div>Hi,<br>
                            <br>
                          </div>
                          Here are some updates.<b><br>
                            <br>
                            ssh:</b> I found from the source code for
                          ds-backup provided by James <a rel="nofollow" href="http://dev.laptop.org/git/users/quozl/ds-backup/" target="_blank"></a><a href="http://dev.laptop.org/git/users/quozl/ds-backup/" target="_blank">http://dev.laptop.org/git/users/quozl/ds-backup/</a>
                          and while searching along the lines of Tony (<i>The
                            script stores and retrieves using sftp with
                            authentication by public/private key.</i>)
                          that communication by ds-backup is done using
                          this command:<br>
                        </div>
                        <div>/usr/bin/ssh -o "PasswordAuthentication no"
                          -o "StrictHostKeyChecking no" -i
                          ~/.sugar/default/owner.key -l serial_number
                          server_address<br>
                        </div>
                        <div><br>
                          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
                          .<br>
                          <br>
                        </div>
                        <div>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. <br>
                          <br>
                        </div>
                        <div>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.<br>
                        </div>
                        <div>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. <br>
                          <br>
                        </div>
                        <div>I have tested that we can add to
                          .ssh/config<br>
                        </div>
                        <div>Host custom_server_name<br>
                        </div>
                        <div>    HostName 10.105.57.97<br>
                              PasswordAuthentication no<br>
                              StrictHostKeyChecking no<br>
                        </div>
                        <div>    IdentityFile ~/.sugar/default/owner.key<br>
                        </div>
                        <div>    User <serial><br>
                          <br>
                        </div>
                        <div>and it works by simply calling : ssh
                          custom_server_name <br>
                        </div>
                        <div>So we can work upon it. <br>
                          A few doubts:<br>
                          <ol>
                            <li>What should be used in
                              custom_server_name?</li>
                            <li>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.</li>
                            <li>How do we expect a human user to use
                              ssh? the longer command or .ssh/config
                              based command? or simply ssh user@server
                              with constant modifications to
                              known_hosts.</li>
                          </ol>
                          <p><br>
                          </p>
                          <p><b>XSCE vs XS</b>:</p>
                          <p>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.</p>
                          <p>@Jerry</p>
                          <blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
                            <p>I'm concerned with backwards
                              compatibility, the original
                              'schoolserver'(XS)<br>
                              based on CentOS-6 doesn't offer the
                              xs-authserver service, hence why I<br>
                              mentioned it. I would not want to break a
                              deployment where the older server<br>
                              version is used.</p>
                          </blockquote>
                          <div>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. <br>
                          </div>
                          <p>A few doubts: <br>
                          </p>
                          <ol>
                            <li>Rough percentage of XS against XSCE out
                              there?</li>
                            <li>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. <br>
                            </li>
                            <li>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. <br>
                            </li>
                          </ol>
                        </div>
                        <div>@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).<br>
                          <br>
                        </div>
                        <div>Thanks.<br>
                        </div>
                        <div> <br>
                        </div>
                      </div>
                      <div class="gmail_extra"><br>
                        <div class="gmail_quote">On Sat, Apr 16, 2016 at
                          7:56 AM, Tony Anderson <span dir="ltr"><<a href="mailto:tony_anderson@usa.net" target="_blank"></a><a href="mailto:tony_anderson@usa.net" target="_blank">tony_anderson@usa.net</a>></span>
                          wrote:<br>
                          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The operative
                            code on the school server is
                            /usr/libexec/create_user. What Manash
                            describes<br>
                            is apparently using the db setup by idmgr to
                            list the registered laptops. I don't think
                            you will<br>
                            break compatibility.<br>
                            <br>
                            What I hope we can look at is implementing
                            LDAP as a central authentication for all of
                            the services which<br>
                            require a user name, password. Of the top of
                            my head - Moodle, Khan Academy Lite,
                            OwnCloud, and Elgg.<br>
                            <br>
                            My brief experience with OwnCloud is that it
                            is a shell requiring a lot of configuration.
                            I would be interested if TK has<br>
                            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.<span><font color="#888888"><br>
                                <br>
                                Tony</font></span>
                            <div>
                              <div><br>
                                <br>
                                On 04/16/2016 10:05 AM, Jerry Vonau
                                wrote:<br>
                              </div>
                            </div>
                            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                              <div>
                                <div> <br>
                                  <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On April
                                    15, 2016 at 6:56 PM Manash Raja <<a href="mailto:mpdmanash@gmail.com" target="_blank"></a><a href="mailto:mpdmanash@gmail.com" target="_blank">mpdmanash@gmail.com</a>>

                                    wrote:<br>
                                    <br>
                                    <br>
                                    @Jerry,<br>
                                    I haven't modified anything for this
                                    feature on the server side. I found<br>
                                    that it uses both idmgr and
                                    xs-authserver. But the 5000 port is
                                    used by<br>
                                    xs-authserver to display a list of
                                    registered laptops. I didn't enable
                                    it<br>
                                    myself, it was there. All I did was
                                    to setup my server according to the<br>
                                    instructions and enabled the "XO
                                    register" feature from the admin
                                    page.<br>
                                    <br>
                                  </blockquote>
                                  I'm concerned with backwards
                                  compatibility, the original
                                  'schoolserver'(XS)<br>
                                  based on CentOS-6 doesn't offer the
                                  xs-authserver service, hence why I<br>
                                  mentioned it. I would not want to
                                  break a deployment where the older
                                  server<br>
                                  version is used.<br>
                                  <br>
                                    <br>
                                  <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> @Tony,<br>
                                    Can you tell me how ownCloud is
                                    supported by XSCE? I saw it in the<br>
                                    services<br>
                                    ready to be enabled. So can we not
                                    move the storage location of<br>
                                    /library/user/<some_id> inside
                                    or account based user directories to
                                    the<br>
                                    cloud storage locations.<br>
                                    <br>
                                    Thanks<br>
                                    <br>
                                  </blockquote>
                                  The ownCloud service is not enabled
                                  out of the box, same as the<br>
                                  'xo-services'. You can enable it and
                                  play around, figure out how and where<br>
                                  the users' data is stored. Either
                                  idmgr or ownCloud could be altered to<br>
                                  suit the need. Here it would be safe
                                  to rely on xs-authserver's information<br>
                                  as there is no existing implementation
                                  of owncloud in previous releases of<br>
                                  the server software. I can help push
                                  the server-side PR's through.<br>
                                  <br>
                                  <br>
                                  Jerry<br>
                                </div>
                              </div>
                              <span>
                                _______________________________________________<br>
                                Sugar-devel mailing list<br>
                                <a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a><br>
                                <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
                              </span></blockquote>
                            <div>
                              <div> <br>
_______________________________________________<br>
                                Sugar-devel mailing list<br>
                                <a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a><br>
                                <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
                              </div>
                            </div>
                          </blockquote>
                        </div>
                        <br>
                      </div>
                      <br>
                      <fieldset></fieldset>
                      <br>
                      <pre>_______________________________________________
Sugar-devel mailing list
<a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a>
</pre>
                    </blockquote>
                    <br>
                  </div>
                </div>
              </div>
              <br>
              _______________________________________________<br>
              Sugar-devel mailing list<br>
              <a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a><br>
              <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
              <br>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
Sugar-devel mailing list
<a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a>
</pre>
    </blockquote>
    <br>
  </div></div></div>

<br>_______________________________________________<br>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
<br></blockquote></div><br></div>