Secure Chat with YTalk and SSH
Pages: 1, 2
Exploiting the Full Power of YTalk While Online
YTalk can become quite cool when its options are used properly. Press
Escape for a menu:
###########################
# Main Menu
#
#a: add a user
#d: delete a user
#k: kill all unconnected
#o: options
#s: shell
#u: user list
#w: output user to file
#q: quit
###########################I won't repeat details that can be found in the man pages. The menu allows you to know who's on the talk server, react to new users, reply to talk requests, connect and disconnect, as well as output everything to a file.
Suppose salt@www.munchies.org and
vinegar@www.munchies.org are chatting away. Suddenly
ketchup wants to join in and talk to
vinegar. Here's what vinegar will see:
----------= YTalk version 3.1.1 =----------
######################################
# Talk to ketchup@www.munchies.org? #
######################################
----------= salt@www.munchies.org =---------- All vinegar has to do is type y for yes. He will now see:
----------= YTalk version 3.1.1 =----------
----------= salt@www.munchies.org =----------
----------= ketchup@www.munchies.org =---------- If salt@www.munchies.org wants to talk to
ketchup@www.munchies.org, all he has to do is to select
a: add a user from the YTalk main menu. He will see:
###########################
# Main Menu
#
# a: add a user
######################################
# Add Which User?
# >
#######################################
# u: user list
# w: output user to file
# q: quit
########################### All salt has to do is type ketchup to add
him to the conversation. Deleting a user is just as simple.
Setting Options Before Going Online with .ytalkrc
There are a number of useful options that give power and flexibility
to YTalk, but let's stick to the basics for the sake of brevity and
simplicity. Options may be set in the .ytalkrc file located
in your home directory. Otherwise, the system wide defaults are in
/usr/local/etc/ytalkrc. Here a typical
.ytalkrc:
################
# a user's window will scroll when he reaches the bottom
# instead of wrapping back around to the top.
turn scrolling on
# re-ring any user who does not respond to your
# invitation within 30 seconds.
turn rering on
# re-rings a user without asking permission.
turn prompt-rering off
# any word which would overextend the right margin will
# be automatically moved to the next line on your screen.
turn word-wrap on
# will add these users to your session
# automatically, without asking you for verification.
turn auto-import on
# will automatically accept any connection
# requested by another user and add
# them to your session. You will not be asked for verification.
turn auto-invite on
#################Remember to look at the man page for further referencing.
Extra Tricks
One of the unfortunate aspects of your garden variety chat lines and
instant messaging systems is the inability to navigate up or down one or
more lines to retype a letter, word or phrase, much less copy and paste
something you may have said 10 minutes earlier. You are condemned to
retype. However, if salt@www.munchies.org were to use the
shell command and activate vi (or, my preference,
vim), he would have the control and versatility of this
powerful editor within YTalk. For the truly enterprising, you can't go
wrong using emacs; just think of all those horizontal and
vertical screens you can generate.
Most of my explorations were involved figuring out YTalk but there was a lot I could have done with SSH. We could have set up public key authentication, for example, but remember it is only available on SSH protocol version 2. A simple SSH contact would have resulted in an immediate login without typing a password. This is great for the typing handicapped among us.
Simplifying and securing the login process can be further enhanced by
restricting the login profile and default account shell--bash
in my case. Everybody can use the same account and when YTalk is
automatically invoked in the script it will look for certain terminals to
log into.
Conclusions
Are there limitations? YTalk works best when there are no more than 3
users. Why? Terminal size: the more people log in, the less space each
user receives. Are there nifty features that could be incorporated? The
X version of YTalk, although primitive, is going in the right direction.
Wouldn't it be great if somebody could look at the code and incorporate
X11 forwarding so as to allow graphical utilities to be tunneled through
it, say, xpaint? Now that I think of it SSH already has X11
port forwarding...
References
Robert Bernier is the PostgreSQL business intelligence analyst for SRA America, a subsidiary of Software Research America (SRA).
Return to the Linux DevCenter.
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 8 of 8.
-
No kidding...
2003-02-24 15:18:23 mbooster [Reply | View]
It would be secure, easier and a lot more usefull if you grabbed a talker base, like Amnuts (www.amnuts.org) and changed it's code to open ssl sockets instead of normal ones. Then, you just had your talker running on a port, and those who wanted would log in.
-
Key based auth
2003-02-21 11:23:53 anonymous2 [Reply | View]
"We could have set up public key authentication, for example, but remember it is only available on SSH protocol version 2"
This is incorrect.. openssh supports ssh v1 RSA key based authentication just fine. It does require a different key type to v2 (use -t rsa1 instead of -t rsa to ssh-keygen), and there are several good reasons why you should allways use v2 instead of v1 where possible.. but still.
-
huh?
2003-02-21 07:48:23 anonymous2 [Reply | View]
ytalk? are you kidding? this is ancient clunky crap.
-
re: I don't understand
2003-02-20 07:02:22 rbernier [Reply | View]
Actually there is no difference in terms of security. The difference is in features. YTalk just happens to have a lot of features that can be very nice to use. the biggest plus is it allows more than two people to communicate at the same time.
The security is because you are using SSH.
Please feel free to email me at robert.bernier5@sympatico.ca if you have any other questions
-
I don't understand
2003-02-20 05:34:39 anonymous2 [Reply | View]
What's the difference (security-wise) between using ytalk on same host and ntalk (or talk) on the same host? I didn't see any security feature for ytalk. I don't see what's giving ytalk. If both users are on the same host connected through ssh, what's the point of using ytalk over ntalk/talk?
Simon
-
Jabber
2003-02-17 03:05:50 anonymous2 [Reply | View]
You could also use jabber with SSL for relatively secure messaging.
-
Don't quit your day job
2003-02-15 20:24:02 anonymous2 [Reply | View]
I can't believe this article passed and made it to publication.
The title says "Secure Chat ....".
This is NOT SECURE !
You're (using ssh) securing a connection from point A (your desktop) to point B (an arbitary server).
Good, anything that goes back and forth between the server and you is encrypted.
Then you run ychat and invite someone else on the same server B to join you. Have they also used ssh to connect to server B ? Are they local on the box ? did they telnet in ? Unless their connection is also secure, the whole privacy thing is blown out of the water. Remember, all chat participants will receive all other participant's messages, and security is as strong as it's weakest link.
But wait, what is this ? You have ychat run by person X connecting to another instance of ychat (or talk, or whatever) run by person Y. But how do the 2 ytalk's talk together ?
Think about it for a second, then run this command on machine B:
tcpdump -X port ntalk
And presto.. There's your cleartext conversation being sniffed as easy as pie.
The *only* way to secure such a chat via ssh is via ssh's tunneling and port-forwarding, which was not mentioned in this article.
- Mina
- http://www.topfx.com
actually say anything. There is nothing interesting
about this combination of ssh and ytalk. ssh can run command line and curses programs. UNIX and Linux can allow multiple people to log into a machine. ytalk can let multiple people on a machine (or on a LAN) talk chat with one another.
It is then obvious that we can set up a machine with accounts on it so people can ssh to it and all right ytalk to one another. So what?
It might have been more interesting to look at the MIT/Athena Zephyr chat system, or Jabber over SSL