Edit the talk service blocks listed in xinetd.conf and restart xinetd. Here it shows user root due to the lower number port it needs to bind. It
may be able to use something such as 'nobody', providing xinetd binds the port then drops privs, but I didn't test.
Code:
enabled = ntalk talk
# This talk is on 517/udp
service talk
{
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.talkd
}
service ntalk
# Port 518 UDP. This is an alternate port. Solaris/Sun (?) machines
# use one of these and not the other. Linux uses one and not the other.
{
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.talkd
}
Adjust the paths in 'server' for you system if different. Set youself(ves) 'talkable': mesg y. Or run 'mesg' to verify talkability. If those commands fail, likely you have wrong permissions on your terminal entries.
Reload the xinetd config and verify the daemon is listening on all interfaces (or desired interface(s) on a multihomed system).
Code:
ss -ua | grep talk
UNCONN 0 0 *:talk *:*
UNCONN 0 0 *:ntalk *:*
root> pkill -SIGUSR2 xinetd
Read the xinetd start/restart/reload messages in its logs and make sure all services restart OK. If trouble, kill the daemon entirely and start up fresh.
If in the console, login on tty1 and tty2. If in X, start two {A|Mrxvt|X|Rxvt|E]terms. Use 'who' to see where you need to talk to. The below shows I logged in on tty1 and then started an X11 session. Then in the first I talk to myself in the second term, which is pts/2. You can't believe the talk daemon message because talk daemon didn't know about pts terminals when it was built, so you can't just do user@host unless you've only one terminal going (like a single console login). You also can't talk to yourself on the same tty/pts, at least in my version.
[code]
1>mesg y
1>mesg
is y
1> who
jayjwa pts/2 2008-07-29 06:15 (:0)
jayjwa tty1 2008-07-28 20:18
jayjwa pts/1 2008-07-28 22:21 (:0)
1>talk jayjwa pts/2
Message from Talk_Daemon@vdrl.ath.cx at 6:15 ...
talk: connection requested by jayjwa@vdrl.ath.cx
talk: respond with: talk jayjwa@vdrl.ath.cx
2>talk jayjwa pts/1
[No connection yet]
[Waiting for your party to respond]
[Waiting for your party to respond]
[Connection established]
[No connection yet]
[Connection established]
Talk? No one runs talk anymore except me, you, and some guy in Germany...
-oo
^C
[\code]
If this still doesn't work, make sure you're not running some odd network firewall/manager thing. Check iptables are clear ( iptables -L INPUT -n -v ; iptables -L OUTPUT -n -v ). Set a sniffer up on the machine in question and try to use the talkd. Watch the packets and see if they go where they are supposed to. Talk uses /var/run/utmp(x). First (mine) tries to open it RW then fails, then opens RO. Make sure you have that and its RO for users. Run 'strace talk someone pts/1' and follow the execution path. It should load libs, look at the resolver stuff, look for utmp, read the /etc/services file, etc, and then attempt a connection. Some steps left out:
Code:
open("/lib/libdl.so.2", O_RDONLY) = 3
access("/var/run/utmpx", F_OK) = -1 ENOENT (No such file or directory)
open("/var/run/utmp", O_RDWR|O_LARGEFILE|0x80000) = -1 EACCES (Permission denied)
open("/var/run/utmp", O_RDONLY|O_LARGEFILE|0x80000) = 3
open("/etc/resolv.conf", O_RDONLY) = 3
open("/etc/nsswitch.conf", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=1362, ...}) = 0
open("/etc/services", O_RDONLY|0x80000) = 3
fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
sendto(3, "\1\2\0\0\0\0\0\2\0\2\311I\300\250\nL\0\0\0\0\0\0\0\0\0"..., 84, 0, {sa_family=AF_INET, sin_port=htons(518), sin_addr=inet_addr("192.168.10.76")}, 16) = 84
sendto(3, "\1\2\0\0\0\0\0\0\0\2\311I\300\250\nL\0\0\0\0\0\0\0\0\0"..., 84, 0, {sa_family=AF_INET, sin_port=htons(518), sin_addr=inet_addr("192.168.10.76")}, 16) = 84
talk/talkd working relies on many parts of the system being setup and working correctly.
Hardening: Maybe look at the sources and fix them up. Link in libssp if possible (didn't check). Use xinetd to limit access to appropriate hosts. I've ran talkd for over 6 years and no one's messed with it (so far....). Talk is good for quick unix-to-unix access when you don't know if the person is running other things, or at least it was when everyone ran talkd. If you need real security/authentication, you might look into Silc. There is a talk setup in GNU's 'inetutils' as well. Likely it is better maintained than the old Netkit ones, which I don't think are being actively maintained anymore. ytalk is a bit different. The above talks are the inetutils ones.
