Since yesterday, my account "kairo" on stage,mozilla.org doesn't let me log in any more, what I get is Permission denied (publickey). As my SeaMonkey tinderboxen are using this account as well, this means that we don't get branch builds of SeaMonkey uploaded any more, and I can't provide candidate builds for our 1.0.3 builds. Was my account deactivated deliberately and if so, why and what can I do to get it reactivated? If it happened accidentally, I'd be happy to get this corrected as well, of course ;-)
Severity: normal → major
Summary: no login for stage account "kairo" → no login for stage account "kairo" (=> no SeaMonkey nightlies on Ftp)
This seems to extend to my cvs-www account as well, maybe even cvs:/mozilla and cvs:/l10n, but I haven't tested those (yet).
Oh, wait, my bad. Forget comment #1, I was trying cvs-www from a wrong account, my key (same as for stage btw) works, as well as for normal cvs. So the problematic account really is my stage account
Kairo: As far as I can tell, no one intentionally disabled your account. The last modified date on your authorized_keys file is July 24 2004 and the disabled flag is not set on your account. Are you sure you're using the right key? Can you run ssh in verbose mode and paste any relevant output?
I'm sure it's the correct key I'm using because it works correctly for cvs accesses (I tried all of them, i.e. cvs-www, cvs:/mozilla, cvs:/l10n) and it fails in the same way for my tinderboxen, all of which are using the same key. Here's verbose (-v) output, I can send you even more verbose output (e.g. -vvv) if wanted: robert@robert:~> ssh -v stage OpenSSH_4.2p1, OpenSSL 0.9.8a 11 Oct 2005 debug1: Reading configuration data /home/robert/.ssh/config debug1: Applying options for stage debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to stage.mozilla.org [220.127.116.11] port 22. debug1: Connection established. debug1: identity file /home/robert/.ssh/id_rsa type -1 debug1: identity file /home/robert/.ssh/id_dsa type 2 debug1: Remote protocol version 2.0, remote software version OpenSSH_3.9p1 debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.2 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'stage.mozilla.org' is known and matches the RSA host key. debug1: Found key in /home/robert/.ssh/known_hosts:53 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/robert/.ssh/id_rsa debug1: Offering public key: /home/robert/.ssh/id_dsa debug1: Authentications that can continue: publickey debug1: No more authentication methods to try. Permission denied (publickey).
Created attachment 228698 [details] DSA key for my account Here's the public key for my account once again, maybe you can try putting it in place again...
Thanks, zach! He found out that premissions on my home dir were open wide, and that prohibited ssh from logging in successfully. This probably has been caused by a wrong setting on my tinderboxes, so it's basically my fault...
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
V.Fixed: SeaMonkey 1.8(.x) branch nightlies are showing up again :-)
Status: RESOLVED → VERIFIED
Attachment #228698 - Attachment mime type: application/octet-stream → text/plain
You need to log in before you can comment on or make changes to this bug.