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_ander...@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@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@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_ander...@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 < <mpdman...@gmail.com> >>>> mpdman...@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@lists.sugarlabs.org >>> http://lists.sugarlabs.org/listinfo/sugar-devel >>> >> >> _______________________________________________ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel >> > > > > _______________________________________________ > Sugar-devel mailing > listSugar-devel@lists.sugarlabs.orghttp://lists.sugarlabs.org/listinfo/sugar-devel > > > > _______________________________________________ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > >
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel