LLM-SSHH: An LLM-Powered SSH Honeypot Framework via State Snapshot

Abstract

SSH honeypots serve as critical infrastructure for cyber threat intelligence, but existing LLM-based systems suffer from context window limitations causing state loss and hallucination-driven inconsistencies, making them easily detectable through simple verification tests. To address these limitations, we propose LLM-SSHH, a framework combining explicit state management with LLM generation to achieve long-term interaction consistency. The system maintains a persistent state snapshot organized as a three-component tuple capturing file system state, runtime context, and system metadata. The framework serializes the current state into LLM prompts and validates generated responses against state constraints to reject hallucinations. Validated responses update the state snapshot, forming a closed loop that ensures consistent state evolution throughout extended interactions. Experimental results demonstrate that LLM-SSHH achieves a mean detection rate of 0.150, representing a 3 to 4 times improvement over existing methods, significantly extending honeypot survivability for threat intelligence collection.

1. Introduction

SSH honeypots serve as critical infrastructure for cyber threat intelligence, enabling security researchers to observe attacker behavior, collect malware samples, and identify emerging attack patterns in controlled environments [1,2]. Traditional rule-based honeypots such as Cowrie [3] and Kippo [4] simulate Linux shell environments using programmed command handlers and static response templates [5]. While these systems can effectively detect automated attacks and record their behavior, they suffer from significant limitations in deployment costs and operational flexibility [6]. Each new command requires manual rule implementation, leading to development and maintenance costs that scale linearly with the diversity of attack techniques. More critically, fixed rule sets cannot adapt to unanticipated command variations or emerging attack techniques. These limitations underscore the need for cost-efficient and flexible honeypot architectures.

Recent advances in large language models such as GPT-4 [7] and Claude 3 [8] have enabled the development of adaptive honeypots capable of interpreting arbitrary shell commands and generating realistic system responses. Systems such as HoneyLLM [9] and shelLM [10] have demonstrated these capabilities through structured prompting and chain-of-thought reasoning respectively. Unlike traditional rule-based honeypots, LLM-based approaches can handle significantly broader ranges of attacker commands. For example, when an attacker executes grep -r “password”/etc, an LLM can interpret the search intent and generate contextually appropriate responses that would require extensive pre-programming in traditional systems. Moreover, different SSH honeypot configurations can be achieved simply by modifying the prompt that defines the LLM’s behavior, eliminating the need for code-level modifications. These capabilities enable the deployment of cost-effective and flexible SSH honeypots that address the scalability and adaptability limitations of rule-based architectures.

However, LLM-based honeypots face two critical challenges rooted in the inherent limitations of large language models. First, context window limitations cause the model to lose track of earlier operations such as file creation or directory modification, leading to responses that contradict prior state changes [11,12]. As illustrated in Figure 1 (left), when an attacker creates a file test.txt and later queries its existence after executing numerous unrelated commands, the system fails to reflect this creation due to context degradation. Second, hallucinations emerge from the generative nature of LLMs, which produce plausible but incorrect outputs [13,14]. For instance, the honeypot may generate inconsistent file listings when an attacker executes ls /home repeatedly or produce output formatting that subtly deviates from genuine Linux systems. Figure 1 (right) shows a typical hallucination scenario where the system outputs ISO-formatted timestamps without proper time-style flags when responding to ls -l cosfs.sh, violating standard Linux output conventions that attackers can use for fingerprinting. Attackers can detect these hallucinations by comparing outputs from repeated queries or checking for state inconsistencies across commands. Both failure modes are exploitable through simple testing sequences that reliably distinguish LLM-based honeypots from genuine systems within minutes, fundamentally undermining their effectiveness.

To address these limitations, we propose LLM-SSHH, a novel framework that synergistically combines explicit state management with LLM generation to ensure long-term interaction consistency while preserving response flexibility. The framework introduces a persistent state snapshot module that maintains an authoritative representation of the simulated Linux environment, organized as a three-component tuple $(\mathcal{F},\mathcal{C},\mathcal{M})$ capturing file system state, runtime context, and system metadata respectively, serving as the ground truth source for all response generation and effectively mitigating state loss caused by context window limitations. The response generation mechanism serializes the current state snapshot into LLM prompts to guide model outputs, while an output validation module ensures all LLM-generated responses conform to state constraints, automatically rejecting inconsistent outputs that exhibit hallucinations and triggering regeneration when necessary. Validated responses are then mapped back to update the state snapshot, forming a closed loop of state-driven generation, validation, and incremental updates that enables monotonic state evolution throughout extended interactions. This design allows LLM-SSHH to overcome the reliability challenges of existing LLM-based honeypots while maintaining response flexibility and significantly extending attacker interaction survivability.

