[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