The Service connection name
according to the manual is:
Required. The name used to refer to the service connection in task properties. It's not the name of your Azure account or subscription. If you're using YAML, use the name as the azureSubscription or the equivalent subscription name value in the script.
In other words: a mandatory label name/label that will be used to identify this connection. Almost anything that makes sense to you should work. The example uses MyArmSubsciption
, but ssh2hostname
or ServiceConnection-2-Hostname-via-ssh
or whatever works for you.
Note: There are possibly restrictions with regards to which characters are allowed (for example no spaces, no wildcard characters, no emojis and/or only A-Z,a-z,0-9,-_.
etc.) but I couldn't find if those limits are documented.
The optional description should allow a more lengthy description with fewer input restrictions than the connection name.
SSH multi-factor authentication - I expect that to be simply not supported.
By philosophy and design MFA is intended to stop automated logins and I don't see anybody offering a break point for the manual input of an one-time authentication code in a pipeline.
A typical work-around is to set up a separate service account / technical account that does not require MFA and where ssh public key authentication alone is sufficient.
To address perceived security issues of that: use the relatively underused feature of openssh and the ~/.ssh/authorized_keys
file format - namely: the ability to configure options/restrictions that will be set when a particular keypair is used to log in.