SEGGER emSSH: Secure Remote Management for Indian Industrial Gateways on Cortex-M

Indian industrial gateway OEMs shipping product to customer sites, solar farms in Gujarat and Rajasthan, factory floors in Pune and Chennai, freight containers on Indian Railways routes, street-light controllers in Hyderabad’s smart-city districts, run into the same operational problem after the first 1,000 units are deployed: the OEM’s support team cannot physically reach every device every time something needs to change. The traditional vendor answers, a USB config tool that requires a technician on-site, an HTTP web UI that works for a single browser session but not for automated fleet operations, or a proprietary cloud agent that the customer’s security team refuses to allow on their private network, all fail at scale. The protocol the Linux server world solved this with twenty years ago is SSH, and the equivalent for a Cortex-M industrial gateway is SEGGER emSSH. This post walks through why SSH belongs on a microcontroller, what emSSH actually provides, the security posture Indian teams should run it with, and the deployment patterns that come up most often. GSAS Micro Systems is the authorized Indian engineering partner for SEGGER Microcontroller GmbH, and we support emSSH licensing, silicon bring-up, fleet-automation integration, and Flasher Secure per-device key provisioning from our offices across India.

Why SSH on a microcontroller

The argument for SSH on an embedded gateway is operational, not technical. The question is not “can the gateway host a shell”, in most cases it should not, but rather “can the OEM’s support team manage the deployed fleet using the same tooling they already use for Linux servers, without dispatching a technician every time a customer reports a problem?”

The answer the Linux ecosystem settled on is SSH, and every mature Indian fleet-management team already has:

• OpenSSH, WinSCP, and Putty on the NOC engineer’s laptop and on the central management server
• Ansible playbooks, Salt pillars, or custom Python scripts that automate “connect, run diagnostic, pull log, push config, disconnect” across thousands of hosts in parallel
• SSH-certificate-based user authentication with audit logging for compliance

Adding an emSSH-enabled gateway to that fleet is a zero-cost extension, the same tools, the same scripts, the same audit pipeline. The alternative, building a proprietary cloud agent and a proprietary command protocol on top of MQTT or HTTP, is months of engineering work for a strictly worse operational experience.

The comparison to emWeb, SEGGER’s embedded HTTP server, covered in the emWeb embedded HTTP server post, is worth making explicitly. emWeb is the right choice when the management interface is a human sitting at a browser, interactively configuring one device. emSSH is the right choice when the interface is a script running in parallel against 10,000 devices, or a NOC engineer running ssh gateway-42 "show fault-log" from a terminal. Most Indian industrial gateway products need both, and the two libraries coexist cleanly in the same firmware build.

What emSSH actually provides

emSSH is SEGGER’s commercial embedded SSH server library. The capability list that matters for procurement and integration:

• SSH protocol version 2. Full SSH-2 with the standard cipher suites, AES-128 and AES-256 for transport encryption, HMAC-SHA-256 for message authentication, ECDH key exchange, and ECDSA or RSA host keys. Protocol version 1 is not supported.
• Public-key user authentication. RSA and ECDSA user keys are both supported. Fleet-management deployments typically use ECDSA P-256 because the public-key blob is small enough to fit cleanly in an authorized-keys file the firmware carries in flash.
• Password authentication is supported for environments that genuinely need it, though we strongly recommend public-key-only for any production gateway exposed to a hostile network.
• Channel multiplexing. Multiple parallel sessions on a single TCP connection, one NOC engineer can open a shell session, push a file over SCP, and pull a log file over SFTP without reauthenticating three times.
• SCP and SFTP file transfer: channel-level subsystems that let an Ansible playbook push a configuration file or pull a diagnostic log with standard Linux-server tooling.
• Runs on top of emNet and emCrypt. emNet provides the TCP transport; emCrypt provides the AES, SHA, and ECC primitives. One vendor, one support contract, one bring-up per silicon family.
• Royalty-free commercial licence: per-product licensing with no per-unit royalties.

Security posture: how Indian teams should run emSSH in production

emSSH is a correctly-implemented SSH server library. The security of the deployed fleet depends on how the Indian product team configures it, not just on the library’s code quality. The posture we recommend for every production Indian industrial gateway:

• Public-key-only authentication. Password authentication disabled entirely on any device exposed to a network that is not strictly under the OEM’s physical control. The authorized-keys list is the list of NOC engineers and fleet-automation service accounts authorized to manage the device; it is compiled into the firmware and updated via a signed OTA when the authorized-key list changes.
• Per-device host keys provisioned at manufacturing. Each gateway has a unique SSH host key, injected at the factory via Flasher Secure alongside the TLS device certificates. Shared host keys across a fleet are a critical security failure, the Flasher Secure encrypted-firmware post covers the factory-side mechanics.
• Restricted command set, not a POSIX shell. emSSH on an embedded gateway should never expose a full shell. The user session connects to a command-dispatch function the product team writes, a state machine that accepts defined commands (show status, show fault-log, set config, reboot, firmware-update) and rejects anything else. The analogy is a Cisco IOS CLI, not a Bash shell.
• Audit logging of every session and every command. Who connected, from what source IP, when, which authorized public key authenticated, and every command run. Compliance-driven customers, medical-adjacent gateways under IEC 62304, industrial-automation under IEC 62443, require this explicitly.
• SSH port not exposed to the public internet. The gateway listens on the customer’s private network, reachable only from the OEM’s VPN or the customer’s jump host. Exposing port 22 on a fleet of microcontrollers is a security failure no library can compensate for.
• Connection cap. emSSH can be configured with a maximum concurrent-session count, 2 or 4 is typical, protecting the device from a broken script that opens a thousand connections.

