SSH servers

This page explains how SSH access works with Ironchip PAM. It is for whoever administers the Linux servers and whoever connects to them.

How it works

The Ironchip PAM broker is not a jump server: it receives the SSH connection and takes it straight to the server, transparently to the client. The person does not install any app or an SSH wrapper.

• From the console (Terminal in PAM > My access) or with the usual ssh client.
• Invisible credential. The broker signs in to the server with the broker’s key or with a password the person does not know.
• Recorded session from start to finish, with processes and sudo commands on a timeline. See Sessions and recordings.

How the broker signs in

Method	When to use it
The broker’s own key pair	The server trusts the broker’s public key, which the console shows ready for authorized_keys. No secret is stored.
Managed by Ironchip: nobody types or sees it	A password nobody knows, changed every day and after every session. The enforcer sets it on local accounts, and the directory on domain accounts.
A stored password	A person’s password, stored encrypted. It requires PasswordAuthentication yes in /etc/ssh/sshd_config. Ironchip does not change it.
An IAM role	The broker identifies itself with an IAM role.

See Password rotation.

sudo control

With the Ironchip agent installed on the server, every sudo asks Ironchip after sudoers has said yes. A control policy decides: the command is allowed, rejected with an explanation of the reason or held until an approver authorizes it. The record shows who authorized it and under which rule.

Steps

1. Register the server as an SSH resource and add it to a target policy.

2. Name that policy in an access.

3. (Optional) Install the agent to control sudo, rotate the password and record processes.

4. The person requests access, if needed, and connects:

   ssh ticket-<TICKET>@<PAM_HOST> -p <PORT>