markusher

RDM 2026.3.16.0 (Windows), WebDAV session entry against a small embedded WebDAV server (Pi1MHz firmware, HTTP, no authentication).

The Home directory field is mandatory, so for the server’s root I set it to /. RDM then sends PROPFIND // HTTP/1.1 (Depth 1, User-Agent DevolutionsWebdavClient, allprop body; captured with a logging relay in between). The server answers 207 Multi-Status with valid absolute-path hrefs; the display names are the full names:

<D:href>/</D:href>        <D:displayname>/</D:displayname>
<D:href>/Backup/</D:href> <D:displayname>Backup</D:displayname>
<D:href>/tdisc/</D:href>  <D:displayname>tdisc</D:displayname>

RDM lists every item with its first character missing: ackup, disc, emos ... (all 27 folders and files). It looks as if RDM removes the length of its own request path (2 characters, //) from each href, instead of resolving the href against the request URL (RFC 4918 lets the server use any href form for the resource; RFC 3986 section 5 for the resolution) or using displayname.

Controls: Windows Explorer (WebClient) lists the same server correctly. With curl, PROPFIND on / and on // return identical hrefs, so the server is consistent; only the request path differs. An independent server, rclone 1.75.2 (rclone serve webdav), answers // the same way: 207 with the same /-prefixed hrefs as for /. RDM shows the same shortened names against that server too.

Could you please (1) resolve each href against the request URL (or use displayname) when building the list, and (2) accept / as the home directory without producing // in the request? An empty home directory would also do, but the field cannot be left empty.

kind regards

Mark

Thanks, Maxim - confirmed. With RDM 2026.3.16.0 the Telnet session works against ULTRIX 4.5, on both a real MicroVAX II and a SIMH-emulated one, including autologin. I’ve moved my VAX entries from PuTTY to native RDM Telnet entries.

I also checked the session on the wire: neither RDM nor the ULTRIX telnetd negotiates BINARY any more, so the server stays in NVT mode and CR / CR LF are handled as expected.

Kind regards and many thanks.

Mark Usher

Hi Jonathan,

Thanks, the PuTTY test was the right call, and it clears RDM.

I repeated the test from the same PC against the same Keenetic router (now KeeneticOS 5.01.C.7.0-4), first with PuTTY 0.85 and then with Windows OpenSSH 9.5p2. Both produce exactly the same "sftp denied" message as RDM:

11:34:30 dropbear: Child connection from 192.168.0.10:64326 <- PuTTY

11:34:40 ndm: Core::Authenticator: user "user" authenticated, realm "Keenetic Peak", tag "cli".

11:34:40 dropbear: Password authentication succeeded for 'user'@cli from 192.168.0.10:64326

11:34:40 ndm: Core::Authenticator: access to "sftp" denied for user "user".

11:34:42 ndm: Core::Session: client disconnected.

11:34:42 ndm: Core::Authenticator: "user" logged in, SSH authenticated.

11:34:51 dropbear: Exit (user) from <192.168.0.10:64326>: Exited normally

11:35:09 dropbear: Child connection from 192.168.0.10:52602 <- Windows OpenSSH

11:35:22 ndm: Core::Authenticator: access to "sftp" denied for user "user".

11:35:23 ndm: Core::Session: client disconnected.

11:35:23 ndm: Core::Authenticator: "user" logged in, SSH authenticated.

11:35:31 dropbear: Exit (user) from <192.168.0.10:52602>: Disconnect received

The source port is the same throughout each session, so this isn't a separate connection. I misread the log in my first post. The "sftp denied" and "client disconnected" lines are KeeneticOS's own internal permission check during every SSH login, regardless of the client. They're not caused by an SFTP request from RDM.

On your version question: the router logs show the same message from RDM 2026.3.8, 3.10 and 3.12, and my logs don't go back far enough to cover 2026.2.

Sorry for the false alarm. Please close this as not an RDM issue. I'll take it up with Keenetic.

Thanks,

Mark

RDM 2026.3.10.0 64-bit on Windows is making a separate SFTP connection whenever I open an SSH Shell session, even though SFTP is completely disabled for the entry.

The target is a Keenetic router running KeeneticOS 5.01.C.6.0-1. Its SSH server provides the CLI but does not provide SFTP.

RDM SSH Shell settings:

• Automatically open the file transfer tab: OFF

• Show files in tree view: OFF

• Show local files: OFF

• All other SFTP options: OFF

• SFTP toolbar button: OFF

The exported entry XML also confirms:

<ConnectionType>SSHShell</ConnectionType>

<ShowFilesInTreeView>false</ShowFilesInTreeView>

<ShowLocalFiles>false</ShowLocalFiles>There are no SFTP-specific properties in the entry.

I also tested:

• enabling/disabling "Automatically open the file transfer tab" and reconnecting;

• Open → Open (ignore specific settings);

• a clean/global Sessions configuration with no SFTP settings.

The behaviour is unchanged.

Evidence

The normal SSH connection works correctly and reaches the Keenetic CLI:

User authenticated successfully using password method

Sending session channel open request

Received channel open confirmation

Sending pty request

Received channel success

Sending shell request

Received channel success

...

KeeneticOS version 5.01.C.6.0-1

(config)>

The ProtocolsSharp SSH log contains no SFTP subsystem request.

However, the Keenetic logs show a separate SSH connection immediately before the normal SSH session:

Child connection from 192.168.0.10:60193

Password authentication succeeded for 'user'@cli from 192.168.0.10:60193

Core::Authenticator: access to "sftp" denied for user "user".

Core::Session: client disconnected.

The normal SSH CLI connection then follows and works correctly.

So the issue appears to be that RDM is initialising an SFTP connection independently of the SSH Shell connection, despite SFTP being disabled.

Could you please confirm whether this is a known issue/regression in RDM 2026.3 and advise how to prevent the SFTP connection from being attempted?

<?xml version="1.0" encoding="utf-8"?>

<RDMExport>

<Connections>

<Connection>

<AppVersion>2026.3</AppVersion>

<ConnectionType>SSHShell</ConnectionType>

<ID>0000000-00000-0000-0000-000000000000</ID>

<Name>test</Name>

<OpenEmbedded>true</OpenEmbedded>

<Terminal>

<Host>192.168.0.1</Host>

<ShowFilesInTreeView>false</ShowFilesInTreeView>

<ShowLocalFiles>false</ShowLocalFiles>

</Terminal>

</Connection>

</Connections>

<DatabaseID>0000000-00000-0000-0000-000000000000</DatabaseID>

<Version>2</Version>

</RDMExport>

Product: Remote Desktop Manager (Windows), version 2026.3.8.0 64 bit (PreJIT)

Session type: Telnet, embedded (tabbed)

Server: DEC Ultrix 4.5 (VAX) telnetd

Problem Login through the RDM Telnet session always fails, or hangs, on Ultrix telnetd. The same server works fine from PuTTY in Telnet mode.

What a packet capture shows

- RDM proposes IAC WILL BINARY and IAC DO BINARY, and the server accepts both.

- With "Return key sends a new line instead of a carriage return" ticked, Enter is sent as CR LF (0d 0a). With it unticked, Enter is sent as a bare CR (0d).

- A bare CR leaves login stuck after the username: no Password: prompt.

- CR LF reaches the Password: prompt, but login then reports "Login incorrect" with the correct password.

Analysis

Once BINARY is active, BSD-derived telnetd (including Ultrix) turns off CR/LF translation. The CR in CR LF then stays inside the line, so login receives "username<CR>" and "password<CR>" instead of the clean strings. The server also stops adding CRs on output. This is consistent with what the capture shows. I have not found an option to turn off BINARY, or to send LF only for Enter. Remapping Enter to another CTRL-J in the Keyboard tab had no effect on the bytes sent.

Requests

1. A per-entry option to disable telnet BINARY negotiation (or make it opt-in).

2. Or an Enter-key option to send LF only, or CR NUL, that is honoured for keyboard input and for the autologin (User/Password prompt string) feature.

3. Ensure the Keyboard tab key map is applied to Enter in Telnet sessions.