On 1 Jul 2020, at 20:13, Grant Taylor via cctalk <cctalk at classiccmp.org> wrote: ?On 6/28/20 6:48 PM, Grant Taylor wrote: I ended up getting this to work. I don't know if it was a macOSism or a *BSDism, but the root of the problem was crossing between users via setuid / setgid in relation to OpenSSH. Two different versions of macOS behaved differently. macOS Yosemite 10.10.5 runs the underlying ssh pipe command as the user account that initiates the uucp / uuto / uux. macOS Catalina 10.15.15 runs the underlying ssh pipe command as the _uucp user, NOT the account that initiates the uucp / uuto / uux. As such, on macOS Yosemite 10.10.5, I have to have the normal user's ssh public key in the authorized_keys file on the remote system. Conversely, on macOS Catalina 10.15.15, I have to have the _uucp user's ssh public key in the authorized_keys file on the remote system. I don't know why macOS Yosemite 10.10.5 and macOS Catalina 10.15.15 are behaving differently, but they are. These inconsistencies made identifying which client ssh config file -- nominally ~/.ssh/config -- was used cumbersome. For some unknown reason, I couldn't rely on "~/" or defaults to specify the _uucp user's key (Identity) file or the known_hosts file on macOS Catalina 10.15.15, despite the fact that it was running as the _uucp user. I ended up having to hard code the paths, as they were defaulting to the original user account that initiated the uucp / uuto / uux. I can only surmise that something is fundamentally different between Linux and macOS in how it does things when changing user accounts via setuid & setgid as I did not have any of these problems on multiple Linux machines. I can further surmise that something is different between macOS Yosemite 10.10.5 and macOS Catalina 10.15.15. I don't know if this is related to System Integrity Protection or something else. -- Grant. . . . unix || die -- Grant. . . . unix || die