This is almost certainly related to the fix for https://issues.gradle.org/browse/GRADLE-3133. Can you provide the debug logs for this failure? Possibly authentication is working in Gradle 2.0 using a mechanism other than password? (In Gradle 2.1 we enforce to use password auth only).
Hey Manfred, Is there any chance you can get the sftp server logs for these connection attempts? As Daz mentioned in earlier versions gradle supported other authentications, which were tried before using the password provided by the build script. So it’s possible the username/password combination in your build script never worked and the underlaying ssh library gradle is using (jsch) already succeded with public key authentication.
Also we limited the “MaxAuthTries” to 1 (default was 6 before) and you might be seeing a sideeffect of this.
We’re happy to support you in figuring out what’s going on here. If it would help you, I can come up with a custom gradle version that adds more configuration options and detailed logging to the sftp support so we can nail down the root cause of that issue.
Indeed I see a lot of those in the log on the sshd side:
2014-10-08T09:23:41.754054+02:00 devaid sshd[10618]: error: Received disconnect from 192.168.50.100: 3: com.jcraft.jsch.JSchException: Auth fail [preauth]
Logging in via a normal sftp client (Transmit on OS X) works OK, so it must be something on the client side which doesn’t seem to work properly. The sshd is not setup for public key authentication, so that cannot be the case.
I’ve uploaded a modified gradle version from current master that can help us to diagnose the root cause of this issue. The modified gradle version is available at http://j.mp/1BTyhRG
with this customized version you can set the ssh properties “PreferredAuthentications” and “MaxAuthTries” via system property from the commandline.
to check whether it’s the change of the PreferredAuthentications to use “password” only or if it’s the change of MaxAuthTries=1 that is causing your problems.