Yes, I'd seen the parameter override for host or hostgroup.  Unfortunately 
this still leaves us with a single SSH user for a host and therefore a 
single set of sudo rules to control privilege escalation.

We're also one of those places where Puppet is allowed to run once at 
deployment time, and then has to be noop from then on.  Our sudoers file is 
a complex beast and controls all types of user elevation.  It is controlled 
by a different team and proposed changes to the sudoers must go through a 
tortuous process before being permitted.

I can understand that a user-based SSH user may lead to problems if the 
relevant SSH users aren't created on the host, but the same can be said for 
the current remote_execution_ssh_user (and also the 
remote_execution_effective_user) surely?  We already need to ensure the 
remote_execution_ssh_user exists on the client and the SSH keys are 
distributed accordingly.  It wouldn't be a great step for us to ensure more 
than 1 SSH user was configured on relevant hosts.

Our team is permitted access to 3 users on each box; read-only user, ops 
user, privileged user.  These each have slightly more privilege than the 
previous.  I can see a way of using the effective user as a middle-man for 
our escalations, but would still require the ability to restrict Roles to a 
specific sets of effective users.  Otherwise we still end up with all 
Foreman users able to select any effective user for the job.


On Thursday, 13 October 2016 07:05:31 UTC+1, Marek Hulán wrote:
> Hello, 
> you can change SSH user too by modifying the remote_execution_ssh_user 
> parameter as mentioned at [1]. The granularity is per host/host 
> group/subnet/domain/os/organization/location. Unfortunately it's 
> impossible to 
> configure it per job template (command) right now. The reason for this 
> design 
> was that specifying arbitrary user would not work until his/her SSH key is 
> installed on target. That's why we prefer changing effective user using 
> sudo on 
> target host. Maybe a puppet module that would configure sudoers based on 
> some 
> policy would be good solution. 
> We could also improve this on host side where we could have a Foreman 
> script 
> that would handle the authorization. There were some discussion on this 
> topic, 
> but there's no clear roadmap. 
> [1] 
> Hope this helps 
> -- 
> Marek 
> On Wednesday 12 of October 2016 02:09:15 Duncan Innes wrote: 
> > Is it possible to alter the SSH user on a role basis within Foreman? 
> > 
> > We have a situation where the granularity of control provided by Foreman 
> > doesn't quite fit our requirements.  We would like to be able to use a 
> > 'read-only' SSH user for executing some commands, then a more privileged 
> > user for executing commands that will change the system. 
> > 
> > e.g. 
> > 
> > read-only SSH user used to run a yum list command as this doesn't change 
> > the system 
> > ops SSH user used to run yum update commands as these are part of 
> general 
> > patching requirements 
> > admin SSH user used to run yum install/remove commands as these 
> shouldn't 
> > be required as part of normal daily running or patching cycles. 
> > 
> > When we change our Foreman-wide SSH User, we then have to craft sudo 
> rules 
> > to allow escalation of yum as that user.  But we don't have the ability 
> to 
> > then separate out the read-only, update, and install/remove functions of 
> > yum to different users. 
> > 
> > I've looked at trying to do this by changing the effective_user for the 
> > job, but this leaves us having to create sudo rules that allow the 
> > escalation of the "/remote_working_dir/foreman-ssh-cmd-{UUID}/script" 
> > command, which then covers all types of remote execution. 
> > 
> > Ideally our Foreman users would be mapped to a different SSH user, or 
> our 
> > jobs should be able to select the SSH user and not just the effective 
> sudo 
> > user at the client side. 
> > 
> > Duncan 

You received this message because you are subscribed to the Google Groups 
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To post to this group, send email to
Visit this group at
For more options, visit

Reply via email to