In particular, the contributions of this paper are summarized as follows:

• We identify and analyze two fundamental flaws in LLM-based SSH honeypots: state loss from context window limitations and output hallucinations from generative mechanisms, demonstrating their exploitability.
• We propose LLM-SSHH, combining persistent state snapshots with state-driven response generation and output validation to achieve state consistency and generation flexibility.
• We implement and evaluate our framework, achieving substantially lower detection rates and significantly extended interaction survivability compared to existing methods.

The remainder of this paper is organized as follows. Section 2 reviews related work on LLM applications in cybersecurity and honeypot technologies. Section 3 formalizes the problem definition and evaluation metric. Section 4 presents the proposed LLM-SSHH framework in detail, including the state snapshot mechanism, output generation, and output validation modules. Section 5 describes the experimental setup, baseline comparisons, ablation study, and case analysis. Finally, Section 6 concludes the paper and discusses future research directions.

2. Related Work

2.1. LLM in Cybersecurity

Large language models have demonstrated significant potential in addressing complex cybersecurity challenges that traditional data-driven approaches struggle to handle [15]. Research shows that LLMs are being applied to an expanding range of security tasks, including vulnerability detection, malware analysis, and network intrusion detection [16,17]. In security operations center automation, LLMs exhibit the capability to process massive volumes of security alerts and perform threat intelligence reasoning, enhancing defensive operations [18]. For specific threats such as distributed denial of service attacks, LLM-based defense frameworks can provide explainable detection results and actionable mitigation measures [19]. More notably, LLM-driven autonomous agents are emerging as a new paradigm in cybersecurity, capable of orchestrating complex multi-step security workflows [17]. In network security environment simulation, fine-tuned LLMs can serve as red team agents executing sophisticated attack scenarios, providing valuable support for defense strategy evaluation [20]. These applications highlight the unique advantages of LLMs in understanding complex security semantics, generating contextually appropriate responses, and adapting to dynamic threat environments.

However, when LLMs are deployed in practical cybersecurity applications, they also face significant reliability challenges [21]. While these challenges may manifest differently across various security domains, the hallucination problem, as an inherent flaw of LLMs’ generative nature, is particularly critical in cybersecurity scenarios requiring precise information maintenance. Therefore, this work focuses on SSH honeypots, a specific application domain that demands long-term interaction state consistency, exploring how to address state management and output reliability issues while preserving the flexible response capabilities of LLMs.

2.2. Honeypots Technologies

Honeypot systems have evolved significantly across both technical implementation strategies and application domains. Early architectures relied on rule-based or script-driven approaches using pre-defined command handlers and static templates, which proved effective for capturing automated attacks but exhibited limited adaptability and detectable fingerprints [22,23]. The emergence of virtualization and containerization enabled more sophisticated deployments with improved isolation and scalability, where container-based architectures dynamically generated honeynet topologies while hybrid approaches combining virtual machine introspection enabled transparent malware analysis [24,25]. Most recently, large language model integration has introduced adaptive capabilities that fundamentally expand interaction possibilities [9]. LLM-powered systems leverage natural language understanding to generate contextually appropriate responses to arbitrary commands, extending engagement depth beyond pre-programmed repertoires through structured prompt engineering and chain-of-thought reasoning [9,26]. From an application perspective, honeypots have diversified across domains, with network-specific deployments revealing heterogeneous attack patterns and Industrial Control System honeypots addressing specialized protocols [27]. However, even sophisticated honeypots require careful configuration to avoid fingerprinting [27], and LLM-based approaches face persistent challenges in maintaining stateful consistency—the critical gap our work addresses.

Recent LLM-powered SSH honeypots have shown promising results in attacker engagement, demonstrating strong capabilities in interpreting arbitrary commands and generating natural responses. However, these systems face critical challenges including output hallucination and short-term memory loss, which enable trivial identification through simple state-verification tests. This paper focuses on developing a new framework that maintains explicit state consistency while preserving response naturalness, extending SSH honeypot survivability against sophisticated adversarial probing.

