server as not matching the glob that the client sent, log (at debug level)
the received pathname as well as the list of possible expected paths expanded
from the glob. bz2966
OpenBSD-Commit-ID: 0bd8db8a595334ca86bca8f36e23fc0395315765
OpenSSH and it shows - the function names are terrible.
Rename do_blah() to sftp_blah() to make them less so.
Completely mechanical except for sftp_stat() and sftp_lstat() which
change from returning a pointer to a static variable (error-prone) to
taking a pointer to a caller-provided receiver.
OpenBSD-Commit-ID: eb54d6a72d0bbba4d623e2175cf5cc4c75dc2ba4
communication with it's ssh sub-processes. We no longer need to reserve two
descriptors to ensure that we don't end up using fd 0-2 unexpectedly, that is
handled by sanitise_stdfd() in main(). Based on an original diff from djm@.
OK deraadt@ djm@
OpenBSD-Commit-ID: b80c372faac462471e955ddeab9480d668a2e48d
e555d5cad5 effectively increased the default copy buffer size for SFTP
transfers. This caused NetBSD 4.x to hang during the "copy local file to
remote file in place" scp.sh regression test.
This puts back the original 32KB copy buffer size until we can properly
figure out why.
lots of debugging assistance from dtucker@
control over some SFTP protocol knobs: the copy buffer length and
the number of inflight requests, both of which are used during
upload/download.
Previously these could be controlled in sftp(1) using the -b/-R options.
This makes them available in both SFTP protocol clients using the same
option character sequence.
ok dtucker@
OpenBSD-Commit-ID: 27502bffc589776f5da1f31df8cb51abe9a15f1c
default), better match scp/rcp's handling of globs that don't match the
globbed characters but do match literally (e.g. trying to transfer
"foo.[1]").
Previously scp(1) in SFTP mode would not match these pathnames but
legacy scp/rcp mode would.
Reported by Michael Yagliyan in bz3488; ok dtucker@
OpenBSD-Commit-ID: d8a3773f53015ba811fddba7473769a2fd343e11
early
previous behavious of unconditionally truncating the destination file
would cause "scp ~/foo localhost:" and "scp localhost:foo ~/" to
delete all the contents of their destination.
spotted by solene@ sthen@, also bz3431; ok dtucker@
OpenBSD-Commit-ID: ca39fdd39e0ec1466b9666f15cbcfddea6aaa179
scp in RCP mode.
> revision 1.106
> date: 2021/10/15 14:46:46; author: deraadt; state: Exp; lines: +13 -9; commitid: w5n9B2RE38tFfggl;
> openbsd 7.0 release shipped with the (hopefully last) scp that uses RCP
> protocol for copying. Let's get back to testing the SFTP protocol.
This will be put back once the OpenSSH release is done.
OpenBSD-Commit-ID: 0c725481a78210aceecff1537322c0b2df03e768
destination directory if it doesn't already exist to match olde-scp(1)
behaviour. noticed by deraadt@ ok markus@
OpenBSD-Commit-ID: cf44dfa231d4112f697c24ff39d7ecf2e6311407
O_CREAT, the 3rd (variadic) mode_t parameter is irrelevant. Many developers
in the past have passed mode_t (0, 044, 0644, or such), which might lead
future people to copy this broken idiom, and perhaps even believe this
parameter has some meaning or implication or application. Delete them all.
This comes out of a conversation where tb@ noticed that a strange (but
intentional) pledge behaviour is to always knock-out high-bits from mode_t on
a number of system calls as a safety factor, and his bewilderment that this
appeared to be happening against valid modes (at least visually), but no
sorry, they are all irrelevant junk. They could all be 0xdeafbeef. ok
millert
OpenBSD-Commit-ID: 503d11633497115688c0c6952686524f01f53121
openbsd 7.0 release shipped with the (hopefully last) scp that uses RCP
protocol for copying. Let's get back to testing the SFTP protocol.
OpenBSD-Commit-ID: 9eaa35d95fd547b78b0a043b3f518e135f151f30
release. We'll wait a little longer for people to pick up sftp-server(8) that
supports the extension that scp needs for ~user paths to continue working in
SFTP protocol mode. Discussed with deraadt@
OpenBSD-Commit-ID: f281f603a705fba317ff076e7b11bcf2df941871
protocol remains available via the -O flag.
Note that ~user/ prefixed paths in SFTP mode require a protocol extension
that was first shipped in OpenSSH 8.7.
ok deraadt, after baking in snaps for a while without incident
OpenBSD-Commit-ID: 23588976e28c281ff5988da0848cb821fec9213c
Now that the -3 option is enabled by default, flip the documentation
and error message logic from "requires -3" to "blocked by -R".
ok djm@
OpenBSD-Commit-ID: a872592118444fb3acda5267b2a8c3d4c4252020
remote-to-remote copies
Do not add another "-s" to the argument vector every time an SFTP
connection is initiated. Instead, introduce a subsystem flag to
do_cmd() and add "-s" when the flag is set.
ok djm@
OpenBSD-Commit-ID: 25df69759f323661d31b2e1e790faa22e27966c1
default. Replace recently added -M option to select the protocol with -O
(olde) and -s (SFTP) flags, and label the -s flag with a clear warning that
it will be removed in the near future (so no, don't use it in scripts!).
prompted by/feedback from deraadt@
OpenBSD-Commit-ID: 92ad72cc6f0023c9be9e316d8b30eb6d8d749cfc
provides a much better and more intuitive user experience and doesn't require
exposing credentials to the source host.
thanks naddy@ for catching the missing argument in usage()
"Yes please!" - markus@
"makes a lot of sense" - deraadt@
"the right thing to do" - dtucker@
OpenBSD-Commit-ID: d0d2af5f0965c5192ba5b2fa461c9f9b130e5dd9
as possible. Previosuly, it would try to make relative and ~/-rooted paths
absolute before requesting transfers.
prompted by and much discussion deraadt@
ok markus@
OpenBSD-Commit-ID: 46639d382ea99546a4914b545fa7b00fa1be5566
~-prefixed paths, in particular ~user ones. Allows scp in sftp mode to accept
these paths, like scp in rcp mode does.
prompted by and much discussion deraadt@
ok markus@
OpenBSD-Commit-ID: 7d794def9e4de348e1e777f6030fc9bafdfff392
prefixed paths. ~user paths aren't supported, but ~/ paths will be accepted
and prefixed with the SFTP server starting directory (more to come)
prompted by and discussed with deraadt@
ok markus@
OpenBSD-Commit-ID: 263a071f14555c045fd03132a8fb6cbd983df00d
exiting avoids LogLevel=verbose (or greater) messages from ssh appearing
after scp has returned exited and control has returned to the shell; ok
markus@
(this was originally committed as r1.223 along with unrelated stuff that
I rolled back in r1.224)
OpenBSD-Commit-ID: 1261fd667ad918484889ed3d7aec074f3956a74b
exiting avoids LogLevel=verbose (or greater) messages from ssh appearing
after scp has returned exited and control has returned to the shell; ok
markus@
OpenBSD-Commit-ID: ef9dab5ef5ae54a6a4c3b15d380568e94263456c
scp(1) by suppressing "Retrieving [path]" lines that were emitted to support
the interactive sftp(1) client. ok markus@
OpenBSD-Commit-ID: 06be293df5f156a18f366079be2f33fa68001acc
basename(3) and prevent a use-after-free in that case in the new sftp-compat
code.
POSIX allows basename(3) to either return a pointer to static storage
or modify the passed string and return a pointer to that. OpenBSD does
the former and works as is, but on other platforms "filename" points
into "tmp" which was just freed. This makes the freeing of tmp
consistent with the other variable in the loop.
Pinpointed by the -portable Valgrind regress test. ok djm@ deraadt@
OpenBSD-Commit-ID: 750f3c19bd4440e4210e30dd5d7367386e833374
scp, via a new "-M sftp" option. Marked as experimental for now.
Some corner-cases exist, in particular there is no attempt to
provide bug-compatibility with scp's weird "double shell" quoting
rules.
Mostly by Jakub Jelen in GHPR#194 with some tweaks by me. ok markus@
Thanks jmc@ for improving the scp.1 bits.
OpenBSD-Commit-ID: 6ce4c9157ff17b650ace571c9f7793d92874051c
djm@openbsd.org
dtucker@openbsd.org
Damien Miller
millert@openbsd.org
jmc@openbsd.org
Darren Tucker
deraadt@openbsd.org
naddy@openbsd.org