Jump Server Architecture and Implementation Using Linux PAM for Secure Access

This article introduces a jump‑server (referred to as “jmp”) implementation that supports Linux servers, Windows servers, and other terminals such as MySQL, Redis, and network devices. Unlike common jump‑server solutions, the presented design does not store any Linux account passwords, keys, or other credentials, thereby eliminating the risk of credential leakage.

The key distinguishing feature is the use of Linux's Pluggable Authentication Modules (PAM) mechanism. By modifying system‑level PAM configuration on each Linux host, the jump‑server partially takes over the authentication process.

Background: Linux PAM

PAM is a flexible authentication framework widely used in Unix/Linux distributions. It separates services from their authentication methods via dynamically linked libraries and provides Service Programming Interface (SPI) and Application Programming Interface (API) for developers.

The core PAM capabilities include authentication management, account management, session management, and password management, each exposing functions such as pam_authenticate , pam_setcred , pam_open_session , and pam_chauthtok .

Typical PAM module types are:

auth : verifies user identity (e.g., password prompt).

account : checks account properties (e.g., login permission).

session : defines actions before login and after logout.

password : handles password changes.

Common PAM modules mentioned include pam_unix.so , pam_cracklib.so , pam_loginuid.so , pam_securetty.so , pam_rootok.so , pam_console.so , pam_permit.so , pam_env.so , pam_xauth.so , pam_stack.so , and pam_warn.so .

Jump‑Server System Architecture

The system is divided into five services and one component:

jmp-api : HTTP API on port 8080, the sole entry for database access and permission management.

jmp-ssh : SSH proxy on port 2200, provides direct access to Linux servers and other terminals.

jmp-socket : WebSocket/Socket.io service on port 8080, forwards traffic to jmp-ssh and enables web‑based terminal access.

jmp-rdp : RDP proxy on port 8080, offers web‑based remote desktop for Windows servers.

jmp-sftp : File upload/download service, supports S3 storage.

jmp-agent : Deployed on each Linux host, runs a persistent process, pulls configuration from jmp-api , and provides a custom PAM module ( jmp.so ) that intercepts SSH, sudo, and other privileged services.

All services are stateless, allowing deployment across multiple data centers. HTTP services use Nginx for routing and load balancing; non‑HTTP services use layer‑4 load balancers (LVS, VGW). Automatic degradation strategies handle time‑outs in dangerous‑command detection or authentication by falling back to cached data or default allow/deny policies.

Core Design Flow

Login to Jump‑Server : Users connect via SSH to jmp-ssh , which forwards the username, encrypted password, and secondary authentication data to jmp-api for permission verification.

Login to Target Server : After successful jump‑server authentication, jmp-ssh initiates an SSH session to the target host. The jmp-agent on the target intercepts the authentication via its PAM module, encrypts the user and host information, and calls jmp-api to confirm login rights.

Command Interaction : Once a session is established, user commands are examined by jmp-ssh against a per‑host dangerous‑command rule set. Depending on the rule, the command is allowed, warned, or blocked.

User Switching / Privilege Escalation : Commands such as sudo or su are proxied to the target host, where jmp-agent again uses PAM to verify whether the user has root or other elevated privileges.

Web Interaction : After SSO login, the web client contacts jmp-socket , which obtains a temporary credential from jmp-api , forwards it to jmp-ssh , and acts as an SSH client on behalf of the user.

Dangerous Command Interception : jmp-ssh loads regex‑based rule sets for each host, matches user input, and decides to alert, block, or pass the command. Alerts are sent to the user, the user's manager, and system administrators.

Non‑Linux Targets : Windows servers are accessed via jmp-rdp (using Apache Guacamole to translate RDP to WebSocket). MySQL and Redis terminals are accessed through Unix sockets on the host, with jmp-agent forwarding I/O. Network devices are managed by retrieving connection info from jmp-api and establishing appropriate protocol sessions.

Permission Rules and Approval Workflow

Default permissions are granted based on role (service owner, project owner, operations staff) and host type (online/offline). Permissions include login only or login + ROOT. When a user needs access beyond defaults, they must submit a request that follows an approval chain involving service/project owners and operations personnel.

Advantages of This Approach

Convenient operation and good user experience : Supports SSH, RDP, and web terminals; micro‑service architecture ensures low latency and high availability.

Security and auditability : PAM‑based interception records exact usernames in logs, enabling precise traceability; dangerous‑command blocking adds an extra safety layer.

Clear service responsibilities : Stateless micro‑services can be scaled horizontally; components can be added or removed as needed.

In summary, the presented jump‑server design offers a simple, highly available, and secure solution for managing large fleets of servers, leveraging Linux PAM to centralize authentication without altering standard system accounts.