# OS-specific requirements
> Configure a target server so Cloud Management Platform (CMP) can run scripts on it over SSH or WinRM
---
Site [llms.txt](/llms.txt)
---
These requirements apply to the generic execution method. A server that runs scripts through its platform's own mechanism, such as a VMware server using VMware Tools, does not need them. See [Configure remote script method](/docs/cmp/use/orchestration/remote-scripts/configure-method/).
## \*nix servers using SSH
Cloud Management Platform (CMP) copies the script to the server and runs it over SSH. For that to work:
- The server's IP address must be routable from the CMP appliance. In public cloud environments, this often means using a public IP address.
- CMP must know the server's IP address, usually because CMP provisioned it or the resource handler reports it.
- TCP port 22 must be open. Test this by opening an SSH session from the CMP appliance to the server.
- `sshd` must be installed and running on the server, with password authentication enabled in its configuration if you authenticate by password.
- The package providing the `scp` client must be installed on the server: `openssh-clients` on CentOS and RHEL, `openssh-client` on Debian and Ubuntu, or the equivalent.
If scripts fail due to a permissions error, point CMP to a directory the connecting user owns, such as a path under that user's home directory, instead of the default temporary directory. Change it in **Admin** > **Miscellaneous Settings** > **Resource management** tab > **\*nix Temporary Directory for Remote Scripts**, and verify that the ownership and permissions on that directory are correct.
## Windows servers using WinRM
On most platforms, running scripts on Windows servers uses [WinRM](https://learn.microsoft.com/en-us/windows/win32/winrm/portal). VMware Windows servers can also be set to use WinRM instead of VMware Tools.
### Prerequisites
- The server's IP address must be routable from the CMP appliance. In public cloud environments, this often means using a public IP address.
- CMP must know the server's IP address, usually because CMP provisioned it or the resource handler reports it.
- Firewalls and permissions inside the guest must allow WinRM connections.
### Configure the Windows guest
1. In the guest, run `gpedit.msc` to open the Local Group Policy editor.
1. Go to **Local Computer Policy** > **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Windows Remote Management (WinRM)** > **WinRM Client**.
1. Enable **Trust the remote machine**.
1. In the settings window, add the CMP appliance name to the **TrustedHostsList** field.
1. Under **WinRM Client**, enable **Allow unencrypted traffic**.
1. Under **WinRM Service**, enable **Allow basic authentication** and **Allow unencrypted traffic**.
1. Open **Control Panel** > **System and Security** > **Check Firewall Status** > **Advanced Settings** > **Inbound Rules**, find **Windows Remote Management (HTTP-In)**, open it, and make sure the public profile is enabled on the **Advanced** tab.
1. In PowerShell, run `Configure-SMRemoting` and answer yes to each prompt.
1. Allow inbound TCP on ports 5985 and 5986. On AWS, add the server to a security group that permits them. On Azure, they are usually open already in the server's network security group inbound rules.
## WinRM encryption
CMP encrypts WinRM traffic by default. The behavior is controlled by the `ENCRYPT_WINRM` setting, which is `True` unless you override it in your customer settings file. Setting it to `False` turns encryption off for every WinRM remote script execution, including the traffic between CMP and any Hyper-V resource handlers.
Command line arguments are not supported when running scripts on Windows servers.
## WinRM with CredSSP
CredSSP provides an encrypted TLS channel and delegates the user's credentials from the client to the target server, for further remote authentication within a Windows domain. Enable it per server: add the **Supports CredSSP** parameter to the server and set it to `True`.
This is not constrained delegation. CredSSP passes the user's full credentials to the server without constraint.
See the [Microsoft documentation on CredSSP](https://learn.microsoft.com/en-us/windows/win32/secauthn/credential-security-support-provider) for background.
## WinRM with Kerberos
Kerberos is the native authentication protocol for Windows domains. Used as the WinRM transport, it authenticates against the domain and gives access to the domain resources the account can reach.
The client requests a ticket-granting ticket (TGT) from the Key Distribution Center (KDC). The KDC verifies the credentials and returns an encrypted TGT and session key. The client keeps the TGT until it expires, then requests a new one.
The DNS servers configured on the CMP appliance **must** match those used by the KDC. Otherwise, the domain never appears when a connection is attempted.
### Enable Kerberos on an environment
The **Supports Kerberos** parameter can be set on a group, an environment, or a blueprint build item. An environment is the most common choice.
1. Go to **Admin** > **Environments** and select an environment.
1. Open the **Parameters** tab and select **Add**.
1. Select **Supports Kerberos** and select **Add**.
1. In the **Options** column, select the pencil icon to edit.
1. Change the value from `False` to `True`.
### Configure Kerberos on the appliance
Edit the Kerberos client configuration file on the CMP appliance, `krb5.conf`, and set the realm, KDC, and domain to match your environment. A minimal configuration defines a default realm under **libdefaults**, the KDC and admin server for that realm under **realms**, and the mapping from your DNS domain to the realm under **domain_realm**.
```text
includedir /etc/krb5.conf.d/
[libdefaults]
default_realm = MY.DOMAIN.COM
dns_lookup_realm = false
ticket_lifetime = 5d
renew_lifetime = 7d
[realms]
MY.DOMAIN.COM = {
kdc = ad-server.my.domain.com
admin_server = ad-server.my.domain.com
default_domain = my.domain.com
}
[domain_realm]
.my.domain.com = MY.DOMAIN.COM
my.domain.com = MY.DOMAIN.COM
```
Replace the realm, server, and domain names with your own.
Fully qualified domain names are case-sensitive. Keep the case consistent throughout the file.
Ticket lifetime is set in the same file. The example above uses five days, after which a new ticket must be requested.
### Initialize a ticket-granting ticket
Use a domain account with access to the resources you need.
1. In a terminal on the appliance, run `kinit` followed by your domain account name, which is case-sensitive.
1. Enter the password. Upon success, you receive a correctly formatted user principal name (UPN), which is all that Kerberos authentication needs thereafter.
Run `klist` to view the tickets that have been generated.
A TGT that has not expired must be associated with the UPN for Kerberos authentication to succeed. CMP does not regenerate or renew TGTs.
## Related
- [Authentication requirements](/docs/cmp/use/orchestration/remote-scripts/authentication-requirements/): the credentials to pair with this setup.
- [Configure remote script method](/docs/cmp/use/orchestration/remote-scripts/configure-method/): choosing the execution method.