Running emSSH with this posture is the difference between a defensible remote-management story and a CVE waiting to happen.

Indian industrial gateway deployment patterns

The patterns that come up most often in Indian industrial gateway projects:

Bengaluru solar-farm O&M: thousands of inverter gateways across western and southern India

An Indian solar-farm operations-and-maintenance company manages thousands of inverter gateway modules deployed across solar plants in Gujarat, Rajasthan, Karnataka, and Tamil Nadu. The central NOC in Bengaluru needs to push firmware patches, pull diagnostic logs when an inverter reports a fault, and run scripted health checks across the entire fleet every 24 hours. emSSH on each gateway lets the NOC’s existing Ansible playbooks run against the deployed fleet identically to the way they run against the Linux servers in the data centre. When a new inverter model joins the fleet, the NOC team updates its inventory and the same playbooks work against the new devices from day one.

Pune industrial automation: CAN-to-Ethernet gateways on customer factory floors

Scenarios in this article are illustrative, common patterns Indian engineering teams encounter, not specific named customers.

A typical Pune-area industrial automation OEM builds CAN-to-Ethernet gateway products that sit between legacy factory-floor equipment and the customer’s MES network. The customer’s own maintenance team is the primary operator, and they already manage hundreds of Linux servers with SSH and WinSCP. emSSH on the gateway lets them manage the OEM’s product with exactly the same tooling, no proprietary config utility, no vendor-specific protocol. The sales team has found this is a tangible differentiator against competing gateway vendors whose products require a Windows-only config tool.

Chennai shipping and freight: remote firmware updates on container telematics modules

A typical Chennai-area-based telematics OEM deploys IoT modules on freight containers moving on Indian Railways routes. When a container sits in a rail yard for 48 hours between cargo movements, the NOC team opens an SSH session to the module over its cellular modem’s management interface, pulls the last 72 hours of GPS and shock-sensor logs for diagnostic review, and pushes a firmware update if the module needs one. Dispatching a technician to a rail yard is not a viable option at the deployed fleet size; emSSH is the mechanism that keeps the deployment operationally manageable.

Hyderabad smart-city sensors: fleet automation on street-light controllers

A typical Hyderabad-area smart-city project deploys street-light controller modules on thousands of city streetlights. The fleet automation platform runs as a set of Python scripts that connect over SSH, pull the day’s power-consumption data, adjust brightness schedules in response to civic-calendar updates, and push firmware as needed. emSSH is the interface these scripts talk to; the alternative, a custom cloud agent, would require the city IT team to open outbound connections from every streetlight to a central cloud endpoint, which their security policy does not allow.

emSSH versus the alternatives

The library-selection conversation for an embedded SSH server lands on a short list:

• Dropbear. The small-footprint open-source SSH server widely used on embedded Linux. Dropbear is a competent library, but it targets an embedded Linux host, file system, process model, /dev/urandom, and Linux syscalls. Porting it to a bare-metal or RTOS-hosted Cortex-M is a non-trivial project.
• libssh and wolfSSH. Two commercial-grade SSH library options. wolfSSH is a direct commercial competitor; libssh is open source with a commercial support option. The selection between these and emSSH usually comes down to the rest of the stack: an Indian team already using emNet, emCrypt, embOS, and emFile gets a one-vendor contract and a single support line by choosing emSSH. A team mixing vendors does not get that benefit.
• Rolling your own. SSH is a complex protocol with a long history of subtle security bugs in third-party implementations. Do not implement it from scratch for a commercial product.

emSSH is the commercial choice that fits cleanly into the SEGGER middleware stack. It is not the only credible option, but it is the one Indian teams pick when they are already buying the rest of the SEGGER stack and want one contract instead of five.

Further reading

• SEGGER emSSH product page at segger.com
• SEGGER emNet product page at segger.com
• SEGGER emSSH at GSAS
• SEGGER emNet at GSAS
• SEGGER emCrypt at GSAS
• SEGGER embOS at GSAS
• SEGGER emWeb embedded HTTP server for Indian industrial gateway dashboards
• SEGGER emSecure-RSA and emSecure-ECDSA for Indian secure boot on Cortex-M
• SEGGER Flasher Secure for encrypted firmware delivery to Indian EMS
• SEGGER at GSAS

Why GSAS for the Indian rollout

Adding an SSH server to an industrial gateway is not the kind of decision an Indian product team reverses easily after launch, the deployed fleet’s remote-management story is the hardest thing to change once the first few thousand units are in the field. GSAS Micro Systems is the authorized Indian engineering partner for SEGGER Microcontroller GmbH, and we support emSSH end-to-end for Indian industrial gateway OEMs: commercial licensing in INR, silicon bring-up on STM32, i.MX RT, nRF52/nRF53, and Renesas RA, restricted-shell design for the command-dispatch layer, per-device host-key provisioning via Flasher Secure at the Indian CM, and fleet-automation integration with Ansible, Salt, or custom NOC tooling. Teams across Bengaluru, Chennai, Hyderabad, Delhi NCR, Mumbai, and Pune reach the GSAS engineering desk for emSSH architecture reviews, restricted-shell design workshops, and commercial proposals. When your deployed fleet grows from 1,000 units to 50,000 and the central operations team needs to manage all of them with the same tooling they already run, the right answer is an embedded SSH server that their existing playbooks talk to, not a proprietary agent the customer’s security team will not approve.