This is an ancient post with no relevance to modern systems.
This article is generally about using SCO OSR5 as your machine.
However, the concepts of using ssh to secure communications apply
to any OS.
Although high speed internet access may not have reached you
yet, it probably will soon. The advantages are obvious, but there's
a dark side: security. I'm not going to talk about the more general
aspects of securing your system here (I've done that in General Security), but only
specifically about the issue of clear text passwords with telnet,
pop, and ftp.
Out with the old, in with the new
Just because you have high speed access doesn't mean you
necessarily want to give up your present ISP. You may not want to
change your email address. You may have a web site that you need to
maintain with ftp. That's my situation: my ISP hosts my mail and my
web site, and I have no interest in changing that.
By the way, a few things you need to think about if you are
planning such a move:
Does the DSL/Cable ISP have an SMTP server you can use for
outgoing mail? The answer is almost certainly yes, but it doesn't
hurt to ask. Ask if they have a back-up server in case that one has
problems. That was a very nice feature I had with my dial-up ISP-
it was rare for the primary to have any problem, but once every
year or so it would, and I' d just switch to the secondary.
Do they have an NNTP (news) server? This may or may not be
important to you, but if it is important, you'll want to ask
questions about the groups they carry and the article retention
Are you getting a fixed IP address or will it be DHCP? You may
have reason to need a static address, or you may not.
Do they care if you are not running Windows? If so, find
Do they care if you use NAT or a Proxy to allow machines on
your internal lan to access the net through this machine?
Does their router/modem provide any security? If so, it's
important to understand what, both for its limitations and in case
it blocks something you need to provide. You can get some idea of
your security status by using an external scanning tool like those
available at http://www.grc.com/default.htm.
When I used that on my DSL line, I got informative messages on my
screen that someone might be trying to break in.
If you are keeping your current ISP for mail, how are you going
to get it? Will your ISP allow remote POP/IMAP access or will you
In the clear
Pop, telnet, and ftp all use clear-text passwords- that is, the
passwords would be totally visible to someone snooping network
traffic. That's not necessarily a problem with a dial-up line (see
the General Security article) but it could be a problem with DSL
and it is definitely a concern with cable modems.
Fortunately, there's a solution: SSH. I'm not going to comment
very much here on how you get ssh or whether or not you need a
license. This is a very confused subject due to ridiculous U.S.
export restrictions (ssh comes from Sweden, but the U.S. government
says that if a U.S. citizen downloads it from Sweden or anywhere
else in the world, they can't then export it!) and the licensing is
confused just because ssh makes it confusing. The older versions
are definitely license-free for non-commercial use, but the
definition of non-commercial is confusing. So I'm going to neatly
bypass all of that and just assume you have ssh available and have
the right to use it.
Ssh replaces telnet. Of course that's not all that it does, but
for a beginning, that's how you'll want to test it. Naturally, your
ISP has to run the sshd daemon- fortunately mine does.
ssh -l username yourisp.com
will attempt to login to "yourisp.com" as "username". It will
ask you for your password, and from that point on it looks like a
telnet session (well, not really: telnet escape keys don't work,
for example). The entire session is encrypted, from the entry of
your password right up until you log out. Nothing you do while
logged in can be seen by someone sniffing the network.
You'd think that wouldn't help you with ftp, but ssh has more
tricks up its sleeves.
logs you in, just as before, but it also sets up a trap on port
1800, and that trap will just take anything that tries to use port
1800 on your local machine and forward it to port 21 (ftp) on
yourisp.com. You can see that it does that by opening a different
window on your home machine and trying:
telnet localhost 1800
(don't do this from the login you made using ssh above; that
won't get you anything useful)
The choice of 1800 is arbitrary and might not work if by chance
port 1800 is already in use. If that is the case, just try another
port. You can see ports in use with "netstat -a".
Yes, that's right: you telnetted to port 1800 on your
local machine, but you end up connected to the ftp server at
your ISP (type "quit" to exit). What's the point? The point is that
the connection is now encrypted because it goes through ssh. Note:
this obviously isn't usually important for anonymous ftp-
this is for sites that you must log in to as a real user, such as
your hosted web site, where you need to upload files. The point is
that you do not want anyone to be able to see your login and
If you have root access, you can set this up on port 21. You'll
need to comment out "ftpd" in /etc/inetd.conf, and send a "kill -1"
to the inetd daemon before you can do that, but then there wouldn't
be any need to use 1800 as a port number,
Unfortunately, that's not quite enough. You need an ftp client
that can be told to connect to port 1800 instead of the 21 it would
default to, and you also need an ftp client that can do "passive"
transfers. Why? Because your firewall should be set not to accept
incoming connections, and keep in mind that this is
important for both anonymous and authenticated ftp.
Ftp is a little different than most protocols. When you connect
to an ftp server, you connect on what's called the "Control" port
(that's port 21). When you want to transfer a file, the ftp server
opens a data connection back to you (using port 20). There's two
connections: one that you originated, and one that the server
opened for data. And there's the problem for most firewalls: they
block that data connection because it comes from outside.
Ian Peattie noted in a comp.unix.sco.misc posting that there is
another way to solve the FTP problem:
To get round this, you can use an FTP proxy.
Luckily, IPNAT comes with an FTP proxy built in to it. If you
change your IPNAT rules to:
then IPNAT will watch for the connection coming
back from the remote server and will forward it on to the PC.
Passive ftp works by the client (that's you) telling the server
to use Passive mode-the client opens it's own data connection, and
the server uses that. The server is being "passive"- it isn't
actively opening connections. For your typical firewall, that's
much easier- the connection originates inside the firewall,
therefore it's OK (though the firewall does usually have to be told
that this is OK ahead of time).
An ftp client that answers both of these problems (and is more
than slick in other respects also) is "ncftp", which is freely
available on the web and from Skunkware. One caveat,
though, at least for the SCO Skunkware version I used while writing
this article: don't run ncftp as root. It's not that it won't work,
or that there's some awful security hole- the problem is just that
it's a little broken and doesn't properly create the bookmark and
preferences files for the root user. These are supposed to go into
$HOME/.ncftp, which is supposed to be created on first use of
ncftp, but it doesn't work for root. You shouldn't be using root
for ordinary work anyway.
Yet another way to have secure ftp is SecureFTP, which is a Java based
product for Unix or Windows.
Jean-Pierre Radley tells me that ncftp's "root" problem
can be fixed by adding "NCFTPDIR=/.ncftp" to root's
This is what an ncftp "bookmark" looks like:
Bookmark name: yourisp.com
Transfer type: Binary
Has SIZE command: Yes
Has MDTM command: Yes
Can use passive FTP: Yes
Operating System: UNIX
To create a new bookmark, type "hosts" at the ncftp prompt and
follow the directions. The only things you'll need to change are
the port (if you are not using port 21) and the "Can use Passive
FTP" (it's No by default). Make sure that the Hostname is
"localhost"- you can name the bookmark anything, but it's got to
connect to "localhost".
The other thing you need is to change your preferences so that
it will use passive ftp. Type "prefs"
Default open mode: anonymous
Anonymous password: email@example.com
Blank lines between cmds: Yes
Default FTP mode: Passive, but fall back to port if needed
(rest of preferences ommitted)
It's the "Default FTP mode" that you have to change to use
Passive. Once this is all configured as shown, an "ncftp
yourisp.com" (note that's the Bookmark name; it's really connecting
to localhost) will connect to your ISP and your control channel
(which is where your password would appear) is secure. Your data
channel is not, but that's unlikely to be a problem, and you could
always separately encrypt anything that was.
For pop, you probably want to use the actual pop port, because
many pop clients just assume 110 and can't be configured otherwise.
I had a pop client that I could configure, but for some reason that
still didn't work for me, and as my primary need (Netscape) insists
on using 110, that's what I did. That means taking POP3 out of
/etc/inetd.conf (and you wouldn't want to be running it there
anyway) and making a connection to your old ISP like this:
will take care of both forwardings at the same time.
Now all you have to do is tell your pop client (Netscape, etc.)
that you want it to use "localhost" instead of your ISP. That's all
it takes; the actual session will be forwarded to your ISP by ssh,
and it will be secure. Don't forget that you'll need to point your
SMTP at your new ISP's mail server and also News if you read news
See also Spamassassin (specifically
for Mac OS X, but would apply to any Unixy OS).
You can also use "scp" to copy files. Let's say I want to copy
"index.html" from my current directory to another machine. I might