30 Jun
2020
30 Jun
'20
2:18 a.m.
On 6/29/20 11:22 AM, Arrigo Triulzi via COFF wrote:
It is indeed Taylor UUCP.
Cool. Thank you for the confirmation.
Yes, UUCP binaries do have setuid set, even on
OpenBSD.
That clarifies setuid. Can the same be said about setgid?
Indeed, in the interest of removing setuid binaries,
UUCP was
completely removed from base OpenBSD and moved to packages.
That seems understandable, especially for OpenBSD.
I think many distros are simply removing UUCP as an antiquated package.
The key file won't normally work if permissions
are more permissive
than 0600 so that is not surprising.
Agreed. I also tried it any way and got the expected error from OpenSSH
saying that it was ignoring the key file with bad permissions.
I was, still am, naively expecting that uucp / uuto / uux are run as
normal users (not root and not the uucp user) to copy files to the uucp
queue directory structure, and then something will cause the uucp user
to initiate the outbound connection as the uucp user. I think this
later part is where my understanding breaks down.
Is it doing tunnelling between two ports, i.e. using
-L etc.? I'm
assuming you are then using uucpd on the remote end listening on the
appropriate, forwarded, port which would suggest that you don't need
UUCP to setup the connection as long as it has access to the local
forwarded port?
No.
sys:
system targetHost
call-login targetHost
called-login targetHost
port targetHost
port:
port targetHost
type pipe
command /usr/bin/ssh targetHost.fqdn /usr/sbin/uucico
Also for debugging purposes, i.e. showing us so that
we can see the
issues you discuss :)
What would you like me to show / share?
Right, never did that in my life… I set things up when
(open)SSH
was v1.2 and port forwarding not quite there yet.
ACK
I've got this same type of configuration working quite well with
multiple Linux systems.
macOS mostly works.
--
Grant. . . .
unix || die