Community
Participate
Working Groups
In Kepler if you create a new connection and specify a login password to a system with id_rsa keyring authentication when trying to connect it will first ask for the id_rsa password and when that dialog is canceled the system password will be used. If a new connection is created and the password is not provided after the id_rsa prompt is canceled it will prompt for the system password which will then be used. This is reasonable and expected behavior. When connecting to the same system with the same parameters using Luna, whether or not the system password has been entered in the connection configuration, after the id_rsa password prompt is canceled I get an Connection Error box with the text: Could not open connection Reason: There is no additional prompt for the regular system password and I am unable to log in.
Please provide steps to reproduce this problem.
This may have been resolved with recent changes in Luna.
I am still seeing this with Luna RC 3. To replicate the problem set up ssh-agent to allow automatic login to the remote system with a public/private key pair so you can log in from the command line without being prompted for a password. Launch eclipse from the command line to ensure it gets the same environment. Create a new synchronized project with your host and username and select password based authentication. Do not enter a password into the field. When you browse for the the remote directory you will be prompted for the ssh key password. If you hit cancel on this password prompt you will see the error instead of a prompt for the machine password.
Strange. I've been able browse remote hosts configured with an ssh public key for ages (we're talking years) with no problems. There must be something unusual with your setup.
I have the same problem. Changing the component to Remote because I see it in the JSch Provider and I assume that Wyatt also used the JSch provider for Luna. The problem seems to be that JSch is using $HOME/.ssh/id_rsa if available. Thus it doesn't matter if the user selects password and doesn't specify a private key, as long as that default private key is accessible. I suggest we set setConfig("PreferredAuthentications","password,keyboard-interactive") if password is selected, so that Jsch doesn't first try pubkey in that case. I uploaded this suggestion as https://git.eclipse.org/r/#/c/34081/.
This patch completely changes the current behavior. With a private/public key set up on a remote machine a user can ssh without typing a password. The current behavior is similar to this, since I just need to enter the host name and user name in the dialog. With this patch, I'm now forced to either always enter the password for the remote machine, or select "Public key based authentication", browse for the private key file and then enter the passphrase.
I agree that this is nice. But I also think the UI should match what the code does. Thus if Password is selected then password should be used. How about we make pubkey the default option in the UI and auto-fill the pubkey if it is in the default location. That way we keep the current behavior and the UI matches. Should we make pubkey only the default option if a pubkey is found or always? Does that solution sound good?
(In reply to Roland Schulz from comment #7) > I agree that this is nice. But I also think the UI should match what the > code does. Thus if Password is selected then password should be used. How > about we make pubkey the default option in the UI and auto-fill the pubkey > if it is in the default location. That way we keep the current behavior and > the UI matches. Should we make pubkey only the default option if a pubkey is > found or always? Does that solution sound good? I'm ok with this if you can come up with a solution that works. However, what if I have two public keys (I have an rsa and a dsa key)? Which are you going to choose? You are going to need to use the same one as ssh, otherwise the behavior will be different.
jsch allows one to add multiple ones. org.eclipse.jsch.internal.core.JSchCorePlugin.loadPrivateKeys (which is called indirectly by JSchConnection.newSession) automatically add those configured under "Network Configurations->SSH2" (default id_dsa,id_rsa). I suggest we add the one the user provides in the dialog and make it non-mandatory to specify a file. Thus if the user doesn't specify any then only the ones from "Network Configurations->SSH2" are used, and if the user specify one then this is also used. I think this is better than auto-filling the pubkey because it works better with multiple identities and works nicely with the "Network Configurations" configuration. Should we make public-key always the default and place it first in the dialog?
This is still a problem since the user will have to manually load the keys into the SSH2 configuration. So, a user who is used to using the command line where they don't have to enter a password, will have to do these extra configuration steps just to get Eclipse working the same way. Currently they don't have to do anything extra, which is the way I'd like to keep it.
I haven't changed the configuration of Network->Configuration->SSH2->General since I installed it. And it says "id_dsa,id_rsa" and $HOME/.ssh (thus that's the default). And if do either change the setting or move my private key file to a different directory, than the automatic usage of ssh-public key doesn't work. And if I move it and change the setting than it does work. Thus shows clearly that already now this setting is used to pick up the default ssh-key. Thus nothing would change for the user which relies on the current automatic behavior. The SSH2 network configuration would only have to be changed if the user didn't have it in the default location and that is already the case. And notice I'm not talking about the "Key Management" tab but about the "Private keys" input on the "General" tab.
I updated the solution in Gerrit. For me it works correctly if I don't specify anything other than connection-name, hostname, and username (as before). Let me know if it works for you too and whether the change as it is now is OK.
Yes it works for me now too. However, I think now you need to add a checkbox (checked by default) to use the default private keys with a hyperlink to the Network Connections preference (if possible) The checkbox should disable/enable the private key file and passphrase boxes. I would also move Public key above Password now since it is the default. E.g. something like: X Public key based authentication X Use default private key _Network Connections_ File with private key:__________________________ Browse... Passphrase:_______________________________________________ O Password based authentication Password:_________________________________________________
What would be a use case for the checkbox? As is it is now both the private key in the network configuration and in the dialog are used (as long as they are not empty). I can't think of any case where it would be important to the user to be able to select that only one or the other key should be used. And thus think a checkbox would just add clutter. If you think it needs to be clearer that the private key field is allowed to be empty, I suggest to add a text such as "The private keys configured in 'Network Configruations' are also used". We could change the label from "File with private key" to "Extra private key" (or Additional ..., or Special ...). It is possible to add hyperlinks to specific preference pages. But they don't work inside modal dialogs.
(In reply to Roland Schulz from comment #14) > What would be a use case for the checkbox? As is it is now both the private > key in the network configuration and in the dialog are used (as long as they > are not empty). I can't think of any case where it would be important to the > user to be able to select that only one or the other key should be used. And > thus think a checkbox would just add clutter. > > If you think it needs to be clearer that the private key field is allowed to > be empty, I suggest to add a text such as "The private keys configured in > 'Network Configruations' are also used". We could change the label from > "File with private key" to "Extra private key" (or Additional ..., or > Special ...). > > It is possible to add hyperlinks to specific preference pages. But they > don't work inside modal dialogs. Rethinking this a bit, I wonder if we should remove the public key section altogether, since it is already provided in the preferences? The password based authentication section would just override the public key if it was selected (it could just be a checkbox instead of a radio button). If we did this, I would still like to have a link to the preference page, so we'd need to make the dialog non-modal, but I don't think this would be a problem. Thoughts?
I think it is reasonable to remove the public key field. In theory the user might have a connection where he wants to use a different key. But there is probably no disadvantage of just adding that different key also to the network settings (would work because all keys are tried in turn). But I'm not sure we want to remove the Passphrase input. As far as I know there is currently no way to remember the Passphrase. There is an open bug for it (179924) and an implementation by the jsch author (https://github.com/ymnk/eclipse-jsch-agent-proxy) but it isn't available as an official eclipse plugin. Thus I suggest to keep the Passphrase input at least until the platform bug is resolved.
(In reply to Roland Schulz from comment #16) > I think it is reasonable to remove the public key field. In theory the user > might have a connection where he wants to use a different key. But there is > probably no disadvantage of just adding that different key also to the > network settings (would work because all keys are tried in turn). But I'm > not sure we want to remove the Passphrase input. As far as I know there is > currently no way to remember the Passphrase. There is an open bug for it > (179924) and an implementation by the jsch author > (https://github.com/ymnk/eclipse-jsch-agent-proxy) but it isn't available as > an official eclipse plugin. Thus I suggest to keep the Passphrase input at > least until the platform bug is resolved. Ok, to summarize, (a) remove the "File with private key" field, (b) add a link to the network connections preference page and make the dialog non-modal, (c) swap the order of the public key/password areas, (d) make public key the default. Something like: X Public key based authentication _Network Connections_ Passphrase:_______________________________________________ O Password based authentication Password:_________________________________________________
I uploaded a new patch with your suggestion. I was wrong and it works even when the dialog is modal. I just did it wrong for the proxy link (uploaded a fix for that separately). I also removed the get/setKeyFile from the JSchConnection now that the input is removed.
Greg mentioned offline to me that when using the link, in a dialog opened from the preference page, then the connection isn't safed an exception is thrown. I can reproduce that. This is the same problem as I discovered for https://git.eclipse.org/r/#/c/36167/ but is present even for a modal dialog. The problem seems to be that the PreferenceDialog.open causes the IRemoteUIConnectionWizard.open to only return after the PreferenceDialog is closed. I can't see a way to change that. I have three suggestions to circumvent the problem. 1) When the user clicks the user open a message dialog whether the user wants to switch over and lose any changes (or also give an option to save in the message dialog). Then close the dialog using "((JSchConnectionWizard) getWizard()).dialog.close();" before opening the PreferenceDialog. This would only happen if the dialog was opened from the PreferenceDialog (i.e. not from the new project dialog). 2) disable the link if opened from the PreferenceDialog 3) remove the link if opened from the PreferenceDialog and instead add it to the Connections preference page under the list of connections
I think adding the link to the bottom of the connections preference page (3) is the neatest.
Is this fixed now? I can't remember.
Marking this as fixed.
