Salt SSH Setup

Length: 00:10:58

Lesson Summary:

Salt lets us run commands on servers that do not have the salt-minion installed. We do this over SSH which essentially allows us to work with unsalted systems through the use of the salt-ssh command.

Salt SSH is not installed alongside the salt-master, so if we want to use it, we need to install and configure it separately. Salt SSH is also not included in the bootstrap script; however, we can install it via the apt command: When we ran the script, SaltStack's repositories were added to our repolist, and now we can use them:

$ sudo apt-get install salt-ssh

Prep the Saltless Server

Despite not having to install Salt on the minion itself, we do have to do a small amount of prep-work. That is, we need to log in to our cloud server and set the password when prompted upon initial login, then we need to update our sudoers file so that Salt can run commands as sudo without issue. Since we can't log in as root, Salt will be using our user user.

$ sudo su -
$ visudo


If you can log in via SSH as root, you do not need to make these changes. Our cloud servers have this disabled. Turning off SSH root login is also generally considered a best practice.

Set Up the Salt SSH Roster

So how does Salt know what servers to SSH into? We need to use the /etc/salt/roster file, which was added after we installed Salt SSH. As with most of our configurations, the file is written in simple YAML.

To add a server to the roster, we first need to give the server an ID. Since our new minion was created specifically to work with Salt SSH, I just used a designation of ssh_minion; generally, however, this would be something more identifiable:

$ sudo $EDITOR /etc/salt/roster


After this, we need to supply some parameters. At the very least, we need to always supply the host location (be sure to use your server's own private IP):


However, there are a number of other options we want to consider, including user, passwd, port, sudo (which always runs Salt with sudo privileges when using a non-root user), sudo_user (set a specific user for escalated privileges), tty (for systems where sudo is set to True and requiretty is set), priv (to set the private key for login), timeout (for establishing the SSH connection), minion_opts, thin_dir (for Salt-related temporary file storage on the SSH minion), and cmd_umask (for instances when using salt-call).

In this case, we want to use the user option, since we can't log in via root, and the sudo option, so we can run commands that require any advanced privileges, just as we can regularly.

  host: >
  user: user
  sudo: True

At this point, you may be wondering why we're not supplying a password or private key information. This is because, by default, Salt will generate and supply its own SSH key for use on our SSH minions. However, for this to be generated, we need to attempt to run a salt-ssh command. Go ahead and save and exit the roster file, then try out a simple using salt-ssh:

$ sudo salt-ssh '*'

Of course, we received an expected error because our SSH public key is not yet on our minion. We can fix this with ssh-copy-id. By default, Salt SSH's key is located at /etc/salt/pki/master/ssh/ To use something else, use the priv argument in your roster.

$ sudo sh-copy-id -i /etc/salt/pki/master/ssh/ user@<PRIVATE IP OF SSH MINION>

With our key added, we can try testing our SSH minion again:

$ sudo salt-ssh '*'

This lesson is only available to Linux Academy members.

Sign Up To View This Lesson
Or Log In

Looking For Team Training?

Learn More