no login for stage account "kairo" (=> no SeaMonkey nightlies on Ftp)

VERIFIED FIXED

Status

--
major
VERIFIED FIXED
12 years ago
12 years ago

People

(Reporter: kairo, Assigned: zach)

Tracking

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
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)
(Reporter)

Comment 1

12 years ago
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).
(Reporter)

Comment 2

12 years ago
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
(Assignee)

Comment 3

12 years ago
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?
(Reporter)

Comment 4

12 years ago
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 [207.126.111.216] 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).
(Reporter)

Comment 5

12 years ago
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...
(Reporter)

Comment 6

12 years ago
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.