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@172.18.96.1
<mailto:xsce-admin@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_ander...@usa.net
<mailto:tony_ander...@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_ander...@usa.net <mailto: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 <mailto: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
<mailto: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
<mailto:Sugar-devel@lists.sugarlabs.org>
http://lists.sugarlabs.org/listinfo/sugar-devel
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
<mailto:Sugar-devel@lists.sugarlabs.org>
http://lists.sugarlabs.org/listinfo/sugar-devel
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
<mailto:Sugar-devel@lists.sugarlabs.org>
http://lists.sugarlabs.org/listinfo/sugar-devel
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
<mailto:Sugar-devel@lists.sugarlabs.org>
http://lists.sugarlabs.org/listinfo/sugar-devel
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
<mailto:Sugar-devel@lists.sugarlabs.org>
http://lists.sugarlabs.org/listinfo/sugar-devel
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
<mailto: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
