Implement key-based SFTP authentication via file system provider, without specifying user:password@host:port/path/to/file, but just user@host:port/path/to/file.
Motivation
I'm trying to extend Apple's pkl-lang project by allowing to load remote resources via SFTP. I'm doing this by adding mina-ssd to the project.
I was able to achieve this by manually isntantiating an SSH client and forwarding the remote requests; however, pal-lang has an already implemented feature that allows to use existing file system providers. As Mina has a filesystem provider, it would integrate really beautifully. However, I don't think it is reasonable to use passwords as variables or plain strings in the .pkl configuration files, so using key-based authentication is preferable.
Alternatives considered
I tried to look into Mina's codebase, but it seems that the user string is validated against the presence of the : character. If the number of parts are different Thant 2, the user is considered invalid and an error is thrown.
Description
Implement key-based SFTP authentication via file system provider, without specifying
user:password@host:port/path/to/file, but justuser@host:port/path/to/file.Motivation
I'm trying to extend Apple's pkl-lang project by allowing to load remote resources via SFTP. I'm doing this by adding mina-ssd to the project.
I was able to achieve this by manually isntantiating an SSH client and forwarding the remote requests; however, pal-lang has an already implemented feature that allows to use existing file system providers. As Mina has a filesystem provider, it would integrate really beautifully. However, I don't think it is reasonable to use passwords as variables or plain strings in the
.pklconfiguration files, so using key-based authentication is preferable.Alternatives considered
I tried to look into Mina's codebase, but it seems that the user string is validated against the presence of the
:character. If the number of parts are different Thant2, the user is considered invalid and an error is thrown.Additional context
No response