Hi, Can you please create user accounts for myself (sbruno) and Peter Moore (pmoore) on the dev-master01, and add our public ssh keys to the respective authorized_keys files? Our keys have already been attached to bugs: 849013 (my pub key) and 848028 (Peter's one). Debug from failed ssh connection attempt (pmoore): http://dev-master01_login.pastebin.mozilla.org/2203534 Thanks, Simone
I'll take this as part of my work in updating userlogins puppet module in Bug 848657
Assignee: nobody → bugspam.Callek
Despite confusion in said dep-bugs puppetizing this should now be done for you guys! ssh firstname.lastname@example.org ssh email@example.com should get you in
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Hi Justin, I tried to access dev-master01 (with command "ssh -i ~/.ssh/id_rsa firstname.lastname@example.org") but I am being requested a password. Can you please double-check that my correct public key has been added to the authorized_keys file? For your convenience, my public key is available here: https://bug847948.bugzilla.mozilla.org/attachment.cgi?id=721406 Thanks a lot! Simone
(In reply to Simone Bruno [:simone] from comment #3) > Can you please double-check that my correct public key has been added to the > authorized_keys file? For some *really* odd reason my puppet patch had changed perms the wrong way here, I have since corrected them across the board, and verified that I can once again login as well, so I think you should be good now.
Hi Callek, I still experience the same behavior (password is being requested): $ ssh -i ~/.ssh/id_rsa email@example.com firstname.lastname@example.org's password:
Hi, I managed to get root access to dev-master01 after setting up my GPG key, and was able to look at the contents of: /home/sbruno/.ssh/authorized_keys /home/pmoore/.ssh/authorized_keys I could see that they are the wrong way round - and this is confirmed because I (Pete) could ssh into Simone's account using my key. He could not ssh into my account, because there was a mistake in /home/pmoore/.ssh/authorized_keys (a bogus '=' character after the key) - but when this had been fixed (removing the '=') he could also ssh into my account using his key. The authorized_keys files contain this header: # HEADER: This file was autogenerated at Wed Mar 13 13:30:47 -0700 2013 / Wed Mar 13 13:32:25 -0700 2013 # HEADER: by puppet. While it can still be managed manually, it # HEADER: is definitely not recommended. This suggests that puppet generated them, and that the correct (long-term) fix should be to switch the keys round in the puppet configs (and delete the bogus '='). However, if I clone the following repositories, I can see that the keys are not both contained inside them: https://hg.mozilla.org/build/puppet https://hg.mozilla.org/build/puppet-manifests Only my key is in the puppet repository, which suggests a clean checkout of these repository is not what was used to generate the files. Therefore I believe one of the following may be true: a) maybe the header is inaccurate - i.e. the files are not generated by puppet b) maybe the header is accurate - but there is/are one or more puppet repositories other than the two I listed above c) maybe the header is accurate - but the keys have been updated directly on the puppet master, and are not committed in source control In any case, it seems that as a separate activity, Simone's key should also be added to https://hg.mozilla.org/build/puppet. Then wherever the source is of the current keys that are the wrong way around, they just need to be switched, and the extra '=' character deleted in Simone's key (currently in my .ssh/authorized_keys file). As a temporary fix, I will append the correct keys to the existing authorized_keys files, although this may be overwritten by puppet later. Thanks, Pete
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to Pete Moore [:pete][:pmoore] from comment #6) > Hi, > > I managed to get root access to dev-master01 after setting up my GPG key, > and was able to look at the contents of: > > /home/sbruno/.ssh/authorized_keys > /home/pmoore/.ssh/authorized_keys PEBKAC > /home/pmoore/.ssh/authorized_keys (a bogus '=' character after the key) - PEBKAC again > This suggests that puppet generated them, It did (but its not *currently* managed by puppet) > However, if I clone the following repositories, I can see that > the keys are not both contained inside them: > > https://hg.mozilla.org/build/puppet This repo manages the newer class of puppetized systems (which does not include this host) > https://hg.mozilla.org/build/puppet-manifests While this is what manages this host, however on this setup of puppet the keys/users are managed in a puppet-master level secrets file, so you won't see it in repo. I backed out my recent change due to issues when deploying [I *think* puppet modded chmod's on all .ssh dir's, but its hard to tell atm] I'll manually fix your two keys (I know puppet won't revert, since I reverted my puppet change) and fix it in the local secrets.pp modification I did, so when I go to restore puppet it will work. > Only my key is in the puppet repository Per above, the repo with your key doesn't manage this, and I still have to add sbruno to the other repo (and the rest of the auth_keys manually) which I've slacked on, but will get done. > c) maybe the header is accurate - but the keys have been updated directly on > the puppet master, and are not committed in source control this :-) > In any case, it seems that as a separate activity, Simone's key should also > be added to https://hg.mozilla.org/build/puppet. Yes, sorry for delay > As a temporary fix, I will append the correct keys to the existing > authorized_keys files, although this may be overwritten by puppet later. O great, I'll mark this fixed for now, since it sounds like you'll be able to proceed. and when I fix the puppetizing on this host puppet will overwrite "properly" (with the right keys) --Thanks!
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago → 6 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.