3. Problem Formulation

3.1. Task Definition

In this paper, we formalize the LLM-based SSH honeypot as a stateful interactive system that processes attacker commands over a single SSH session while maintaining explicit system state. Given a sequence of commands $\{c_1,c_2,\dots ,c_n\}$, the honeypot generates a corresponding sequence of responses $\{r_1,r_2,\dots ,r_n\}$ while updating its internal state representation. We define the system state transition and response generation as follows:

$$r_i=f(c_i,{\mathcal{S}}_{i-1}),{\mathcal{S}}_i=g(c_i,{\mathcal{S}}_{i-1}),$$

(1)

where ${\mathcal{S}}_0$ denotes the initial state at session start, $f(·)$ represents the response generation function, and $g(·)$ represents the state update function. The system must achieve two key objectives: first, each response $r_i$ should strictly follow the output format specifications and command behaviors of genuine Linux systems to ensure authenticity; second, responses must respect the accumulated state history encoded in ${\mathcal{S}}_{i-1}$ to maintain consistency across all interactions.

Table 1. Summary of mathematical notation and symbols used in the LLM-SSHH framework.

Symbol	Description
$c_i,r_i$	Command and response at interaction round i
${\mathcal{S}}_i=(\mathcal{F},\mathcal{C},\mathcal{M})$	State snapshot: file system, context, metadata
$f(·),g(·)$	Response generation and state update functions
$\mathcal{F}$	File system state (path → file objects)
$\mathcal{C}=\{d,\mathcal{E},\mathcal{H},\mathcal{P},\mathcal{N},t_{\mathrm{sys}},\dots \}$	Context state components
$\mathcal{M}$	System metadata (hostname, kernel, OS, etc.)
$\mathcal{V}$	Output validation function
$T_{\mathrm{survive}}$	Interaction survivability metric

summarizes the key notation used throughout this paper for reference.

In this paper, we evaluate system effectiveness using interaction survivability, which measures the honeypot’s ability to sustain prolonged attacker engagement without being detected. Unlike existing benchmarks that evaluate honeypots on static test sets or single-round command accuracy, interaction survivability focuses on long-term deception capability during continuous reconnaissance sessions, which directly reflects the system’s capacity for real-world threat intelligence collection. Formally, we define interaction survivability as the maximum number of command rounds an attacker can execute before definitively identifying the system as a honeypot through consistency verification tests:

$$T_{\mathrm{survive}}=max\left\{i\mid \forall j\le i,\mathrm{responses}\mathrm{remain}\mathrm{undetected}\right\},$$

(2)

where higher values of this metric indicate that the honeypot can sustain deception over extended sessions, thereby collecting more comprehensive attacker behavior data and threat intelligence.

3.2. Assumptions

Our problem formulation operates under the following assumptions regarding system scope, resource constraints, and attacker behavior:

• System Scope. The honeypot simulates a basic Linux SSH server environment where all command outputs are generated through simulation without executing real binaries or kernel operations. Input commands are assumed to be syntactically valid.
• Resource Constraints. The system has access to capable LLM APIs such as GPT-4 or Claude, subject to standard API latency and rate limits.
• Attacker Model. The attacker is assumed to possess Linux expertise and can execute arbitrary shell commands but has no access to the internal implementation details of the honeypot.

4. LLM-SSHH

4.1. Algorithm Overview

We propose LLM-SSHH, a novel framework that addresses context window limitations and hallucinations in LLM-powered SSH honeypots by combining deterministic state management with selective LLM generation. Our design integrates explicit state management with selective LLM generation to balance consistency and adaptability. As illustrated in Figure 2, the framework comprises three synergistic components that form a closed-loop interaction through well-defined data flows. At the foundation, the state snapshot module maintains a persistent, authoritative representation of the simulated Linux environment, organized as a three-component tuple $(\mathcal{F},\mathcal{C},\mathcal{M})$ capturing file system state, runtime context, and system metadata respectively. Building on this foundation, the output generation module serializes the current state snapshot into structured prompts that guide the LLM to produce responses grounded in authoritative state and command semantics. Before responses reach attackers, the output validation mechanism applies command-specific rules to verify conformance with the state snapshot, rejecting inconsistent outputs and triggering regeneration when necessary. Validated responses are then mapped back to the state snapshot to complete state updates, forming a continuously evolving closed loop that ensures both consistency and adaptability throughout extended interaction sessions.

