Hi!
On Sat, 2023-12-30 at 02:33:22 +0100, Simon Josefsson wrote:
> Ah, I had forgotten about this (if I ever knew about it). But looking
> at src/rsh*.c in inetutils there is plenty of Kerberos stuff in it.
> Doesn't it work? We build inetutils against MIT Kerberos V5 in GitLab
> CI/CD: https://gitlab.com/jas/inetutils/-/jobs/5836939514
AFAIR the Kerberos V5 support is not complete for those commands, at
least according to the configure.ac file:
,---
krb5)
[…]
# We have limited support for krcmd() with Kerberos5.
# Encryption must be sorted out as a first step.
IU_DISABLE_TARGET(rcp)
IU_DISABLE_TARGET(rlogin)
IU_DISABLE_TARGET(rsh)
# Likewise, we need to migrate away from KRB4 and des_*()
IU_DISABLE_TARGET(rlogind)
IU_DISABLE_TARGET(rshd)
`---
And forcibly commenting those out, resulted in compilation failures
(and just checked now to confirm this).
> I think there is value in having a plaintext-able rsh and rshd
> available for interacting with ancient systems.
>
> The current netkit-rsh package does not support Kerberos. I feel it
> may be more appropriate to replace netkit-rsh with a inetutils-rsh of
> the same feature-set rather than with a Kerberos-enabled variant.
There's also the src:rsh-redone packages, but that also seems
orphaned. In any case I understand how rsh/rexec/rlogin might be
useful for compatibility, but as I've said I'd feel rather
uncomfortable adding this anew (even if to replace the equivalent
netkit or rsh-redone ones), with no encryption available whatsover
on this day and age. In general I think using ssh should always be the
better option in any case.
> Offering both would be even better. But simply enabling Kerberos V5
> for rsh/rsh in inetutils and ship that is probably sufficient and
> resolves all concerns.
If we can get the Kerberos V5 support then that would indeed
ameliorate my concerns, even though the program will still be usable
in their default insecure modes. :)
Thanks,
Guillem
