[Kimchi] [RFC] Issue #1063: Upon migrating guest to remote server, password less ssh is permanent
*Currently*: Upon migrating guest to remote server, password less ssh is permanent. Due to that, from terminal able to log on to the remote server with out prompting password *Propose*: Upon completion of migration, password-less ssh has to revoke. Option 1: As migration need password-less ssh, without which migration cannot be done, so it should be delete once migration is completed. Option 2: lets update user that on migration password-less ssh will be established till migration is not completed(May be as document or in UI). And ask user if he was to delete the password-less ssh login or not in migration UI panel. Option 3: Using libvirt.openauth. However I was not able to figure out any proper documentation on how to use openauth. As this is kind of security issue, we can go with Option - 1 to fix the issue for now, enhancement is always possible. :) Thanks, Archana Singh
On 11/08/2016 11:46 AM, Archana Singh wrote:
*Currently*:
Upon migrating guest to remote server, password less ssh is permanent. Due to that, from terminal able to log on to the remote server with out prompting password
*Propose*:
Upon completion of migration, password-less ssh has to revoke.
Option 1: As migration need password-less ssh, without which migration cannot be done, so it should be delete once migration is completed.
I can live with option (1) as long as: - we clearly warn the user that the password-less setup made by Kimchi will be undone after the migration; - if there is an existing password-less setup environment we do not undo it.
Option 2: lets update user that on migration password-less ssh will be established till migration is not completed(May be as document or in UI). And ask user if he was to delete the password-less ssh login or not in migration UI panel.
I think you mean that we can provide the user the option to either retain the password-less setup or not. I think this is the best option.
Option 3: Using libvirt.openauth. However I was not able to figure out any proper documentation on how to use openauth.
Same here.
As this is kind of security issue, we can go with Option - 1 to fix the issue for now, enhancement is always possible. :)
In my opinion if you implement (1) there's not much extra code to go for (2). It would be basically an extra parameter in the 'migrate' API to indicate whether the password-less setup should be undone and, if the parameter is 'true', undo it. I believe the solution should aim to (2). Daniel
Thanks, Archana Singh
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
I will send the patch as per below understanding: Provide an option for API to specify if password less setup done by kimchi has to be removed or not. By default if it is not specified then password less setup done by kimchi will be removed. However if password less setup is not done by kimchi it cannot be removed. Thanks, Archana Singh On 11/08/2016 09:25 PM, Daniel Henrique Barboza wrote:
On 11/08/2016 11:46 AM, Archana Singh wrote:
*Currently*:
Upon migrating guest to remote server, password less ssh is permanent. Due to that, from terminal able to log on to the remote server with out prompting password
*Propose*:
Upon completion of migration, password-less ssh has to revoke.
Option 1: As migration need password-less ssh, without which migration cannot be done, so it should be delete once migration is completed.
I can live with option (1) as long as:
- we clearly warn the user that the password-less setup made by Kimchi will be undone after the migration;
- if there is an existing password-less setup environment we do not undo it.
Option 2: lets update user that on migration password-less ssh will be established till migration is not completed(May be as document or in UI). And ask user if he was to delete the password-less ssh login or not in migration UI panel.
I think you mean that we can provide the user the option to either retain the password-less setup or not. I think this is the best option.
Option 3: Using libvirt.openauth. However I was not able to figure out any proper documentation on how to use openauth.
Same here.
As this is kind of security issue, we can go with Option - 1 to fix the issue for now, enhancement is always possible. :)
In my opinion if you implement (1) there's not much extra code to go for (2). It would be basically an extra parameter in the 'migrate' API to indicate whether the password-less setup should be undone and, if the parameter is 'true', undo it. I believe the solution should aim to (2).
Daniel
Thanks, Archana Singh
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On Tuesday 15 November 2016 09:52 PM, Archana Singh wrote:
I will send the patch as per below understanding:
Provide an option for API to specify if password less setup done by kimchi has to be removed or not.
By default if it is not specified then password less setup done by kimchi will be removed.
However if password less setup is not done by kimchi it cannot be removed.
Thanks, Archana Singh
+1
On 11/08/2016 09:25 PM, Daniel Henrique Barboza wrote:
On 11/08/2016 11:46 AM, Archana Singh wrote:
*Currently*:
Upon migrating guest to remote server, password less ssh is permanent. Due to that, from terminal able to log on to the remote server with out prompting password
*Propose*:
Upon completion of migration, password-less ssh has to revoke.
Option 1: As migration need password-less ssh, without which migration cannot be done, so it should be delete once migration is completed.
I can live with option (1) as long as:
- we clearly warn the user that the password-less setup made by Kimchi will be undone after the migration;
- if there is an existing password-less setup environment we do not undo it.
Option 2: lets update user that on migration password-less ssh will be established till migration is not completed(May be as document or in UI). And ask user if he was to delete the password-less ssh login or not in migration UI panel.
I think you mean that we can provide the user the option to either retain the password-less setup or not. I think this is the best option.
Option 3: Using libvirt.openauth. However I was not able to figure out any proper documentation on how to use openauth.
Same here.
As this is kind of security issue, we can go with Option - 1 to fix the issue for now, enhancement is always possible. :)
In my opinion if you implement (1) there's not much extra code to go for (2). It would be basically an extra parameter in the 'migrate' API to indicate whether the password-less setup should be undone and, if the parameter is 'true', undo it. I believe the solution should aim to (2).
Daniel
Thanks, Archana Singh
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Regards, Suresh Babu Angadi
participants (3)
-
Archana Singh -
Daniel Henrique Barboza -
Suresh Babu Angadi