peer_keys without suexec?

115 views
Skip to first unread message

Steffen Gebert

unread,
Oct 1, 2012, 6:26:57 PM10/1/12
to repo-discuss@googlegroups.com Discussion
Hi,

can I use the peer host key ring without doing "suexec"?

I want to execute commands without being enforced to create additional users for automatic deployment (but to set up a user, I need to be able to do SSH (except gsql..)).
So it would be great if I could execute commans as "Gerrit Code Review" user.

Or how did you solve the chicken-egg problem to get authenticated through ssh?

(I need that for plugin installation and also for flushing caches after group sync)

Thanks for your help!
Steffen

Steffen Gebert

unread,
Oct 1, 2012, 7:06:57 PM10/1/12
to repo-discuss@googlegroups.com Discussion
I just found an example of exactly what I'm trying to do:

> ssh -p 29418 -i site_path/etc/ssh_host_rsa_key 'Gerrit Code Review'@localhost gerrit flush-caches --all
http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.1.2.html#_server_administration

But this ends up with the following warning:

> [2012-10-02 01:04:50,999] WARN com.google.gerrit.sshd.CommandFactoryProvider : Cannot start command "gerrit flush-caches --list" for user Gerrit Code Review
> com.google.inject.ProvisionException: Guice provision errors:
>
> 1) Not Signed In
> at com.google.gerrit.server.util.ThreadLocalRequestContext$1.provideCurrentUser(ThreadLocalRequestContext.java:61)
> while locating com.google.gerrit.server.IdentifiedUser
> for field at com.google.gerrit.sshd.commands.FlushCaches.currentUser(FlushCaches.java:34)
> while locating com.google.gerrit.sshd.commands.FlushCaches
> while locating org.apache.sshd.server.Command annotated with CommandName[gerrit flush-caches]
>
> 1 error
> at com.google.inject.internal.InjectorImpl$4.get(InjectorImpl.java:987)
> at com.google.gerrit.sshd.DispatchCommand.start(DispatchCommand.java:80)
> at com.google.gerrit.sshd.DispatchCommand.start(DispatchCommand.java:96)
> at com.google.gerrit.sshd.CommandFactoryProvider$Trampoline.onStart(CommandFactoryProvider.java:170)
> at com.google.gerrit.sshd.CommandFactoryProvider$Trampoline.access$100(CommandFactoryProvider.java:87)
> at com.google.gerrit.sshd.CommandFactoryProvider$Trampoline$1.run(CommandFactoryProvider.java:134)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at com.google.gerrit.server.git.WorkQueue$Task.run(WorkQueue.java:337)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:636)
> Caused by: com.google.gerrit.common.errors.NotSignedInException: Not Signed In
> at com.google.gerrit.server.util.ThreadLocalRequestContext$1.provideCurrentUser(ThreadLocalRequestContext.java:64)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at com.google.inject.internal.ProviderMethod.get(ProviderMethod.java:104)
> at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40)
> at com.google.inject.internal.SingleFieldInjector.inject(SingleFieldInjector.java:53)
> at com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjectorImpl.java:110)
> at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:94)
> at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:254)
> at com.google.inject.internal.FactoryProxy.get(FactoryProxy.java:54)
> at com.google.inject.internal.InjectorImpl$4$1.call(InjectorImpl.java:978)
> at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1024)
> at com.google.inject.internal.InjectorImpl$4.get(InjectorImpl.java:974)
> ... 14 more


.. and when I try it with suexec (suexec --as f...@example.org gerrit flush-caches --list), I get
fatal: "--list" is not a valid option

Using gerrit 2.5

Thanks
Steffen
> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en

Edwin Kempin

unread,
Oct 2, 2012, 1:35:36 AM10/2/12
to Steffen Gebert, repo-discuss@googlegroups.com Discussion


2012/10/2 Steffen Gebert <ste...@steffen-gebert.de>
If you want to see the caches user the 'gerrit show-caches' command [1].

[1] https://gerrit-review.googlesource.com/Documentation/cmd-show-caches.html
 

Steffen Gebert

unread,
Jan 9, 2014, 3:57:01 PM1/9/14
to repo-d...@googlegroups.com, Steffen Gebert
Hi,

I'm revisiting that topic and I somehow hesitate to implement a peer_keys based suexec once more.

I'm asking myself, if there is any way to *not* impersonate any account but to just run commands (e.g. a gerrit create-user) as the "Gerrit Code Review" account.

For an automated deployment of Gerrit (using Chef in this case) this would help a lot, if the root user of the system running Gerrit could do such an action.

