4

I am trying to set up Jenkins for software hosted in Google Cloud VM. I have a VM with user account A and user account B. Jenkins is hosted in user account A. All the other softwares are hosted in user account B. In order to authorize Jenkins to ssh into userB@VM_ADDRESS, I am placing user A's .ssh/id_rsa.pub into user B's .ssh/authorized_keys. This allows for Jenkins to ssh into userB@VM_ADDRESS to update my software whenever I push changes to Github. However, after awhile, for some reason the .ssh/authorized_keys in user account B is replaced/refreshed and my key is gone, and the ssh from Jenkins would fail with permission denied. How should I solve this? Or am I doing Jenkins wrong?

I saw this thread at https://groups.google.com/g/gce-discussion/c/iHqRb2KlMZg/m/x59xV4pYAQAJ?pli=1 that seems to be a similar problem but after reading through I still do not know what I need to do.

Samson
  • 1,336
  • 2
  • 13
  • 28

1 Answers1

6

The SSH keys in the metadata are redeployed regularly. To solve the issue, instead of performing manually the copy/paste in the system, copy the key and (add it to the compute engine metadata](https://cloud.google.com/compute/docs/instances/adding-removing-ssh-keys)

However, I'm not sure that is the good way to follow. Why you don't log in with the account A, because it's the "reality" and perform action on software? You can put the account A and the account B in the same Linux group, or performing a chown to change the owner of the fresh files at the end.

What's the requirements behind this tricky question?

Update 1:

The fact to use the key of the account A to log into the user B, is like an impersonation. At the end, you don't know if it's the user account A or B which have performed stuff on your file.

Anyway, in linux you have 3 level of permission UGA (User, Group, All), that's why you have something like this when you perform a ls -la: rwxr-xr-- which mean U (User) can do RWX (Read Write eXecute), group can only Read and eXecute and all can only read.

Therefore, if the user account A and user account B are in the same Group, you can set common group permissions and avoid all (others) to access to the files.

guillaume blaquiere
  • 66,369
  • 2
  • 47
  • 76
  • Jenkins is logged into account A, but it cant access account B without the ssh, and the software are in account B. – Samson Dec 04 '20 at 12:32
  • Why is it not a good way to add the key into the metadata? Also, I am afraid I don't fully understand the other alternative suggestions you have made, could you elaborate more? – Samson Dec 04 '20 at 12:33
  • Add to instance metadata the key you already have, and as comment of the key (the last field) put the username of the local user (on the machine) where the key needs to be inserted. If I understand correctly your use case, this will look like: `ssh-rsa AAAABC... userB`. basically take the id_rsa.pub of userA and change the last field to userB's username so it gets pushed to the correct authorized_keys from the instance metadata – Vi Pau Dec 08 '20 at 13:20
  • Thanks for the update! I am trying the metadata method first, as impersonation is not really an issue for me, but following the tutorial given by gcp, even after adding the ssh key in the metadata, it still says publc key permission denied :( – Samson Dec 09 '20 at 12:04
  • @Samson are you setting the comment (-C field of ssh-keygen) correctly to the username of the user you want to login into, and not from?(user B) – Vi Pau Dec 15 '20 at 14:25
  • @AlbertoPau sorry what comment are you talking about? I don't remember using a -C field – Samson Dec 16 '20 at 03:24
  • https://cloud.google.com/compute/docs/instances/adding-removing-ssh-keys#createsshkeys – Vi Pau Dec 16 '20 at 16:01
  • many thanks for the first part of your answer. I came here having nothing to do with Jenkins, still seeing the error message, and I can imagine many people learned from this first part of your answer. – Thorsten Staerk Jul 30 '23 at 08:40