4.2. State Snapshot

To address the context window limitations and hallucinations inherent in LLM-based SSH honeypots, we design a state snapshot mechanism that serves as the authoritative ground truth for system state. We organize the system state as a three-component tuple $\mathcal{S}=(\mathcal{F},\mathcal{C},\mathcal{M})$, where each component operates with distinct responsibilities while maintaining cross-component consistency. The file system state $\mathcal{F}$ captures persistent storage content, the context state $\mathcal{C}$ tracks runtime session dynamics, and the system metadata $\mathcal{M}$ encapsulates immutable system identity.

• File System State $\mathcal{F}$: Represents the honeypot’s file system and models it using a dictionary data structure that maps complete paths to file information (e.g., {“/etc/passwd”: FileObject}), formalized as $\mathcal{F}:\mathrm{Path}\to \mathrm{FileObject}$. Each file object $f=\langle \mathrm{type},\mathrm{content},\mathrm{meta}\rangle$ contains a type field (file or directory), content payload, and metadata (permissions, ownership, timestamps). For instance, the dictionary key /root/script.sh maps to $\mathrm{FileObject}(\mathrm{type}=\mathrm{file},\mathrm{content}=“\#!/ \mathrm{bin/bash}\dots ”$, $\mathrm{meta}=\{\mathrm{perm}:755,\mathrm{owner}:\mathrm{root},\dots \})$. Path prefix relationships implicitly encode directory hierarchy, enabling efficient query resolution where listing /root simply matches all /root/* paths without constructing explicit tree structures.
• Context State $\mathcal{C}$: Maintains mutable session information as an extensible set $\mathcal{C}\supseteq \{d,\mathcal{E},\mathcal{H},\mathcal{P},\mathcal{N},t_{\mathrm{sys}},\dots \}$, where d stores the current working directory, $\mathcal{E}$ holds environment variables, $\mathcal{H}$ records command history synchronized with /root/.bash_history in $\mathcal{F}$, $\mathcal{P}$ maps process IDs to descriptors, $\mathcal{N}$ maintains network connections, and $t_{\mathrm{sys}}$ tracks system timestamps. Additional fields such as user sessions or open file descriptors can be incorporated based on deployment requirements.
• System Metadata $\mathcal{M}$: Encapsulates immutable system identification attributes as $\mathcal{M}\supseteq \{\mathrm{hostname},\mathrm{kernel},\mathrm{os},\mathrm{arch},\mathrm{uid},\dots \}$. All fields are initialized once at session start. The field set can be extended with new entries during runtime, but existing field values remain unchanged to ensure consistency. This design guarantees temporal consistency for repeated invocations of system information commands such as uname -a, hostname, or cat /etc/os-release.

The state snapshot employs a two-phase strategy of minimal initialization and incremental updates. At session start, the system establishes a lightweight baseline by provisioning only essential system structure rather than exhaustive content. Specifically, $\mathcal{F}$ initializes core directories and critical files such as /etc/passwd, $\mathcal{C}$ sets the initial working directory and standard environment variables, and $\mathcal{M}$ adopts realistic patterns (such as hostname “web-srv-04”) that are configurable via profile templates. The baseline values can be derived from reference system configurations, developer experience, or LLM-generated defaults, as the exhaustiveness of the initial content is not critical given that the state evolves organically through subsequent incremental updates. For state updates, each attacker command $c_i$ is fed into the LLM alongside the current state snapshot ${\mathcal{S}}_{i-1}$. The LLM parses the command semantics and determines which state components require modification along with the specific operation types, such as adding new entries, updating existing ones, or removing entries. The LLM returns only incremental changes rather than complete state reconstruction, significantly reducing token consumption. For example, the touch command adds a file object in $\mathcal{F}$, the cd command updates the working directory in $\mathcal{C}$, while $\mathcal{M}$ remains immutable and returns realistic errors for modification attempts. This approach enables organic state evolution that balances lightweight initialization with dynamic adaptation.

4.3. Output Generation

The output generation module leverages large language models to produce contextually appropriate responses $r_i$ based on the current state snapshot ${\mathcal{S}}_{i-1}$ and attacker command $c_i$. The LLM acquires the current state not through conversational memory but through explicit serialization of ${\mathcal{S}}_{i-1}$ into each prompt, fundamentally distinguishing our approach from context-window-dependent methods. The generation process serializes the state tuple ${\mathcal{S}}_{i-1}=(\mathcal{F},\mathcal{C},\mathcal{M})$ and combines it with command $c_i$ and Linux behavior specifications to form the LLM prompt. To balance prompt length against information completeness, the system adopts a conditional two-step generation mechanism where the file system component $\mathcal{F}$ contains only file paths (e.g., /etc/passwd, /root/.bashrc), while context $\mathcal{C}$ (working directory, environment variables, command history) and metadata $\mathcal{M}$ (hostname, kernel version, OS type) are fully serialized as key-value pairs. As illustrated in Figure 3, in the first step, the prompt instructs the LLM to determine whether the command requires specific file content based on command semantics and the path list. For commands without file reading requirements (e.g., ls, pwd), the LLM directly generates the final response, whereas for commands requiring file content (e.g., cat /etc/passwd, grep “root” /etc/shadow), the LLM outputs the required file path to trigger the second step. In the second step, the system appends the complete file content to the prompt and reinvokes the LLM to generate the final output. By embedding the state snapshot as an authoritative data source in the LLM context, this mechanism ensures that generated responses remain faithful to the established system state while flexibly handling reconnaissance commands.

4.4. Output Validation

Despite state-grounded prompting strategies, LLMs may still generate outputs that violate system consistency due to their inherent probabilistic nature. The validation mechanism serves as the final safeguard in our framework, ensuring that all LLM-generated responses exhibit behavior consistent with genuine Linux systems before being delivered to attackers. Formally, we define a validation function $\mathcal{V}:r\times \mathcal{S}\times c\to \{\mathrm{ACCEPT},\mathrm{REJECT}\}$ that verifies whether response r generated for command c conforms to the current state $\mathcal{S}$ through command-specific consistency rules. This mechanism operates through three complementary categories of consistency rules that address file system operations, temporal stability, and structural formatting respectively. When validation rejects a response ($\mathcal{V}(r,\mathcal{S},c)=\mathrm{REJECT}$), the system regenerates the response.

• File System Consistency. For directory listing commands such as ls, the validator extracts the ground truth file set $\mathcal{G}=\{f:f\in \mathcal{F}\}$ from the state snapshot and accepts response r only if $\mathcal{G}\subseteq \mathrm{Extract}\left(r\right)$, ensuring that all files recorded in the state snapshot appear in the output while allowing the LLM to generate additional realistic files to enhance system authenticity. Similar validation applies to file content (cat) and path resolution (pwd) commands.
• Temporal Consistency. System identification commands such as uname, hostname, and date must return identical outputs across repeated invocations within a single session. The system maintains a consistency cache $\mathcal{K}$ mapping each command to its first execution output, validating subsequent executions by checking whether $r=\mathcal{K}\left[c\right]$ for repeated commands or $c\notin \mathcal{K}$ for first-time invocations.
• Structural Integrity. Format-sensitive outputs such as ps aux and netstat are validated against structural templates to ensure content completeness (all entries from $\mathcal{C}.\mathcal{P}$ or $\mathcal{C}.\mathcal{N}$ must appear), state mapping accuracy, and format compliance with standard Linux specifications. Any missing fields, formatting errors, or content mismatches trigger rejection to prevent outputs that would confuse parsing tools or reveal simulation artifacts.

5. Experiment and Evaluation

5.1. Experimental Setup

5.1.1. Experimental Design Rationale

Evaluating LLM-driven SSH honeypots fundamentally requires testing how long they can sustain interactive sessions before being identified by attackers, which directly determines their effectiveness in collecting threat intelligence. The most ideal evaluation approach would involve real attackers engaging in continuous adversarial interactions with honeypot systems, with method performance judged by the length of interaction sequences achieved. However, purely manual evaluation faces significant challenges in practice, including prohibitively high costs and low testing efficiency. Considering that the evaluation core lies in two key steps, namely attackers generating attack commands based on context and attackers judging whether the system is a honeypot based on interaction sequences, we can design targeted solutions combining automation with human validation.

We adopt the widely recognized paradigm in the AI field of LLM-assisted generation with human review [28], a design that preserves the credibility of manual evaluation where key decisions are expert-driven while significantly improving experimental efficiency by leveraging LLMs’ strong instruction-following, contextual understanding, and controllable generation capabilities.

• For attack command generation, the LLM generates candidate commands based on the current system state and previously executed commands, followed by review from one cybersecurity researcher who validates syntactic correctness, attack logic rationality, and safety to avoid actual destructive operations, with the LLM required to regenerate until approval is obtained if deemed unreasonable. This human-machine collaboration approach can generate more diverse and context-relevant attack sequences compared to static command sets.
• For interaction sequence judgment, to avoid requiring manual assessment for every interaction, we artificially limit session interaction sequence lengths to between 5 and 50 rounds, submitting complete interaction sequences of specific lengths to the LLM for preliminary judgment (i.e., three independent judgments are performed for each sequence length, and the final decision is determined by majority voting), followed by human review to confirm the final results and determine whether the system is a honeypot. The Detection Rate (DR) is then calculated across multiple experimental trials.

5.1.2. Baseline Methods

We compare our LLM-SSHH approach against six baseline systems spanning different SSH honeypot paradigms. All baseline implementations were obtained from public repositories or faithfully reproduced from original publications to ensure fair comparison.

• Docker (Real Linux Environment) [29]: A genuine Ubuntu 20.04 container serving as the oracle for evaluating output correctness, where all commands are executed in a real Linux environment without any simulation or emulation.
• LLM-Basic [30]: A minimal LLM-powered honeypot that directly forwards attacker commands to a language model without maintaining explicit state, relying solely on the LLM’s short-term conversational memory for context retention.
• shelLM [10]: An LLM-driven honeypot employing chain-of-thought prompting and session-based history management, where the complete interaction history is preserved across sessions but lacks a structured filesystem representation.
• LLMHoney [31]: A hybrid architecture combining dictionary-based caching for common commands with LLM generation for novel inputs, featuring a virtual filesystem but limited to predefined file structures.
• HoneyLLM [9]: An LLM-powered medium-interaction honeypot that generates authentic shell responses to deceive attackers without exposing a real operating system.
• Cowrie_LLM [32]: An enhanced version of the widely-deployed Cowrie honeypot augmented with LLM capabilities, where pre-scripted responses are replaced by dynamic LLM-generated outputs while retaining Cowrie’s static filesystem emulation.

5.1.3. Evaluation Metrics

We adopt Detection Rate (DR) as the primary evaluation metric, defined as the proportion of sessions identified as honeypots. This metric is computed based on the interaction survivability $T_{\mathrm{survive}}$, where for each evaluation session s, we record the maximum number of command rounds an attacker can execute before identifying the honeypot as $T_{\mathrm{survive}}\left(s\right)=max\{i\mid \forall j\le i,\mathrm{responses}\mathrm{remain}\mathrm{undetected}\}$. A session is judged as detected when $T_{\mathrm{survive}}\left(s\right)$ is less than the total session rounds, denoted as $\mathrm{detected}\left(s\right)=\mathrm{True}$, and the final DR is calculated as

$$\mathrm{DR}={\displaystyle \frac{\left|\right\{s\in S:\mathrm{detected}\left(s\right)=\mathrm{True}\left\}\right|}{\left|S\right|}},$$

(3)

where S represents the set of all evaluation sessions. A lower detection rate indicates the honeypot can sustain longer interaction rounds without being identified, meaning higher $T_{\mathrm{survive}}$ values, thereby collecting more comprehensive attacker behavior data and threat intelligence, which constitutes the core optimization objective of this work.

5.1.4. Hyperparameter Settings

All experiments employed Qwen-Max (qwen-max-latest) as the LLM-powered attacker with temperature $0.8$ to balance between systematic reconnaissance and adaptive exploration. The evaluation jury comprised three models (Qwen-Max, Kimi-v1, and GPT-4o) operating at temperature $0.2$ for consistent judgments. To ensure fair comparison, all LLM-based baseline systems were configured with the same backbone model (GPT-5.4) at temperature $0.8$ while retaining their original prompt structures as described in the respective publications. The Docker ground-truth environment ran Ubuntu 20.04 LTS with kernel 4.15.0-20-generic, allocated 512 MB memory, and network isolation enabled. Each experimental session was initialized with a fresh honeypot instance to eliminate cross-contamination between trials.

5.2. Experimental Results

5.2.1. Detection Rate Across Interaction Lengths

Following the evaluation methodology described above, we conducted controlled experiments across varying interaction lengths ranging from 5 to 50 rounds, with each configuration evaluated through 10 independent trials.

Table 2. Detection rates of honeypot systems across different interaction lengths (lower is better).

Method	Interaction Rounds									Mean
	5	10	15	20	30	35	40	45	50
True Docker	0.0	0.0	0.0	0.0	0.0	0.1	0.1	0.2	0.2	0.075
ShelLM	0.0	0.1	0.2	0.1	0.6	0.5	0.8	0.8	1.0	0.513
LLMHoney	0.0	0.0	0.1	0.1	0.3	0.5	0.7	1.0	0.9	0.450
HoneyLLM	0.1	0.2	0.1	0.3	0.5	0.6	0.8	0.9	0.9	0.550
Cowrie_llm	0.0	0.0	0.2	0.3	0.4	0.5	0.8	1.0	1.0	0.613
LLM-Basic	0.1	0.1	0.3	0.2	0.4	1.0	1.0	0.9	1.0	0.625
LLM-SSHH (Ours)	0.0	0.0	0.0	0.0	0.0	0.2	0.3	0.3	0.4	0.150
Mean	0.029	0.086	0.143	0.157	0.329	0.514	0.643	0.729	0.771	-

presents the comprehensive detection rates, demonstrating that LLM-SSHH achieves the lowest detection rates among all honeypot systems with an overall mean of 0.150, representing a 3.0 times improvement over LLMHoney (0.450), 3.4 times over shelLM (0.513), 3.7 times over HoneyLLM (0.550), and 4.2 times over LLM-Basic (0.625). A closer examination of performance across different interaction stages reveals that LLM-SSHH maintains perfect concealment (detection rate = 0.0) throughout short-to-medium interactions spanning 5 to 30 rounds, a period during which competing methods begin exhibiting detectable artifacts. More importantly, even in extended interactions (35–50 rounds) where accumulated LLM hallucinations and context limitations affect all methods, LLM-SSHH demonstrates graceful degradation with detection rates gradually increasing from 0.2 to 0.4, in stark contrast to competitors approaching near-complete failure (detection rates ≥ 0.8–1.0). This performance advantage stems from our state snapshot architecture, which explicitly maintains the three-component state representation through incremental updates, providing essential guarantees for sustaining deception effectiveness across prolonged interactive sessions.

5.2.2. Validation of Evaluation Methodology

To validate the effectiveness of our experimental approach, particularly the interaction sequence-based honeypot judgment method, we deployed a genuine Ubuntu 20.04 environment based on Docker, executing all attacker commands in a real Linux shell (labeled as “True Docker” in Table 2). As shown in the table, the Docker environment achieves an overall detection rate of 0.075, confirming the effectiveness of our “LLM preliminary judgment + human review” assessment scheme. This value demonstrates the scheme’s validity through two aspects: the non-zero detection rate indicates the judgment method possesses the capability to distinguish between genuine systems and honeypots, while the low rate shows the method avoids excessive sensitivity that would misclassify real systems as honeypots. On the other hand, the Docker environment’s detection rate is significantly lower than all honeypot methods (0.150 for LLM-SSHH and 0.450–0.625 for other approaches), suggesting that current LLM-based SSH honeypots still exhibit detectable gaps compared to genuine systems, particularly becoming more identifiable during medium-to-long interaction sequences with attackers.

5.2.3. Ablation Study

To validate the individual contributions of our proposed components, we conducted ablation experiments by systematically removing key modules from the complete LLM-SSHH framework. As shown in

Table 3. Ablation study on the individual contributions of state snapshot and output validation modules to detection rate reduction.

Configuration	Interaction Rounds									Mean
	5	10	15	20	30	35	40	45	50
w/o State Snapshot	0.1	0.2	0.4	0.5	0.7	0.8	0.9	1.0	1.0	0.622
w/o Output Validation	0.0	0.1	0.1	0.2	0.3	0.4	0.5	0.6	0.7	0.322
Full LLM-SSHH	0.0	0.0	0.0	0.0	0.0	0.2	0.3	0.3	0.4	0.150

, we evaluated three configurations: (1) w/o State Snapshot removes the state snapshot module and relies solely on LLM conversational memory, (2) w/o Output Validation retains state snapshots but disables the output validation mechanism, and (3) Full LLM-SSHH includes all components. The results reveal that the state snapshot serves as the foundational component of our framework. Removing this module causes catastrophic performance degradation, with the mean detection rate surging from 0.150 to 0.622. Specifically, the detection rate starts at 0.1 in 5-round interactions and rapidly escalates to 1.0 by rounds 45–50. This collapse occurs because LLM conversational memory cannot maintain long-term state consistency. As interaction rounds accumulate, the system exhibits increasing state loss and contradictions that make its behavior progressively less credible to attackers. In contrast, removing output validation leads to more moderate yet still significant performance degradation, with the mean detection rate rising to 0.322. This indicates that output validation provides critical additional safeguards on top of the state snapshot foundation. Notably, the performance of the full system substantially exceeds the simple additive contribution of individual components. These findings empirically confirm that state snapshots provide the essential temporal consistency required for multi-round interactions, while output validation addresses the long-tail distribution of specialized commands. Their synergistic combination is critical for sustaining deception effectiveness across extended interactive sessions.

5.3. Case Study

To illustrate the practical advantages of our state management architecture, we present a representative 50-round penetration testing scenario where an LLM-powered attacker performs systematic reconnaissance over an extended session.

Table 4. Case study of critical consistency failures in LLM-Basic compared to LLM-SSHH across a 50-round interaction session.

Round	Command	LLM-Basic	LLM-SSHH (Ours)
28	cat/etc/passwd (repeated)	Inconsistent user lists ✗	Fixed content from $\mathcal{F}$ ✓
37	ls/tmp	File not listed (state loss) ✗	File correctly shown ✓
43	uname -a (repeated)	Inconsistent kernel version ✗	Consistent output via $\mathcal{M}$ cache ✓

highlights three critical moments where LLM-Basic, a baseline approach relying solely on conversational memory without explicit state management, demonstrates detectable anomalies across three consistency dimensions. Round 28 reveals content consistency failure when repeated execution of cat/etc/passwd produces different user lists and formatting because the LLM regenerates content each time without fixed file storage mechanisms, immediately exposing the simulation nature. Round 37 demonstrates state persistence failure where ls/tmp fails to list a file created in earlier interactions due to context window limitations causing state loss, showing the system cannot maintain long-term operation history. Round 43 shows metadata consistency failure when repeated uname -a commands yield different kernel versions due to the non-deterministic nature of LLM generation without consistency guarantees. LLM-SSHH successfully maintains deception throughout all 50 interactions by leveraging its three-component state snapshot architecture $(\mathcal{F},\mathcal{C},\mathcal{M})$. Specifically, the file system component $\mathcal{F}$ stores fixed file content and returns identical results on repeated reads to ensure content consistency, explicitly tracks all file creation operations to address long-term state persistence, while the system metadata component $\mathcal{M}$ combined with consistency caching ensures identical outputs for repeated system information commands to maintain metadata consistency. These cases empirically validate that structured state management is essential across three critical dimensions where content fixation prevents regeneration randomness, state persistence overcomes context window limitations, and metadata consistency maintains system identity stability, all working synergistically to sustain long-term deception against sophisticated attackers during extended interactive sessions.

6. Conclusions

In this paper, to address the context window limitations and hallucinations inherent in LLM-based SSH honeypots, we propose LLM-SSHH, a novel framework that combines explicit state management with LLM generation capabilities. The framework maintains a persistent state snapshot $(\mathcal{F},\mathcal{C},\mathcal{M})$ as the authoritative ground truth for system state. It guides LLM response generation through state-driven prompts while rejecting hallucinated outputs that violate state constraints. Validated responses update the state snapshot, forming a closed loop that enables consistent state evolution throughout extended interactions. Experiments show that LLM-SSHH achieves a mean detection rate of 0.150, representing a 3–4 times reduction compared to existing methods, with zero detection within 30 interaction rounds. This provides a reliable solution for threat intelligence collection and network security operations. In future work, we will extend the evaluation to longer interaction sequences and adapt the framework to broader attack scenarios to further enhance its real-world applicability.