Closed Bug 753086 Opened 13 years ago Closed 13 years ago

please give khuey access to the build-vpn

Categories

(Infrastructure & Operations :: Infrastructure: Other, task)

task
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: bhearsum, Assigned: jabba)

References

Details

No description provided.
Access granted to moco account.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Kyle still isn't able to ssh into the VPN jumphost (vpn1.releng.scl3.mozilla.com). The last log I got from him was: $ ssh vpn1.releng.scl3.mozilla.com -v OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007 debug1: Reading configuration data /c/Users/Kyle Huey/.ssh/config debug1: Applying options for vpn1.releng.scl3.mozilla.com debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to vpn1.releng.scl3.mozilla.com [63.245.214.124] port 22. debug1: Connection established. debug1: identity file /c/Users/Kyle Huey/.ssh/identity type -1 debug1: identity file /c/Users/Kyle Huey/.ssh/id_rsa type 1 debug1: identity file /c/Users/Kyle Huey/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3 debug1: match: OpenSSH_5.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.6 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 'vpn1.releng.scl3.mozilla.com' is known and matches the RSA host ke y. debug1: Found key in /c/Users/Kyle Huey/.ssh/known_hosts:15 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,gssapi-keyex,gssapi-with-mi c debug1: Next authentication method: publickey debug1: Offering public key: /c/Users/Kyle Huey/.ssh/id_rsa debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mi c debug1: Trying private key: /c/Users/Kyle Huey/.ssh/identity debug1: Trying private key: /c/Users/Kyle Huey/.ssh/id_dsa debug1: No more authentication methods to try. Permission denied (publickey,gssapi-keyex,gssapi-with-mic). Kyle, can you confirm that's still the error you're getting?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Logs indicate that the username khuey isn't known, even though LDAP says he's in the buildteam group. Could you guys in infra debug the server side, please?
Assignee: server-ops-releng → server-ops-infra
Component: Server Operations: RelEng → Server Operations: Infrastructure
QA Contact: arich → jdow
Yes, I'm still seeing the same problem.
It looks like someone stopped puppet on the host that was doing the automation for deploying user accounts here. I moved this automation to the new puppetmaster, since the host it was on is getting retired next week, and verified it is now working again. root@vpn1.dmz.releng.scl3:/home> id khuey uid=1586(khuey) gid=1586(khuey) groups=1586(khuey) Should be good to go and apologies for the delay.
Assignee: server-ops-infra → jdow
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Yep, it's working now. Thanks!
Status: RESOLVED → VERIFIED
Component: Server Operations: Infrastructure → Infrastructure: Other
Product: mozilla.org → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.