SSH command line

Using SSH to administer appliances

This is set up when an Appliance is created and can use password or public key authentication. Cloud deployments only support the Cloud provided public key method. Once signed in, Appgate SDP appliances support passwordless sudo. This is only enabled when a public key has been set for SSH access and when an SSH password has not been set. Typically you are running commands on only the one appliance. So for instance if you wanted to change the SSH keys on all members of the Collective then this would have to be performed on each appliance.

Temporary file system

The Appgate SDP appliance file system is read only except for '/mnt/data' - there are some other directories in the file system that have been bound to this directory in order to make them persistent. Any files 'saved' outside these areas will be removed upon system reboot. This has been done for two reason:

For security reasons it makes it very hard to interfere with the Appgate SDP appliance since all changes will be lost on reboot.
It makes it easy to root-cause issues caused by the use of third party executables as the system can always be returned to its original state.

Appgate SDP runs in what is called 'Overlayfs'; this is a temporary file system which is reloaded every time the system is booted. This means any changes made via the command line to the running system will be non-permanent; this includes any additional users created, as they will be automatically deleted if the appliance is rebooted.

There is a specific way to save third party executables so they will be persistent. Other actions should be performed using special commands such as cz-config or cz-iptables if the effect is to be persistent.

Restricting access to port 22

See system security - best practice for more information about securing SSH access to your appliance. You can disable the SSH server completely in System>Appliances>Networking>Advanced Mode.

Port 22 access to Connector with no static IP address

Occasionally you may find that you are unable to get to port 22 on an appliance. This may well be be the case with the Connector when it is deployed on a network where it is not assigned a fixed/public IP address. In this case you should follow the system security - best practice where it is suggested that port 22 access can be configured via the tunnel.

To SSH to a Connector with no fixed/public IP address, a tunneled connection will be made from the user's Appgate SDP Client via a Gateway down to the Connector where it loops back to itself. The principal of operation is the same for Express and Advanced, however the implementation details are slightly different.

Connector

For Express

Edit the Connector function on your Connector appliance. Refer to Configure appliances.
Add a Local Resources as the static IP address [192.168.8.250] of the Connector with a /32 subnet for ipv4 or /128 for ipv6.

For Advanced

Edit the Connector function on your Connector appliance. Refer to Configure appliances.
Identify a secondary static IP address [192.168.8.251] and assign it as an IP alias on the existing network interface or as a static IP to an additional network interfaces (e.g. on eth1).
Disable Source NAT from Local Resources. This will allow reaching the Connector by the secondary IP address.
Add a Client - specify a Name [i.e. ssh] and define the Local Resources as the secondary IP address of the Connector with a /32 subnet for ipv4 or /128 for ipv6.

Site

Configure a Site where the user and Connector will rendezvous. For this to work the Connector's Client and user's Client must rendezvous at the same Gateway! If there are more than one Gateway per Site then this is handled automagically in the case of Express and for Advanced is handled by the Entitlement.

Identity Provider

Make sure that the built-in Connector identity provider has ip pools assigned [192.168.100.0/24] depending on your use case (ipv4 and/or ipv6). The default IP pools can be configured (if required) to provide a larger range of IPs for the virtual tunnel interfaces. Refer to IP Pools.

Create a user Entitlement to allow up traffic to the IP address of the Connector, e.g. TCP up to 192.168.8.250 on port 22.

For Advanced

For the user Entitlement make sure to check Enable Monitoring to ensure the Client will hunt for Connector's Gateway to ensure a rendezvous.
Create a Connector Entitlement to allow down traffic from the user's tun IP address, e.g. TCP down from 192.168.1.20 on port 22.

Policy

Ensure that your user Policy includes the TCP up Entitlement (to the Connector).

For Advanced

Create a Connector SSH Policy - making sure the Policy is applied only to that particular Connector Client by assigning using Identity Provider is "Connector" AND `user.clientName` is name [i.e. ssh].
Assign the Connector's TCP down Entitlement to the SSH Policy.

Client

Now test the access from the user Client, it should have access to port 22 on the Connector as configured in your Entitlement.

Managing the SSH password

Sign-in to the appliance using SSH and enter:

sudo cz-config passwd

This will prompt you for your existing password and allow a new one to be entered.

To remove the SSH password enter:

sudo cz-config set -j users/0/nopasswd true

Preventing password guessing

There is an Ubuntu feature which prevents the guessing/trying of countless passwords. The trigger point where the user connection can be changed if required:

sudo cz-config set -j sshServer/max_auth_tries 99

This feature uses sshd's "MaxAuthTries" which specifies the maximum number of authentication attempts permitted per connection. Once the number of failures reaches half this value, additional failures are logged. The default is 6.

Disabling password authentication

Irrespective of whether a SSH password has been set, password authentication can be disabled from the admin UI in System>Appliances>System Settings; find the SSH Server section and disable <Password Authentication>.

Managing the SSH key

Setting/changing the SSH key

If a new appliance is set up from the command line, then the first Controller will be seeded with a CZ user password for SSH access to the Appliance. (This will not be the case for Cloud instances which require PKI authentication.) Strong passwords are fine to use, but public key authentication is almost always stronger. The SSH authentication should be changed to public key for the first Controller.

First generate your SSH key pair.

Adding keys

To add this SSH key (for the cz user) on an appliance. From the command line on the 1st Controller do one of the following:

sudo cz-config user --authorized-keys "KEY" where KEY is your ssh key pasted between the "" (e.g. "ssh-rsa AABBCCDD......")
sudo cz-config user --authorized-keys-file FILE where FILE is the path to your ssh key.

The above cz-config commands will overwrite any current keys. If you are trying to ADD another key, then instead you must:

Copy the file /home/cz/.ssh/authorized_keys to somewhere else such as temp/new_keys.
Edit the new file to add the new key and save.
NOTE: There must be ONLY ONE KEY PER LINE.
Do the following: sudo cz-config user --authorized-keys-file FILE

Your SSH key(s) for the 'cz' user can now be used.

Pinning keys

To pin the key(s), preventing the cloud provider from overriding them do the following:

sudo cz-config user --pin {true,false}

Defaults to false.

You can now disable password authentication when connecting to the appliance using SSH.

Disabling password authentication

From the admin UI go to System>Appliances>System Settings find the SSH Server section and disable <Password Authentication>.

Setting SSH 'Message of the Day'

You can set (and remove) a specific 'message of the day' for SSH users with the following commands:

sudo cz-config set motd/message "my message"

sudo cz-config del motd/message

NOTE
UTF-8 support: If you are using Putty you need to change your putty settings in Window -> Translation -> Received data to UTF8.