742670 - Provide a non-mozilla user access to make.mozilla VM

Status: RESOLVED FIXED

(Infrastructure & Operations Graveyard :: WebOps: Labs, task)

Description

[Ross Bruniges [:boozeniges]]

Heya guys,

Am wondering if we have a process for providing external contractors (without LDAP access) the ability to SSH into our virtual machines?

We've got someone working on our make.mozilla work and having him be able to get into make-dev1.vm1.labs.sjc1.mozilla.com would save a bunch of time.

If this is possible can you let me know what info you need and I'll get it to you ASAP!

Cheers, 

Ross

Comment 1

[Philippe M. Chiasson (:gozer)]

(In reply to Ross Bruniges from comment #0)
> Heya guys,
> 
> Am wondering if we have a process for providing external contractors
> (without LDAP access) the ability to SSH into our virtual machines?

As far as I know, that's not possible. I think you'd need to get that third party to go through the contributor agreement process: http://www.mozilla.org/hacking/committer/

Comment 2

[Matt Patterson]

Does the committer agreement get me SSH access? I don't need commit access to any of the protected Mozilla source repos, which is all the contributor agreement seems to cover.

Comment 3

[Philippe M. Chiasson (:gozer)]

I know, but the process is the same. And the code for that site lives in source-control somewhere.

I'd fill the contributor's agreement and file a bug asking for access to that site's repository only.

Comment 4

[Matt Patterson]

Okay cool. The source is on Github, so I really don't need access to any Mozilla-hosted repos, but if the process starts the same way, then we'll do that. I'll get that form filled out tomorrow.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

The process Gozer linked to is only relevant to Mozilla source code repositories, and doesn't seem relevant here (you want access to the VM itself). For normal SSH access to a VM, you'll have to make your own arrangements with whoever is administering that VM. Sounds like you need to sit down with whichever IT people are responsible for the infra you want and figure out what you need and how things should be set up :)

Comment 6

[Philippe M. Chiasson (:gozer)]

(In reply to Gavin Sharp (use [e-mail] for email) from comment #5)
> The process Gozer linked to is only relevant to Mozilla source code
> repositories, and doesn't seem relevant here (you want access to the VM
> itself).

Actually, what I need is for this user to have a LDAP account with a SSH key and a contributor agreement on file.

> For normal SSH access to a VM, you'll have to make your own
> arrangements with whoever is administering that VM. Sounds like you need to
> sit down with whichever IT people are responsible for the infra you want and
> figure out what you need and how things should be set up :)

That's me, and the point is that since the labs VM network is currently flat, we can't let outsiders (non-LDAP/CLA) inside, unfortunately.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

(In reply to Philippe M. Chiasson (:gozer) from comment #6)
> Actually, what I need is for this user to have a LDAP account with a SSH key
> and a contributor agreement on file.

For access to which repository?

Comment 8

[Philippe M. Chiasson (:gozer)]

(In reply to Gavin Sharp (use [e-mail] for email) from comment #7)
> (In reply to Philippe M. Chiasson (:gozer) from comment #6)
> > Actually, what I need is for this user to have a LDAP account with a SSH key
> > and a contributor agreement on file.
> 
> For access to which repository?

Since the repo itself is on github, to no internal Mozilla repository

Comment 9

[:Gavin Sharp [email: [e-mail]]]

The committer's agreement is quite specific to Code contributions to Mozilla-hosted code repositories. It wasn't designed to be used as a requirement for other forms of access (like shell access to a VM). As someone responsible for dealing with Mozilla repository access requests, I've just never seen a request made that involved getting access to other parts of MoCo infra, so I guess I'm just confused as to why you think a signed committer's agreement is necessary in this case. It's possible I'm just not aware of some new IT policy?

Comment 10

[Michelle Thorne]

I'm project managing this website and just returning from vacation. 

Is there anything we can do from our end to help resolve this? Would be great to get Matt access so he can start coding. Happy to help however I can.

Thanks!

Comment 11

[matthew zeier [:mrz]]

If he's a contractor he should already have an @mozilla.com email address and an LDAP account.

Who's the contractor?

Comment 12

[Michelle Thorne]

Matt Patterson (cc'ed on this bug) is our contractor. 

Ok, didn't realize we should first grab him an LDAP. I'll file a bug for that, and then it sounds like afterward he can easily be set up on the VMs.

Comment 13

[Matt Patterson]

So, I'm in LDAP and have MPT VPN access, but I still can't get into the server. Here's the ssh -v transcript:

Is it possible that LDAP doesn't have my pubkey? (I did submit it...)

ssh -v [e-mail]
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /Users/matt/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to XXXX.vm1.labs.sjc1.mozilla.com [10.110.4.116] port 22.
debug1: Connection established.
debug1: identity file /Users/matt/.ssh/id_rsa type 1
debug1: identity file /Users/matt/.ssh/id_rsa-cert type -1
debug1: identity file /Users/matt/.ssh/id_dsa type -1
debug1: identity file /Users/matt/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3p1 Debian-3ubuntu3lpk0
debug1: match: OpenSSH_5.3p1 Debian-3ubuntu3lpk0 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr 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 'XXXX.vm1.labs.sjc1.mozilla.com' is known and matches the RSA host key.
debug1: Found key in /Users/matt/.ssh/known_hosts:174
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/matt/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: /Users/matt/.ssh/matt-beor_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/matt/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).

Comment 14

[Philippe M. Chiasson (:gozer)]

(In reply to Matt Patterson from comment #13)
> So, I'm in LDAP and have MPT VPN access, but I still can't get into the
> server. Here's the ssh -v transcript:
> 
> Is it possible that LDAP doesn't have my pubkey? (I did submit it...)

I can see you in LDAP, but you are correct, there are no public ssh key attached.

Comment 15

[Matt Patterson]

Bingo, I got Desktop Support to add my SSH key and I'm in... This can be marked Fixed :-)

Comment 16

[Ross Bruniges [:boozeniges]]

Matt is in - and very happy he is.

Thanks all for the input,

Ross