Score:0

How to create a new SSH service connection for a server which has MFA enabled?

in flag

I'm trying to create an azure pipeline. Part of the process involves creating a service connection so that I can copy files to the remote server securely.

enter image description here

I have 2 questions:

  1. What do I put in the Service connection name field? An example with a brief explanation would suffice.
  2. How do I create this SSH service connection if I have MFA enabled? There's no option related to this on UI.

I asked ChatGPT about this, but I don't know whether if it's correct.

If you have MFA (multi-factor authentication) enabled on your remote machine, you'll need to use a different authentication method than a traditional password or private key. One option is to use a security token, which is a time-based code that is generated by an authenticator app (such as Microsoft Authenticator) and used in conjunction with your password to authenticate.

To use a security token in your Azure Pipeline SSH task, you'll need to add an additional parameter to the task configuration. Here's an example of how you can configure an SSH task with a security token

- task: SSH@0
  inputs:
    sshEndpoint: '<your SSH service connection name>'
    runOptions: 'ssh -o StrictHostKeyChecking=no'
    command: 'ls -l'
    arguments: '-la /home'
    sshPublicKey: '<your public key>'
    sshPassphrase: '<your passphrase>'
    sshExtraOptions: '-o IdentitiesOnly=yes'
    useAgentAuth: false
    sshPassword: '<your password>'
    sshSecurityToken: '<your security token>'

In this example, the sshSecurityToken parameter is used to specify the security token that should be used for authentication. You'll also need to include your public key, passphrase (if applicable), and password (if applicable) in the configuration.

Is this correct? If it is, how do I actually implement this part of authentication involving security tokens? Any kind of help would be appreciated.

vidarlo avatar
ar flag
sshSecurityToken is confabulation.
Score:2
in flag

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.

service screenshot


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.

Apoorv Patne avatar
in flag
So setting up a separate account that doesn't require MFA is the solution to my problem? I'll ask the administrator about this.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.