BPM / BAW cannot open an SSH session by itself, but a service flow can run Java, and Java can run PowerShell remoting or SSH. Three practical designs:
1. Java integration + SSH library (JSch or Apache MINA sshd as a managed server file jar): the service flow calls a small Java class that opens the SSH connection and runs the command; on a Windows host run PowerShell through the OpenSSH server (powershell -Command ...).
// Java class packaged as a managed jar, called from a Java Integration in a service flow
public class RemoteShell {
public static String run(String host, String user, String password, String command) throws Exception {
JSch jsch = new JSch(); Session s = jsch.getSession(user, host, 22);
s.setPassword(password); s.setConfig("StrictHostKeyChecking", "no"); s.connect(15000);
ChannelExec ch = (ChannelExec) s.openChannel("exec"); ch.setCommand(command);
InputStream in = ch.getInputStream(); ch.connect();
String out = new String(in.readAllBytes(), "UTF-8"); ch.disconnect(); s.disconnect(); return out;
}
}// service flow script: tw.local.output = result of the Java integration "run"
// input mapping: host = tw.env.remoteHost, command = "powershell -NoProfile -Command Get-Service -Name Spooler | ConvertTo-Json"
2. Expose PowerShell as a REST end point on the host (Windows: a tiny Flask / .NET minimal API, or PowerShell Universal) and call it with the OOB REST external service from BAW - no Java, no credentials in BPM, and the host controls what may be executed. This is the option security teams usually prefer.
3. UCA + queue: the BPD sends a JMS / MQ message with the command request, an agent on the host consumes it and answers with a message that the BPD receives through a UCA - fully asynchronous and auditable.
Whatever you choose: store the credentials in a Server definition or an environment variable of the app (never in the script), restrict the commands to a fixed list on the host side, and put a timeout on the call (service flows block a thread while waiting).
References