Or do you see any other way than SSH'ing into Gerrit with a key listed in peer_keys? I mean.. I can impersonate any Gerrit administrator - but there has to exist one :-)

Thanks for your help!
Steffen

P.S: While I have this problem open in my head since a week or two, somebody else in the Chef community is having the same trouble:

Peter Jönsson

unread,
Jan 9, 2014, 6:36:14 PM1/9/14
to Steffen Gebert, repo-d...@googlegroups.com
Hi!

I wrote a cookbook which on first we would inject the a user via auto-creation of a SQL script which would insert into the necessary tables to create the admin user.

We haven’t upstreamed these changes because quite frankly I was ashamed of the hackish nature of this :)

Ideally the init-step could/would/should support adding a initial user as an admin.

// peter


On Thursday 9 January 2014 at 21:57, Steffen Gebert wrote:

> Hi,
>
> I'm revisiting that topic and I somehow hesitate to implement a peer_keys based suexec once more.
>
> I'm asking myself, if there is any way to *not* impersonate any account but to just run commands (e.g. a gerrit create-user) as the "Gerrit Code Review" account.
>
> For an automated deployment of Gerrit (using Chef in this case) this would help a lot, if the root user of the system running Gerrit could do such an action.
>
> Or do you see any other way than SSH'ing into Gerrit with a key listed in peer_keys? I mean.. I can impersonate any Gerrit administrator - but there has to exist one :-)
>
> Thanks for your help!
> Steffen
>
> P.S: While I have this problem open in my head since a week or two, somebody else in the Chef community is having the same trouble:
> http://lists.opscode.com/sympa/arc/chef/2014-01/msg00120.html
>
> Am Dienstag, 2. Oktober 2012 07:35:39 UTC+2 schrieb Edwin Kempin:
> >
> >
> > 2012/10/2 Steffen Gebert <ste...@steffen-gebert.de (javascript:)>
> > > .. and when I try it with suexec (suexec --as f...@example.org (javascript:) gerrit flush-caches --list), I get
> > > fatal: "--list" is not a valid option
> >
> > If you want to see the caches user the 'gerrit show-caches' command [1].
> >
> > [1] https://gerrit-review.googlesource.com/Documentation/cmd-show-caches.html
> >
> > >
> > > Using gerrit 2.5
> > >
> > > Thanks
> > > Steffen
> > >
> > > On Oct 2, 2012, at 12:26 AM, Steffen Gebert <ste...@steffen-gebert.de (javascript:)> wrote:
> > >
> > > > Hi,
> > > >
> > > > can I use the peer host key ring without doing "suexec"?
> > > >
> > > > I want to execute commands without being enforced to create additional users for automatic deployment (but to set up a user, I need to be able to do SSH (except gsql..)).
> > > > So it would be great if I could execute commans as "Gerrit Code Review" user.
> > > >
> > > > Or how did you solve the chicken-egg problem to get authenticated through ssh?
> > > >
> > > > (I need that for plugin installation and also for flushing caches after group sync)
> > > >
> > > > Thanks for your help!
> > > > Steffen
> > > >
> > > > --
> > > > To unsubscribe, email repo-discuss...@googlegroups.com (javascript:)
> > > > More info at http://groups.google.com/group/repo-discuss?hl=en
> > >
> > >
> > > --
> > > To unsubscribe, email repo-discuss...@googlegroups.com (javascript:)
> > > More info at http://groups.google.com/group/repo-discuss?hl=en
> >
>
> --
> --
> To unsubscribe, email repo-discuss...@googlegroups.com (mailto:repo-discuss...@googlegroups.com)
> ---
> You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com (mailto:repo-discuss...@googlegroups.com).
> For more options, visit https://groups.google.com/groups/opt_out.



Stephen Nelson-Smith

unread,
Jan 10, 2014, 1:43:17 AM1/10/14
to repo-d...@googlegroups.com, Steffen Gebert
Hi Peter,

I think writing to the database is not such a bad idea.  If you could share your approach it would be very handy.

I have quite the same issue - I need to solve the question of how to seed an ssh key so that I can have a user who can run gerrit commands over the gerrit ssh interface.

I've looked looked into the peer keys option, although I'm familiar with Steffen's cookbook which uses it.  I've also not yet looked at the REST API.

My current idea is to write some code that drives the website and uploads a key - I need to do this anyway to ensure that I get to choose which user from LDAP gets to be admin.  So while I do it, I might as well upload their ssh key.  But it all feels a bit nasty.

S.
> More info at http://groups.google.com/group/repo-discuss?hl=en
>  
> ---  
> You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com (mailto:repo-discuss+unsub...@googlegroups.com).
Reply all
Reply to author
Forward
0 new messages