It turned out that ktelnetd cannot find path to /usr/bin/login program, when I execute "ktelnetd -a none" through xinetd. Probably you only test ktelnetd with encryption enabled, but for fail-over purposes I need the old, non-encrypted approach. Anyway, what I propose is that you use the configure flag to set the full path to login program during the compile time ("/bin/login").
To show what I meant with this, try: # kadmin kadmin> add --random-key host/my.machine.foo.bar Max ticket life [1 day]: Max renewable life [1 week]: Principal expiration time [never]: Password expiration time [never]: Attributes []: kadmin> [create similarly random keys for services telnet and ftp, the principals are ftp/my.machine@FOO.BAR and telnet/my.machine@FOO.BAR. See http://www.pdc.kth.se/heimdal/heimdal.html#keytabs for more docs. Continue then with extraction of the host key from KDC server (created above) on your local machine] kadmin> ext host/my.machine.foo.bar kadmin> quit # ktutil list FILE:/etc/krb5.keytab: Vno Type Principal 1 des-cbc-crc afs/my.machine.foo.bar@FOO.BAR 1 des-cbc-md5 host/my.machine.foo.bar@FOO.BAR 1 des-cbc-md4 host/my.machine.foo.bar@FOO.BAR 1 des-cbc-crc host/my.machine.foo.bar@FOO.BAR 1 aes256-cts-hmac-sha1-96 host/my.machine.foo.bar@FOO.BAR 1 arcfour-hmac-md5 host/my.machine.foo.bar@FOO.BAR 1 des3-cbc-sha1 host/my.machine.foo.bar@FOO.BAR # # /usr/sbin/ktelnetd -a none -debug ktelnetd: socket af = 10: Address family not supported by protocol [this will show on current terminal the log output] # ktelnet my.machine.foo.bar -l me Encryption is verbose Trying xxx.xxx.xxx.xxx... Connected to my.machine.foo.bar. Escape character is '^]'. Waiting for encryption to be negotiated... [ Trying mutual KERBEROS5 (host/my.machine.foo.bar@FOO.BAR)... ] [ Kerberos V5 accepts you as ``me/admin@FOO.BAR'' ] [ Kerberos V5 accepted forwarded credentials ] [ Output is now encrypted with type DES_CFB64 ] [ Input is now decrypted with type DES_CFB64 ] Encryption negotiated. This is \n.\O (\s \m \r) \t telnetd: /usr/bin/login: No such file or directory. Connection closed by foreign host. # The fix is just a simple configure flag to be added to .ebuild!
Sorry, I forgot the --with-login flag to configure is available only in case of openssh. Configure distributed with heimdal doesn't have it. It would work out of the box with the login binary available from heimdal itself, but you install it as /usr/bin/klogin. Let me emphasize on platform (other than Linux) where for example the heimdal-x.x.x./appl/login/login.c did not support well its native authentication mechanism telnetd/ftpd/rshd call the system-wide "/usr/bin/login -f" to finish login procedure, that means the login binary available with heimdal is not strictly necessary. I think as the PAM support is available on Linux the login from heimdal is functionally same as login in Gentoo base system. In my example in original comment #1 I should have said one can work around by doing: /usr/sbin/ktelnetd -a none -debug -L /usr/bin/klogin or /usr/sbin/ktelnetd -a none -debug -L /bin/login
*** Bug 125443 has been marked as a duplicate of this bug. ***
Created attachment 86069 [details, diff] 014_all_heimdal-path.patch I would prefer it to be self-contained. Does this patch fix all the issues?
Quick inspection tells me one more are missing: # strings /usr/bin/klogin | grep bin /usr/bin:/bin /bin/sh /usr/bin/passwd fork /bin/passwd # ls -la /usr/bin/passwd lrwxrwxrwx 1 root root 11 Mar 23 11:51 /usr/bin/passwd -> /bin/passwd # It should point to kpasswd.
The ktelnetd issue is fixed by the patch 014_all_heimdal-path.patch, also the krsh issue is fixed. The client rsh manpages are installed in any case now, but rhsd.8 is not. Generally, the selective installation of manpages makes me suspect not all manpages are installed on Gentoo. :( Please fix the klogin sources as well so it executes kpasswd from proper location (comment #5). Thanks.
heimdal developers answered my email, so here we go: > Hi, > I had some fun on Gentoo linux with Heimdal packages and after a while I > have finally figured out that the hard-compiled-in path to login(1) is wrong. > Is there any way to tell configure which path to use? > http://bugs.gentoo.org/show_bug.cgi?id=118508 Johan, how to solve this ? > I think Gentoo developers should be instructed how to tell configure that > rcp/rsh will be installed under different names (krcp, krsh), etc. It sucks > they always rename an relocate things. > http://bugs.gentoo.org/show_bug.cgi?id=125443 > --program-transform-name="s/^rsh$/krsh/;s/^rshd$/krshd/" as argument to configure. Love
Created attachment 86183 [details, diff] 014_all_heimdal-path.patch Next time Cc us instead please. What is the problem in renaming the binaries, and what are we relocating? The only real issue is the hardcoding of path/name for the exec calls in the clients. Patch updated to fix also login.
With relocation I meant installing into other PATHs than default. Especially in case of Kerberos and its apps which look for hardcoded paths, where their configure tries to guess that kth-krb is in /usr/athena, heimdal in /usr/heimdal and mit-krb5 in /usr and is often fooled if they are not. But I pointed this many times, and current buglist shows that filenames have collisions, that kth-krb and heimdal still cannot be installed together on Gentoo ... you have no resources and users have to test and report ... and there're just a few. I think the patch is correct, the passwd stuff I cannot test now as I don't use password expirations, which would force me to change my pass on next successfull login. Probably the part @@ -38,7 +38,7 @@ #ifdef HAVE_SHADOW_H #ifndef _PATH_CHPASS -#define _PATH_CHPASS "/usr/bin/passwd" +#define _PATH_CHPASS "/usr/bin/kpasswd" #endif static int would be replaced for consistency and just for future $bindir manipulations by configure with: @@ -38,7 +38,7 @@ #ifdef HAVE_SHADOW_H #ifndef _PATH_CHPASS -#define _PATH_CHPASS BINDIR "/passwd" +#define _PATH_CHPASS BINDIR "/kpasswd" #endif static int Additional answer from Love Astrand Hornquist: >> --program-transform-name="s/^rsh$/krsh/;s/^rshd$/krshd/" as argument to >> configure. > > > Is this really equivalent to the patch attached to the bug? > > http://bugs.gentoo.org/show_bug.cgi?id=118508 No, but it should be, I'll have a look if its possible. rsh/rcp are one of those interesting programs that keep running each other. Love
I haven't heard anything back from heimdal developers yet, so please commit the patch after taking in the changes proposed in comment #9 in the meantime; but probably keep the issue open unless we hear from upstream. Thanks.
fixed in 0.7.2-r2
