Community
Participate
Working Groups
Lately I am having troubles with connection to anonymous eclipse.org CVS server and getting "Password Required" dialog for about 100 times an hour (on syn, on history view, on opening comparison editor, etc). It goes trough after several retries, but this dialog is very annoying and distruptive. Eclipse 3.2M5, Java5 and Windows XP
For pserver, we only prompt if authentication failed. Unfortunately, pserver is pretty weak when it comes to describing the nature of an authentication failure (i.e. it doesn't at all) so we need to treat all authentication failures as a failure due to an invalid password or username.
Please consider an option to disable such behaviour (maybe even configurable in preferences). The most common case when it is happening is for "anonymous" account where is no password at all on sites like sf.net or eclipse.org. Besides, Iknow that I've typed my pasword correclty in the repository preferences and id I ever want to type password again I could go to those preferences again. I think it would be more convenient from the end user point of view.
I guess it would make sense to have a setting for anonymous connections that indicates that the authentication information never changes. However, you would still get prompted with an error dialog when the connection failed. I am also curious as to why this is only happening to you and no one else. Is there anything special about how you are connecting to dev.eclipse.org?
Not sure why it was happeing on eclipse.org. I only noticed that for a few days over weekend. It could be a problem with my internet provider that can't handle connection under heavy loads over weekends. Also, this is actually common issue with some projects on sf.net. I guess it related to popularity or overall load for given segment of their server farm. E.g. Spring framework project is a constant subject of problems with anonymous access and this is very popular project. Another thing worth to mention about error dialog. It is probably ok to show it when opening comparison editor, but for history view, quickdiff and synchronization it should fail silently showing status in a view (like for history) or in job status for synchronization job.
Michael, now I am having the same issue with ext connection (remapped to extssh) on Eclipse 3.3M4. I am pretty confident that my passwords never change and yet I have to reenter them every time background synchronization occurs. Can you please do something about it? Some kind of option to disable asking for these passwords. E.g. add an explicit marker for anonymous connection and then never request password if it is anonymous and when it is non-anonymous but there is user info available. I am not sure it is is related to bug 170722 which may cause to loose keyring data on concurrent modifications. https://bugs.eclipse.org/bugs/show_bug.cgi?id=170722
(In reply to comment #5) > when it is non-anonymous but there is user info available. According to your bug 170722, your keyring has been broken and user info is not available(and not writeable?), so it is right behavior, isn't it?
(In reply to comment #6) > (In reply to comment #5) > > when it is non-anonymous but there is user info available. > According to your bug 170722, your keyring has been broken and > user info is not available(and not writeable?), so it is right behavior, isn't > it? No. Because of bug 170722 I may loose saved credentials (error shown in that bug is just one of the consequences and probably most severe one). However I am being asked for user/password not only when credentials are lost but also seems like on connection issues (there've been some eclipse.org outages recently). So, in case if credentials are not lost (I can see them in the repository prefs dialog), user not supposed to be asked for password. Explicit flag for non-anonymous login will allow to do that.
(In reply to comment #7) > So, in case if credentials are not lost (I can see them in the repository prefs > dialog), user not supposed to be asked for password. Explicit flag for > non-anonymous login will allow to do that. Is it really not lost? In current implementation, if correct password is given from keyring, such a dialog must not appear.
(In reply to comment #8) > Is it really not lost? > In current implementation, if correct password is given from keyring, > such a dialog must not appear. I don't know what it must, I only see what it does and also see that user name and password aren't blank for that repository. What is also weird, that it first asks for user/passord and when after entering it several times I hit cancel, it shows different dialog and this time is asking for password only...
(In reply to comment #9) > I don't know what it must, I only see what it does and also see that user name > and password aren't blank for that repository. At leaset, non-blank does not mean that the correct password is stored. > What is also weird, that it first asks for user/passord and when after entering > it several times I hit cancel, it shows different dialog and this time is > asking for password only... The first dialog will be for the password authentication method, the second method will be for the keyborad-interactive auth method and they depend on the remote sshd's configurations. I agree with you that the dialog for keyboard-interactive must be improved and I have planed to do.
(In reply to comment #10) > At leaset, non-blank does not mean that the correct password is stored. Usually it goes away together with the user name. > The first dialog will be for the password authentication method, > the second method will be for the keyborad-interactive auth method and > they depend on the remote sshd's configurations. I agree with you that > the dialog for keyboard-interactive must be improved and I have planed to do. Hmm. Why do we need two dialogs? Shouldn't it use auth info from server preferences instead?
(In reply to comment #11) > (In reply to comment #10) > > At leaset, non-blank does not mean that the correct password is stored. > Usually it goes away together with the user name. Unsual thing has happed on your environemnt, so you have posted bug 170722? Anyway, it will be helpful if you can check what kind of 'location' and 'password' are given to the constructor, org.eclipse.team.internal.ccvs.ssh2.CVSSSH2ServerConnection ,which is included in org.eclipse.team.cvs.ssh plug-in and the source code of this plug-in is available at CVS repository on dev.eclipse.org > > The first dialog will be for the password authentication method, > > the second method will be for the keyborad-interactive auth method and > > they depend on the remote sshd's configurations. I agree with you that > > the dialog for keyboard-interactive must be improved and I have planed to do. > Hmm. Why do we need two dialogs? Shouldn't it use auth info from server > preferences instead? As I wrote, it depends on the sshd's configurations. The keyboard-interactive method is not just for password auth, and may be used for one-time password, RSA's SecurID, etc.
Sorry for typo... (In reply to comment #12) > Anyway, it will be helpful if you can check what kind of 'location' and > 'password' are given to the constructor, > org.eclipse.team.internal.ccvs.ssh2.CVSSSH2ServerConnection > ,which is included in org.eclipse.team.cvs.ssh plug-in and the source code I meant that, org.eclipse.team.cvs.ssh2
(In reply to comment #12) > Unsual thing has happed on your environemnt, so you have posted bug 170722? I said I am not sure if it is related. Given that password is requested multiple times, I suspected that parallel processes (if there are parallel processes) are having troubles to get or update auth info. > Anyway, it will be helpful if you can check what kind of 'location' and > 'password' are given to the constructor, > org.eclipse.team.internal.ccvs.ssh2.CVSSSH2ServerConnection > ,which is included in org.eclipse.team.cvs.ssh plug-in and the source code > of this plug-in is available at CVS repository on dev.eclipse.org I have no way to check it because this issue happens in Eclipse instance I am working in... You can try to setup scheduled synchronization with some projects at eclipse.org for every 30 minutes. I bet it won't take you longer then a week to catch this issue. It is probably different for Michael, because he is on really fast connection to eclipse.org and may not be able to reproduce these errors.
(In reply to comment #14) > You can try to setup scheduled synchronization with some projects at > eclipse.org for every 30 minutes. I bet it won't take you longer then a week to > catch this issue. It is probably different for Michael, because he is on > really fast connection to eclipse.org and may not be able to reproduce these > errors. It is interesting... Do you mean that problem 'only' occurs on the scheduled synchronization and it does not occur on interactive operation by GUI?
(In reply to comment #15) > It is interesting... > Do you mean that problem 'only' occurs on the scheduled synchronization and > it does not occur on interactive operation by GUI? Well, I usually let is synchronize in the background. So, chances to catch it by forcing synchronization are definitely less. Also note that I have more then one synchronization in Synchronize view (and not only for CVS).
There are now two issues in this report: 1) The user gets prompted for an anonymous connection. We can fix this with a checkbox that indicates that the location does not have a password. 2) The user gets prompted for a password when using extssh even though the entered password is correct. To me, the proper solution here is for the SSH2 client to properly differentiate an authentication failure from a connection attempt failure. There have been some issue with dev.eclipse.org lately so it is not clear whether this is a problem caused by the SSH2 client in Eclipse or by the dev.eclipse.org server. It would be nice if we could get information about what Eclipse is sending and what the server is responding in order to see where the fault lies. Ymnk, does Jsch have any tracing that can be enabled by end-users? For M6, we'll try and add a checkbox that indicates that a repository doesn't have a password. For the second issue, we can't really do anything without more information.
(In reply to comment #17) > For M6, we'll try and add a checkbox that indicates that a repository doesn't > have a password. For the second issue, we can't really do anything without more > information. Michael, I think you can still provide an option to not re-request auth info if it is already present. It will be better then nothing, so I can still change aout info from the repository preferences, but at least I won't have to enter auth info hundreds of times over and over again.
Sorry but that would make it too easy for the user to get in a state where too many invalid connection attempts are made and the users account gets looked out (i.e. you may be smart enough to remember to change your authentication information but I suspect that many users would simply forget about the setting and get into problems). IMHO, if it is not an SSH authentication failure then the Jsch client should not be re-prompting. The proper solution is to find out what is going on and, if a problem exist is Jsch, to fix it there.
(In reply to comment #19) I understand, though it already takes several years to figure out what is the problem there. So, maybe an option for expert users (disabled by default) is a good workaround. BTW, it would also help if these errors would of been printed to CVS console...
Created attachment 57401 [details] org.eclipse.team.cvs.ssh2 plug-in After backing up plugins\org.eclipse.team.cvs.ssh2_3.2.100.I20061208.jar replace it with attached jar file, then run 'eclipse -console' on DOS prompt. Arguments(location and password) for CVSSSH2ServerConnection will be printed out to stderr and if an exception is thrown in establishing ssh session, it will be also printed out to stderr. In current implementation, if it works as expected, * prompts for password will not be appeared if correct password is given, * password will be prompted if incorrect password is given or password is not given, * CVSAuthenitcationError will be thrown if authenticaions are faild at last, * IOException will be thrown if there are problems in connecteing to sshd. Frankly to say, I have guessed that the correct password is not given to CVSSSH2ServerConnection.
(In reply to comment #14) > You can try to setup scheduled synchronization with some projects at > eclipse.org for every 30 minutes. I bet it won't take you longer then a week to > catch this issue. It is probably different for Michael, because he is on > really fast connection to eclipse.org and may not be able to reproduce these > errors. I have tried to synchronize 6 plug-ins on dev.eclipse.org's CVS for 18 hours(evey 30 minutes as you have suggested), but I have not been able to reproduce such a problem. I'm connecting to there from Japan and the connection to dev.eclipse.org must not be so fast.
(In reply to comment #21) > After backing up > plugins\org.eclipse.team.cvs.ssh2_3.2.100.I20061208.jar > replace it with attached jar file, then run 'eclipse -console' on DOS prompt. Is it going to work on Eclipse 3.3M4?
(In reply to comment #23) > Is it going to work on Eclipse 3.3M4? Yes, it works. Sorry for poor explanations.
(In reply to comment #24) > > Is it going to work on Eclipse 3.3M4? > Yes, it works. Sorry for poor explanations. Great. I'll put it in and will report back when this happens again.
Ok. It happens again. There is no exception or error but when password was requested I see the following on the console: Thu Jan 25 12:49:19 EST 2007 location: :ext:ekuleshov@cvs.asm.forge.objectweb.org:/cvsroot/asm password: null previous entry for same repository had good password Thu Jan 25 11:49:18 EST 2007 location: :ext:ekuleshov@cvs.asm.forge.objectweb.org:/cvsroot/asm password: ********* So, right now I can only think that keyring API is not thread safe and can return broken data if write and get happens about the same time (bug 170722, which seems like being ignored). So, methods Platform.*AuthorizationInfo() or AuthorizationHandler.*AuthorizationInfo() need to be somehow synchronized.
I greatly appreciate your help. (In reply to comment #26) > Ok. It happens again. There is no exception or error but when password was > requested I see the following on the console: > Thu Jan 25 12:49:19 EST 2007 > location: :ext:ekuleshov@cvs.asm.forge.objectweb.org:/cvsroot/asm > password: null Those linese have been from the following code in org.eclipse.team.internal.ccvs.ssh2.CVSSSH2ServerConnection class, protected CVSSSH2ServerConnection(ICVSRepositoryLocation location, String password) { this.location = location; this.password = password; System.err.println(new Date()); System.err.println("location: "+location.getLocation(false)); System.err.println("password: "+password); System.err.println("----"); } That means that "null" has been given as a passwod by org.eclipse.team.cvs.core plug-in. > So, right now I can only think that keyring API is not thread safe and can > return broken data if write and get happens about the same time (bug 170722, > which seems like being ignored). > So, methods Platform.*AuthorizationInfo() or > AuthorizationHandler.*AuthorizationInfo() need to be somehow synchronized. It seems Platform#getAuthorizationInfo has been used in cvs.core. I have not checked that code yet, but this problem must be serious(data has been lost!) and it is worth checking it.
(In reply to comment #27) > It seems Platform#getAuthorizationInfo has been used in cvs.core. > I have not checked that code yet, but this problem must be serious(data has > been lost!) and it is worth checking it. I know, but nobody responded on bug 170722
I got into this issue again. CVS plugin started to ask me for the password continuously. At this point the following message appear on the console: Session.run: unsupported type 3 When I choose to cancel password request dialog, the following had been printed to the console: Thu Feb 01 19:44:11 EST 2007 com.jcraft.jsch.JSchException: Auth fail ----
(In reply to comment #29) > I got into this issue again. CVS plugin started to ask me for the password > continuously. At this point the following message appear on the console: > Session.run: unsupported type 3 It is interesting. The number "3" means "SSH_MSG_UNIMPLEMENTED". we have not encountered yet such a sshd, which will send "SSH_MSG_UNIMPLEMENTED". What kind of sshd are you connecting to? Have you ever connected that sshd succesfully, but today did you get such an error suddenly? Or, is it first time to try that sshd? > When I choose to cancel password request dialog, the following had been printed > to the console: > Thu Feb 01 19:44:11 EST 2007 > com.jcraft.jsch.JSchException: Auth fail > ---- Yes, it is expected message. You have canceled the auth process, so it has failed.
(In reply to comment #30) > It is interesting. > The number "3" means "SSH_MSG_UNIMPLEMENTED". > we have not encountered yet such a sshd, which will send > "SSH_MSG_UNIMPLEMENTED". > What kind of sshd are you connecting to? > Have you ever connected that sshd succesfully, but today did you get such an > error suddenly? Or, is it first time to try that sshd? Yes this error happens suddenly with one of the extssh repositories I am using all the time and even have scheduled synchronization. After I canceled that password dialog, I was able to synchronize successfully. That still does not explain why password is being re-requested. It should be enough to enter it one time.
(In reply to comment #31) > Yes this error happens suddenly with one of the extssh repositories I am using > all the time and even have scheduled synchronization. Has the remote sshd changed its configurations? > After I canceled that password dialog, I was able to synchronize successfully. I can not understand what you are talking about. Without typing correct password, you can synchronize by just pressing cancel button? Is it really synchronized successfully? At that error "unsupported type 3", ssh session must be down.
(In reply to comment #32) > Has the remote sshd changed its configurations? I doubt it. Server is cvs.asm.forge.objectweb.org > > After I canceled that password dialog, I was able to synchronize successfully. > I can not understand what you are talking about. > Without typing correct password, you can synchronize by just pressing cancel > button? After error "unsupported type 3" occured, I tried to enter password 5..10 times. Each time, after hitting OK in the password dialog, there was no any printing on the console and password dialog reappeared instantly. So, eventually I choose Cancel. then I hit synchronize on that repository and it wen't trough without asking me about password. > Is it really synchronized successfully? Really really
(In reply to comment #33) > After error "unsupported type 3" occured, I tried to enter password 5..10 > times. Each time, after hitting OK in the password dialog, there was no any > printing on the console and password dialog reappeared instantly. Do you remeber the message on that passowrd dialog? "Password for XXX@cvs.asm.forge.objectweb.org" or "Keyboard Interactice authentication for ..." ? > So, > eventually I choose Cancel. > then I hit synchronize on that repository and it wen't trough without asking me > about password. I'm sorry, but I can not understad the words "wen't". Now, you can synchronize without any prompt? I have remembered that you have reported similar problem about *.objectweb.org host and it was resolved by changing sshd's config.
(In reply to comment #34) > Do you remeber the message on that passowrd dialog? > "Password for XXX@cvs.asm.forge.objectweb.org" or > "Keyboard Interactice authentication for ..." ? It was "Password for XXX@cvs.asm.forge.objectweb.org" and had user name and password > > eventually I choose Cancel. > > then I hit synchronize on that repository and it wen't trough without asking > me > > about password. > I'm sorry, but I can not understad the words "wen't". It passed. > Now, you can synchronize without any prompt? Yes. > I have remembered that you have reported similar problem about > *.objectweb.org host and it was resolved by changing sshd's config. I might reported it, but don't recall anything about changing sshd config, especially because I don't have access to that.
IMHO, the essential problem is that your password in the key-ring is lost and ssh2 client needs to prompt you. But, I can not find reasons for such repeated password prompt and success by hitting cancel button, frankly to say. > I might reported it, but don't recall anything about changing sshd config, > especially because I don't have access to that. I have remembered that I had communicated with admin at objectweb.org, but I guess current problem is not related to that problem. Please ignore it.
(In reply to comment #36) > IMHO, the essential problem is that your password in the key-ring is lost > and ssh2 client needs to prompt you. I don't think password had been lost in this case. At least not according console output.
(In reply to comment #37) > I don't think password had been lost in this case. At least not according > console output. So, all I can say is that remote sshd suddenly stopped to accept the correct password and now it accpets correct one.
Eugene, are you still seeing the problem with extssh or did the fix for bug 170722 fix the problem?
I think I saw it once with 3.3M6, but not completely sure.
Closing for lack of activity. Please re-open if this is still happening.
