KRSHD(8)

💅 KRSHD(8) — kerberized remote shell server 🐚

okay bestie, welcome to kshd, the kerberized remote shell server. this is the kshd(8) page from the System Manager's Manual, and yes we're reading the whole thing together, grab a boba 🧋

---

✨ NAME ✨

kshd — kerberized remote shell server 🔥

---

🦋 SYNOPSIS 🦋

kshd [ -kr45ec ] [-D port] [-L variable]

---

🌸 DESCRIPTION 🌸

kshd is literally the server for the rcmd(3) routine and, by extension, for the rsh(1) program. it hands out remote execution facilities, with authentication based on privileged port numbers coming from trusted hosts, or on the Kerberos authentication system. main character energy, honestly 👑

kshd gets invoked by inetd(8c) when a connection shows up on the port indicated in /etc/inetd.conf. a typical /etc/inetd.conf line for krshd might look like this:

kshell    stream    tcp  nowait    root /usr/lib/mit/sbin/kshd   kshd
-5c

so when a service request comes in, this whole protocol kicks off, in order:

1. authentication is checked ✅
2. authorization gets checked via the access-control files .k5login and .klogin in the user's home directory 🔍
3. a null byte is returned on the initial socket, and the command line is passed to the user's normal login shell. the shell inherits the network connections established by krshd 🐚

kshd can be configured through command-line arguments passed by inetd(8). the options are:

• -5 — allow Kerberos5 authentication with the .k5login access control file to be trusted. if the client is using this authentication system and the authorization check passes, then the user is allowed to log in. if the user has no .k5login file, the login is authorized if the results of the krb5_aname_to_localname conversion match the account name. unless special rules are configured, that's true if and only if the Kerberos principal of the connecting user is in the default local realm and the principal portion matches the account name 💖
• -4 — allow Kerberos4 authentication with the .klogin access control file to be trusted. if the client uses this authentication system and the authorization check passes, the user is allowed to log in.
• -k — allow Kerberos5 and Kerberos4 as acceptable authentication mechanisms. this is the same as including -4 and -5 together 🫶
• -e — require the client to encrypt the connection. only Kerberos5 clients support encryption 🔒
• -L variable — carry the current value of the specified variable through into the environment of the child. this option can be used to preserve up to four variables.
• -c — require Kerberos5 clients to present a cryptographic checksum of initial connection information — like the name of the user the client is trying to access — inside the initial authenticator. this checksum gives you additional security by preventing an attacker from changing the initial connection information. to actually benefit from that security, only Kerberos5 should be trusted, because Kerberos4 and rhosts authentication don't include this checksum. if this option is specified, older Kerberos5 clients that don't send a checksum in the authenticator will not be able to authenticate to this server. this option is mutually exclusive with the -i option ⚠️

if neither the -c nor the -i option is specified, then checksums are validated if they're presented. since it's difficult to remove a checksum from an authenticator without making the authenticator invalid, this default mode is almost as significant a security improvement as -c, provided new clients are used. it also has the bonus advantage of backwards compatibility with some clients. unfortunately, clients before Kerberos V5, Beta5 generate invalid checksums, so if those clients are used, the -i option must be used 😭

• -i — ignore authenticator checksums if they're provided. this option ignores the authenticator checksums presented by current Kerberos clients to protect initial connection information; it's the exact opposite of -c. this option exists because some older clients — particularly clients predating the release of Kerberos V5 Beta5 (May 1995) — present bogus checksums that prevent Kerberos authentication from succeeding in the default mode 💀

---

🎀 testing options 🎀

krshd supports six options that may be used for testing:

• -S keytab — set the keytab file to use.
• -M realm — set the Kerberos realm to use.
• -A — don't allocate a reserved port for the stderr connection.
• -P path — use the argument to find the Kerberos binaries. normally a compiled-in argument is used.
• -D port — run in standalone mode, listening on port. the daemon will exit after one connection and will not background itself.
• -w [ip|maxhostlen[,[no]striplocal]] — controls the form of the remote hostname passed to login(1). specifying ip results in the numeric IP address always being passed to login(1). specifying a number, maxhostlen, sets the maximum length of the hostname passed to login(1) before it gets passed as a numeric IP address instead. if maxhostlen is 0, then the system default is used, as determined by the utmp or utmpx structures. the nostriplocal and striplocal options, which must be preceded by a comma, control whether or not the local host domain is stripped from the remote hostname. by default, the equivalent of striplocal is in effect 🌈

---

💀 DIAGNOSTICS 💀

except for the last one listed below, all diagnostic messages are returned on the initial socket, and after that any network connections are closed. an error is indicated by a leading byte with a value of 1 (and 0 is returned in step 3 above, upon successful completion of all the steps before the login shell gets executed) 🚨

• locuser too long — the name of the user on the client's machine is longer than 16 characters.
• remuser too long — the name of the user on the remote machine is longer than 16 characters.
• command too long — the command line passed exceeds the size of the argument list (as configured into the system).
• Login incorrect. — no password file entry existed for that user name.
• No remote directory. — the chdir command to the home directory failed.
• Permission denied. — the authentication procedure described above failed.
• Can't make pipe. — the pipe needed for the stderr wasn't created.
• Try again. — a fork by the server failed.
• <shellname>: ... — the user's login shell could not be started. this message is returned on the connection associated with the stderr, and it is not preceded by a flag byte 🙈

---

🦋 SEE ALSO 🦋

rshd(8), rsh(1), rcmd(3)

---

😭 BUGS 😭

• a facility to allow all data exchanges to be encrypted should be present.
• a more extensible protocol should be used.

---

okay that's the whole thing, no cap 💜 this was KRSHD(8) from the System Manager's Manual — go forth and rsh responsibly, bestie, mwah 💅✨🎀