[ https://issues.jboss.org/browse/JBIDE-8096?page=com.atlassian.jira.plugin... ] Andre Dietisheim resolved JBIDE-8096. ------------------------------------- Resolution: Done Adding the key that was selected to launch the instance to the ssh-prefs Committed to TRUNK (CR1) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8096?page=com.atlassian.jira.plugin... ] Andre Dietisheim edited comment on JBIDE-8096 at 1/13/11 12:12 PM: ------------------------------------------------------------------- the problem that remains here is the following: Deltacloud running against EC2 only offers the private key of a key-pair in the moment you create it. There's no way to get the private part of a key pair afterwards. So we can not store the private key to the local machine if the key was created in the aws console. I currently add the key to the prefs when you select it. I currently store the key when you create it. So the usecase that is not handled yet is when you create a key in aws manually. It will then show up in the list of the available key in our tool, but there's no way for the tools to store the priavet key of this key-pair automatically. I could work around this by offering a dialog with a link to download it manually with a browser. The same dialog could also offer a browse button that would allow the user to browse for the key he downloaded and store it to the location indicated by the ssh-prefs. was (Author: adietish): the problem that remains here is the following: Deltacloud running against EC2 only offers the private key of a key-pair in the moment you create it. There's no way to get the private part of a key pair afterwards. So we can not store the private key to the local machine if the key was created in the aws console. I could work around this by offering a dialog with a link to download it manually with a browser. The same dialog could also offer a browse button that would allow the user to browse for the key he downloaded and store it to the location indicated by the ssh-prefs. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8096?page=com.atlassian.jira.plugin... ] Andre Dietisheim edited comment on JBIDE-8096 at 1/13/11 2:19 PM: ------------------------------------------------------------------ ok so we decided the following: 1) we add a text-field to the "Manage keys" dialog that is initialized with the path that is set in the SSH-preferences. 2) In the "Manage keys" dialog we store keys to the given (text-field) path and add it to the private keys of the SSH-preferences 3) we ask the user if he agrees that the new key's stored and added 4) We warn the user if he launches an instance with a key that is not stored locally & added to the private keys and RSE is enabled (on the 2nd page) 1) is necessary since you can add keys to the (ssh-prefs) private keys full path. SSH-home in the prefs is just a sensitive default to store keys but you may choose any other location and add the key to the private keys. 4) is a pragmatic approach since we are close to CR1. We can implement that dialog later on. There may be usecases where the key that was used to launch the instance is not identical to the key that is used to connect to the ssh-daemon that runs on it. was (Author: adietish): ok so we decided the following: 1) we add a text-field to the "Manage keys" dialog that is initialized with the path that is set in the SSH-preferences. 2) In the "Manage keys" dialog we store keys to the given (text-field) path and add it to the private keys of the SSH-preferences 3) we ask the user if he agrees that the new key's stored and added 4) We warn the user if he launches an instance with a key that is not stored locally & added to the private key 1) is necessary since you can add keys to the (ssh-prefs) private keys full path. SSH-home in the prefs is just a sensitive default to store keys but you may choose any other location and add the key to the private keys. 4) is a pragmatic approach since we are close to CR1. We can implement that dialog later on. There may be usecases where the key that was used to launch the instance is not identical to the key that is used to connect to the ssh-daemon that runs on it. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8096?page=com.atlassian.jira.plugin... ] Andre Dietisheim resolved JBIDE-8096. ------------------------------------- Resolution: Done committed to BRANCH (CR1) and TRUNK (FINAL) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8096?page=com.atlassian.jira.plugin... ] Andre Dietisheim edited comment on JBIDE-8096 at 1/18/11 5:39 AM: ------------------------------------------------------------------ I added a verification for the key-folder to be writable committed to BRANCH (CR1) and TRUNK (FINAL) was (Author: adietish): committed to BRANCH (CR1) and TRUNK (FINAL) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8096?page=com.atlassian.jira.plugin... ] Libor Zoubek closed JBIDE-8096. ------------------------------- -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira