Secure Real-Time Integration for Engineering Systems Using SSH Key-Based Authentication
Designing reliable real-time integrations in mixed-tool engineering environments—without requiring platform upgrades or workflow changes.
Hi, I’m Fayaz Khan — a PLM Solution Architect with deep hands-on experience in 3DEXPERIENCE, real-world integrations, and enterprise system behavior.
I work at the intersection of engineering, security, and systems thinking, navigating between PLM platforms, cloud infrastructure, APIs, and practical business needs. I prefer digging into why something works (or breaks), rather than just how to configure it.
My writing is an attempt to document the often-overlooked details — the silent bugs, the edge cases, the security gaps — and sometimes, the mental models that help me make sense of it all.
Modernizing PLM integrations without disrupting existing engineering workflows
Engineering ecosystems evolve unevenly. Some systems move toward APIs, event-driven architectures, and cloud-based services, while others continue to rely on proven utilities, flat file exchanges, and command-driven automation. Real-world PLM environments often sit at the center of this diversity, needing to coordinate with multiple upstream and downstream tools that operate at different levels of maturity.
This article describes how a secure and reliable SSH-based integration architecture can bring real-time behavior into such environments without requiring a complete modernization of all participating systems.
Why This Integration Approach Was Chosen
Modern platforms increasingly offer REST APIs, event-driven frameworks, and synchronous integration flows. However, large enterprises must balance newer capabilities with the operational landscape that teams are already tuned to. Many engineering workflows depend on long-established utilities and well-tested file-driven processes that downstream systems are comfortable consuming.
In such cases, the goal is not to replace working mechanisms simply because a newer option exists. Instead, the architectural focus is on improving security, reliability, and responsiveness while respecting organizational priorities, system dependencies, and the stability that teams require.
The SSH-based model became the natural enhancement. It allowed existing file-based workflows to remain intact, while adding secure authentication, controlled access, and real-time remote execution—delivering modern behavior without disrupting established processes.
Why SSH Fits PLM & Engineering Integrations
SSH provides secure identity verification using cryptographic keys instead of passwords. For automated PLM integrations, this matters greatly:
No secrets travel over the network
No passwords appear in logs or scripts
Authentication becomes programmable and machine-friendly
Identity can be tightly mapped to a specific user on the target system
Access restrictions can be applied at multiple layers for safety
In the integration flow, the PLM system generates flat files—BOM snapshots, design data, metadata exports, or any other engineering payload. A Java component bundled within the PLM environment then uses SSH to perform two tasks:
Transfer the flat files to the downstream server using SCP, and
Trigger a remote execution that processes those files.
This turns a traditionally batch-oriented system into a responsive, synchronous one.
How SSH Key Authentication Really Works
It’s common to misunderstand SSH authentication. The private key is never sent to the server. Instead, SSH uses a challenge–response mechanism:
The server sends a random challenge (nonce).
The client signs the challenge using its private key.
The server validates the signature using the public key stored in the user’s profile.
If they match, authentication succeeds.
The result is identity verification without exposing any credentials.
Why Java Libraries Require Explicit Key Loading
Native SSH clients on Linux automatically read ~/.ssh keys.
Java does not.
A JVM sandbox cannot assume OS-level trust. It requires explicit instructions:
JSch jsch = new JSch();
jsch.addIdentity("/path/to/private/key", "passphrase");
This ensures predictable, controlled authentication in code—perfect for PLM integrations that run non-interactively.
Mapping SSH Keys to a Specific Windows User
When the PLM system connects to the downstream Windows server, it authenticates as a specific user. Windows OpenSSH determines identity by reading:
C:\Users\<username>\.ssh\authorized_keys
For example, if the integration uses the account integration.agent, the public key must be placed here:
C:\Users\integration.agent\.ssh\authorized_keys
The .ssh folder and authorized_keys file must be accessible only to that user and the system, ensuring both security and accountability.
This mapping provides clear traceability:
one key → one user → one integration identity.
Restricting Access to Critical Servers
Even with valid keys, SSH lets you apply strict guardrails.
These restrictions are embedded directly into authorized_keys.
Restrict by Source IP
from="192.168.1.50" ssh-ed25519 AAAAC3...
Only your PLM server can use the key.
Restrict by Forced Command
command="C:/scripts/run_job.ps1" ssh-ed25519 AAAAC3...
The key cannot open a shell—only run a specific script.
SSH Certificates for Higher Security
SSH certificates allow:
Expiry
Binding to specific hosts or users
Internal CA-based trust
Ideal for enterprise-grade rotation policies.
Server-Side Hardening
PasswordAuthentication no
PubkeyAuthentication yes
Eliminating passwords removes brute-force vectors entirely.
Firewall-Level Filtering
Even valid keys cannot connect unless network rules permit it.
This layered security ensures that your integration remains safe even if a key is leaked.
End-to-End PLM Integration Workflow Using SSH
Here’s how the real-time flow works in practice:
A user triggers an action inside the PLM dashboard.
The PLM platform generates the required flat files (CSV, XML, neutral metadata, CAD descriptors, etc.).
A Java component inside the PLM server uses SCP to transfer these files to the target machine.
Immediately afterwards, it invokes a remote process via SSH—triggering downstream automation.
Retry logic and connectivity safeguards built into the Java layer ensure resilience.
The combination creates an API-like real-time experience without needing full platform migrations.
Why This Architecture Works Well for Engineering Systems
This pattern respects both stability and modernization:
You keep established workflows that teams trust.
You add security and real-time responsiveness where it matters.
You avoid disruptive or costly redesigns.
You gain traceability and auditability with strong user mapping.
You modernize the integration pattern without replacing existing tools.
This is a pragmatic architecture that bridges legacy and modern platforms gracefully—ideal for PLM environments where reliability, auditability, and continuity are just as important as modern capabilities.
