RDP — Remote Desktop

Purpose

Connect to a Windows machine's desktop, saved for reuse.

How to do it

1. 1Click RDP in the toolbar, then + Add RDP Host .
2. 2Fill in Hostname/IP , Port (3389 default), a Display name , Username (plain, DOMAIN\user , or user@domain.com ), and optionally Domain (for NLA).
3. 3Enter the Password or leave it blank to be prompted at connect time; check Save password to store it in the OS keychain.
4. 4Pick a Resolution : Auto-fit window (matches the MangoSSH window size, crispest), a fixed preset (1280×800 up to 2560×1440), or Fullscreen.
5. 5Optionally assign a Group for organization and credential inheritance (same Groups system as SSH, scoped independently per protocol).
6. 6Click Add & Connect — unlike SSH's "Add host" button, this one both saves the host AND opens the session immediately in the same click; there's no separate save-only step.

How to verify

1. 1Click Add & Connect and expect the remote desktop to start rendering inside the MangoSSH window within a few seconds, with no extra click needed to "connect" afterward.
2. 2Move the mouse and type over the session; expect the remote cursor to track your mouse and keystrokes to appear in whatever remote window has focus.
3. 3With Auto-fit resolution selected, resize the MangoSSH window (drag an edge/corner).
   • Expect the remote desktop's rendered size to resize along with it, with no black bars or scrollbars appearing.
4. 4Disconnect, then reopen the same host from the sidebar — this second connect should also be a single click on the sidebar entry, same as SSH from this point on.

Troubleshooting

• Black screen after connecting — often an NLA (Network Level Authentication) mismatch; confirm the Domain field matches what the server expects, or try leaving it blank for a local/Microsoft account.
• "Unknown server certificate" prompt on first connect — shows the exact fingerprint and two buttons, "No, cancel" and "Yes, trust & connect"; expected the first time, but treat it exactly like SSH's host-key trust prompt (see the SSH chapter) — verify out of band if this appears on a host you've connected to before without a prompt.
• Connects but keyboard input is wrong (wrong layout/symbols) — a keyboard-layout mismatch between your machine and the remote session; check the remote Windows machine's own configured input language.

Purpose

• Reach an RDP host that isn't directly exposed on the network at all — only reachable through an organization's RD Gateway server over HTTPS/WebSocket (MS-TSGU), the standard pattern for publishing internal desktops without opening RDP's raw port to the internet.
• MS-TSGU RDP You embedded RDP canvas RD Gateway HTTPS / WebSocket Windows host no direct exposure The gateway and the SSH-tunnel option (below) are independent — you can use either, both, or neither, depending on how the target network is set up.

How to do it

1. 1On the host's Add/Edit form, fill in RD Gateway : the gateway address (e.g. gateway.example.com:443 ), and a separate gateway username/password (HTTP Basic auth) — stored separately in the OS keystore from the host's own RDP password.
2. 2Leave it blank for a direct connection with no gateway.

How to verify

1. 1Fill in the gateway address and gateway username/password, leave the main Username/Password fields set to the target machine's own login, and click Add & Connect.
2. 2Expect the session to establish successfully even from a network position that CANNOT reach the target host directly (e.g. outside the corporate VPN) — that's the real proof the gateway hop is doing the work, not a direct connection that happened to succeed on its own.
3. 3As a negative control: temporarily clear the gateway password (leave the gateway host set) and reconnect.
   • Expect a gateway-specific authentication failure, distinct from a normal "wrong Windows password" error — confirming the two credentials are genuinely separate.

Troubleshooting

• Gateway authentication fails — this is a separate credential from the RDP host password; double check the gateway username/password specifically, not the target machine's login.
• Works without the gateway configured but you need it for off-network access — confirm you actually need it: if the target is reachable directly (e.g. on VPN), the gateway fields can stay blank.

Purpose

Reach an RDP host that's only reachable from inside a network you can SSH into — route the RDP session through an existing saved SSH connection as a bastion, without needing a dedicated RD Gateway server.

How to do it

1. 1On the host's Add/Edit form, set Tunnel via SSH host to any already-saved SSH host that can reach this RDP target's network.
2. 2MangoSSH opens that SSH session, forwards a local port through it to the RDP host's port on the far side, then points the embedded RDP client at that local forwarded port — all automatically.

How to verify

1. 1Set "Tunnel via SSH host" to a saved SSH bastion, connect, and expect the RDP session to open normally with no extra prompts.
2. 2While the RDP session is open, check the SSH sidebar and confirm the referenced bastion host's status dot is ALSO green — this is what proves the tunnel is really riding on a live SSH connection, not a coincidental direct path.
3. 3Disconnect the SSH bastion host specifically (not the RDP session).
   • Expect the RDP session to drop shortly after — this is expected and confirms the dependency; it's not a bug in the RDP session itself.

Troubleshooting

