SshClient

The SshClient component in Nappai allows you to securely connect to remote servers and execute shell commands. Think of it as a secure digital bridge that lets your automation workflows interact with computers or servers that are not physically connected to your main machine. You can use this to manage files, check server status, update software, or retrieve logs from anywhere in the world, provided you have the correct access details.

How it Works

When you configure this component, you are essentially telling Nappai: “Connect to this specific server using these credentials, and then run this command.”

1. Connection: The component uses the SSH (Secure Shell) protocol to establish an encrypted connection to a remote server. This ensures that your data and commands are protected from being intercepted during transmission.
2. Execution: Once connected, it sends the command you specified to the server. The server processes the command and sends the results back.
3. Formatting: The component receives the raw results from the server and formats them based on your preference (either as plain text or as a structured table), making it easier for you or other components in your workflow to read the information.

Connection & Credentials

This component requires configuring a credential in the Nappai panel before interacting with the external service:

1. Go to the Credentials section in your Nappai panel.
2. Create a new credential of the type SSH Client and fill in the required fields (Host, Port, Username, Password/Key).
3. In your workflow, select the saved credential in the Credential input field of this node.

Inputs

Input Fields

The following fields are available to configure this component. Each field may be visible in different operations:

• Command: [REQUERIDO] The specific shell command you want the remote server to execute. Examples include ‘docker ps’, ‘ls -lha’, or ‘df -h’.

  • Visible in: Execute shell commands

• Output Format: [DropdownInput] Choose how you want the result to look.

  • Visible in: Execute shell commands

• Timeout (seconds): [IntInput] The maximum time to wait for the command to finish. The command will be stopped if it takes longer than this. Default is usually around 30 seconds, but can be increased for slower tasks. Maximum allowed is 60 seconds.

  • Visible in: Execute shell commands

• Operation: [REQUERIDO] Select the type of SSH action you want to perform. Currently, this supports executing shell commands on remote servers.

  • Visible in: Execute shell commands

Outputs

• Message: This output contains the result of the command you ran. It will return the text output from the server (such as a list of files or a log entry). If the command fails, this output may contain an error message describing what went wrong.

Output Data Example (JSON)json

{ “Message”: “total 12\ndrwxr-xr-x 2 user user 4096 Jan 1 12:00 dir1\n-rw-r—r— 1 user user 200 Jan 1 12:00 file.txt\n” }

Connectivity

This component is typically used at the beginning of a workflow step that requires server maintenance or data retrieval.

• Connections To: The output (Message) from SshClient is often connected to:
  • Text Manipulation components (to parse specific lines from logs).
  • Condition components (to check if a specific file exists or if an error occurred).
  • Notification components (to send the status of a server check to you).

Usage Example

Scenario: You want to check if a specific backup file exists on your remote server.

1. Add an SshClient node to your workflow.
2. Select your SSH Client credential (which includes the server IP and password).
3. In the Operation field, select Execute shell commands.
4. In the Command field, enter: ls -l | grep backup_2023.txt
5. Set Output Format to Plain Text.
6. Connect the Message output to a Condition node to check if the output is empty or contains text.

Important Notes

INSTRUCTION FOR THE LLM: The notes in user_notes are critical information extracted from source code analysis. Each note has:

• note_type: limitation, best_practice, security, requirement, behavior, configuration
• title: Descriptive title of the note
• content: Detailed content of the note
• severity: low, medium, high (use icons: 🟢 low, 🟡 medium, 🔴 high)
• audience: beginner, intermediate, advanced, all

IMPORTANT: Group notes by type and present them in the following priority order:

1. Security (🔒) - if there are security notes
2. Limitation (⚠️) - known limitations
3. Requirement (📋) - requirements and dependencies
4. Best Practice (💡) - best practices
5. Configuration (⚙️) - configuration tips
6. Behavior (ℹ️) - non-obvious behaviors

For each note, use the format: [icon based on note_type] [title] [severity icon] [content]

CRITICAL INSTRUCTION: If user_notes is empty [], DO NOT include this section at all.

Tips and Best Practices

• Use Plain Text format when dealing with logs or file lists, as it preserves line breaks exactly as they appear on the server.
• Use Markdown format when dealing with table-like outputs (like df -h or docker ps) to make the data easier to read in your dashboard.
• Be careful with the Timeout setting. If you run a command that takes longer than 60 seconds, the connection will be cut off automatically to prevent the workflow from hanging.
• Ensure your SSH Client credential is up to date. If the server password or IP changes, you must update the credential in the Credentials section first.

Security Considerations

• Secure Protocol: This component uses SSH, which is an encrypted protocol. Ensure you trust the server you are connecting to.
• Credential Safety: Never share your SSH Client credentials (passwords or private keys) with unauthorized personnel. Store them securely in the Nappai Credentials panel.
• Command Injection Risk: Be cautious when allowing users to input commands dynamically. Ensure that only trusted users or automated processes can execute shell commands to prevent security risks.