Home
|
FAQ
|
Feedback
|
Licence
|
Updates
|
Mirrors
|
Keys
|
Links
|
Team
Download:
Stable
·
Snapshot
|
Docs
|
Privacy
|
Changes
|
Wishlist
The SFTP draft protocol specs define an extension request called
"home-directory", in which the client sends a username,
and the server sends back the path name of that user's home directory.
Or the client can send the empty string, and the server sends the path
name of the logged-in user's home directory.
This makes it possible for PSFTP and PSCP to support the Unix-style
~ syntax for specifying a user's home directory. All of
the following syntaxes could do something useful, and currently don't:
C:\Dir>pscp hostname:~username/file.txt . C:\Dir>pscp file.txt hostname:~username/subdir C:\Dir>pscp -ls hostname:~username C:\Dir>psftp hostname psftp> cd ~/src/thingy
The obvious strategy for this is for PSCP and PSFTP to notice
a ~ at the start of the command line, and if they find
one, send a "home-directory" query to the server, with an
empty string for just ~ by itself or a username
for ~username, and substitute the directory that comes
back (if any). For extra points, we could remember whether the server
advertised support for this extension in
its SSH_FXP_VERSION message, and not bother even trying
if it didn't.
But I've labelled this as difficulty "tricky" because it's not that
simple. Unfortunately, OpenSSH's SFTP server had a bug in versions up
to 9.7 in which the reply to the "home-directory" query
was always your home directory, even if you requested
somebody else's!
There is a workaround: OpenSSH also supports a different extension
request called "expand-path@openssh.com" which expands a
whole pathname in the style of SSH_FXP_REALPATH, but also
handling a leading ~ or ~username. So we
could add a bug compatibility flag, detect versions of OpenSSH which
we expect to lie about "home-directory", and for those
versions, send "expand-path@openssh.com" with
argument "~username" in place
of "home-directory" with argument "username".
Strictly speaking, this is a layer violation and not properly
reliable, because there's no guarantee that the SFTP server matches
the SSH server, and we only receive a version-string banner from the
latter. If someone configured their OpenSSH server so that
the "sftp" subsystem request invoked someone else's SFTP
server, or conversely configured another server to run
OpenSSH's sftp-server from a buggy version of OpenSSH,
then this strategy wouldn't detect it. But I don't think there's
anything we can do about that except document the bug flag and make
sure users can turn it on manually, by also having command-line
control over it.
(Another strategy would be to
use "expand-path@openssh.com" to expand the whole
pathname in place of the SSH_FXP_REALPATH we were doing
anyway, but I don't like that answer, because I want to
substitute ~ in some situations where
there wasn't an SSH_FXP_REALPATH we were doing
anyway, and also, "home-directory" has some chance of
becoming standard so that other SFTP servers support it too. I'd
rather base my strategy on "home-directory", and
use "expand-path@openssh.com" only as a workaround for
that bug.)