Support for ssh_options and variable ssh_online timeout/retries

[srak289]

This features allows a user to specify alternate login users for machines that Carthage should configure. It also allows users to specify longer ssh_online_timeout and additional retries in environments where virtual infrastructure could be slow to start.

class MachineWithNoRoot(MachineModel):
    ssh_options = ('-lmy-user', '-oUserKnownHostsFile=/dev/null', '-oGSSAPIAuthentication=yes', )
    ssh_online_timeout = 30
    ssh_online_retries = 100

[hartmans]

• Is it right that each and every ssh_options override needs to specify stricthostkeychecking=no?
• How does a non-root user interact with filesystem_access and rsync? It seems like a lot of things like SystemdNetworkMixin are going to fail if a user is non-root. In a previous version of this I saw, sudo was explicitly inserted. I don't know that I liked that, but I think this may go too far in the other direction.

I think we need to figure out what we're trying to support and why. This is probably the right patch for something like a Cisco that wants you to log in as admin rather than root. But it's probably the wrong patch for something that wants you to log in as root and then run sudo. I'm relatively happy saying we want to support the first but not (at this time) the second.

[srak289]

I wonder if it should be possible to configure some options for ssh from config.yml?

I did not look into the other use cases, strictly the limitation of ssh being enabled for root. It is unfortunate that in some environments the configuration is set up to disallow root access directly over ssh. I agree, I have found it non-trivial to use sudo over rsync in the past. Perhaps in these instances, should a user decide to override the default root user configuration it should be up to them to also understand that they might want to rsync the files as their access user and then sudo cp /remote/src /remote/dest on the target machine.

This is simply what I thought would be a less hack workaround for the challenges that I was currently facing. By allowing the user to override the default configuration rather than edit the source .. but hopefully understanding what it is that they were doing.

[hartmans]

"srak289" == srak289 @.***> writes:

srak289> I wonder if it should be possible to configure some options
srak289> for ssh from config.yml?

Sounds like a great option.

I strongly dislike this option because it creates a developer burden on anyone developing ansible roles or Customizations for Carthage for what I think is probably a design anti-pattern (disabling administrative access for automated provisioning.) I'd rather spend the time to figure out why organizations come up with site security policies like this and come up with ways of meeting the legitimate security interests without complicating every customization people are going to write.

Examples include:

• Having a secondary root account only for automated management
• Using something like per-user administrative Kerberos accounts to gain admin privileges

[hartmans]

Hmm, my last comment wasn't clear. I think the option that is bad is expecting people to call rsync and then call cp.