• RDP session drops when you close the SSH session — expected; the SSH connection is the tunnel's transport.
  • Reconnect the SSH host first, or rely on its own auto-reconnect setting if configured.
• "Connection refused" through the tunnel — the RDP port isn't actually reachable from the SSH bastion's own network position; confirm the bastion itself can reach the target's port 3389 (or whatever port you set).

Purpose

Make a local folder show up as an extra drive inside the remote Windows session, for moving files in and out without a separate SFTP/copy step.

How to do it

1. 1On the host's Add/Edit form, under Shared folders , click Add shared folder and pick a local folder via the file dialog.
2. 2Repeat for each folder you want available; each becomes its own redirected drive inside the session.

How to verify

1. 1Click "Add shared folder", pick a local test folder (e.g. your Desktop), connect, then open "This PC" inside the remote Windows session.
   • Expect a new drive letter labeled with your folder's name to appear alongside the C: drive.
2. 2Inside the remote session, create a new text file on that redirected drive, type a recognizable string into it, and save.
   • Switch to your local machine and open the SAME folder — expect the file to already be there with the same content, no manual sync step.
3. 3Reverse it: create a file locally in that folder, then refresh (F5) the remote Explorer window on the redirected drive — expect the new file to appear there too.

Troubleshooting

• Drive doesn't appear in "This PC" — confirm drive redirection wasn't disabled by the target machine's own Group Policy (some hardened environments block RDP drive redirection organization-wide, independent of anything MangoSSH does).
• Files write locally but don't show remotely (or vice versa) — refresh the remote Explorer window; redirected-drive contents don't always auto-refresh on change.

Purpose

Use a physical smartcard reader for in-session authentication (e.g. a CAC-gated internal app), or print from the remote session to a local PDF, both without any extra software inside the remote machine.

How to do it

1. 1Check Smartcard redirection to make a locally-attached smartcard reader available inside the session — useful for a remote app that itself requires a smartcard login or signing step.
2. 2Check Printer redirection to make a virtual printer available inside the session — anything printed there saves as a PDF on your local machine, no physical printer or driver installation needed.

How to verify

1. 1Smartcard : insert your card into the local reader BEFORE connecting, check Smartcard redirection, connect, then open a smartcard-aware app inside the session (e.g. Windows' own "certutil -scinfo" from a command prompt, or a PIV-gated internal tool).
   • Expect the card to be listed there exactly as it would be if you were sitting at that machine physically.
2. 2Printer : check Printer redirection, connect, open any document (e.g. Notepad) inside the session, and print it.
   • Expect no physical printer dialog — instead, a PDF should appear in your LOCAL machine's default downloads/save location within a few seconds of printing.

Troubleshooting

• Smartcard not visible inside the session — confirm the reader is recognized locally first (check your own OS's smartcard/PIV status) before assuming the redirection itself is broken.
• Printed PDF never appears — check your OS's default "Save" download location; the PDF is written there, not to a specific folder inside MangoSSH.

Purpose

• Span a remote session across every physical monitor detected on your local machine, for a true multi-monitor remote desktop experience.
• Marked experimental in the UI deliberately — multi-monitor RDP depends on both an initial display-topology negotiation and a live display-control channel, which is newer, less-traveled territory than the rest of the RDP feature set.

How to do it

Check Multi-monitor on the host's Add/Edit form before connecting.

How to verify

1. 1On a machine with 2 or more physical monitors, check Multi-monitor before connecting.
2. 2Connect and expect the session to span across your monitors matching your desktop's actual arrangement (left monitor content on the left, etc.) — not just mirrored on one screen or confined to whichever monitor MangoSSH's own window happened to be on.
3. 3Move the mouse across the boundary between two monitors during the session and confirm the cursor moves continuously, the way it would moving between two monitors locally.

Troubleshooting

• Session only shows on one monitor — given the experimental status, fall back to single-monitor (uncheck the option) if it doesn't behave correctly on your setup, and treat any inconsistency as expected for now rather than a configuration mistake on your part.

Purpose

Copy text between your local machine and the remote Windows session in either direction, the way you'd expect any remote-desktop tool to behave.

How to do it

1. 1Nothing to configure — clipboard redirection is always active for embedded RDP sessions.
2. 2Copy text locally, switch focus to the RDP session window, and paste — or copy inside the remote session and paste locally.

How to verify

1. 1On your local machine, select and copy (Ctrl+C) a distinctive piece of text (e.g. "clipboard-test-123").
   • Click into the RDP session window, open Notepad remotely, and paste (Ctrl+V).
   • Expect "clipboard-test-123" to appear exactly.
2. 2Reverse it: type a different distinctive string inside the remote Notepad, select and copy it there, click back onto your local desktop, and paste into a local text editor.
   • Expect the same round-trip to work in this direction too.

Troubleshooting

• Paste doesn't pick up what you just copied remotely — clipboard sync is triggered by focus changes; click once inside the MangoSSH window (giving it focus) before pasting locally.