Hi,

I have a problem with FTP or telnet access to my Linux Debian PC from the internet. The PC gets its IP from either a router or directly from my ISP, via DHCP.

FTP or telnet works fine on the home network but when I access it from the outside, the connection times out before login. This happens whether the Linux box is behind the router or directly connected to my ISP via the ADSL modem.

Has anyone had such a problem or have an idea of the problem?

Thanks,
Ferry

Do you have any iptables setup to block outside (not 192.168.x.x) traffic?

Also, is it possible that your isp is dropping traffic on the ports you're trying to use. From what I understand, ISPs do this a lot, especially port 80.

Thanks for the replys; I'm not very sure about the IPtables and how they work. When I do a

iptables -L

I get the following:

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

But I don't know what it means... How can I check what traffic I'm blocking?

As far as the ISP is concerned, I checked the agreement and it does not say the don't allow ftp. I'll inquire to be sure!

thanks,
Ferry

Why don't you change the port your FTP daemon listens on and try that. That should eliminate the ISP. Also make sure your router, if in front of the box, forwards the necessary ports to your Linux box.

how can I change the port of the ftp service? is that in the /etc/services file?

What ftp daemon are you running? It's usually in the config file but I'm sure it varies between daemons. In vsftpd, you can change the "listen_port" directive in vsftpd.conf file.

Also, as a general note you should not be using FTP or telnet to access your machine over the Internet, as they transmit passwords in plain text, which are thus liable to be sniffed. You should use SSH and SFTP instead, as they perform encryption.

Your iptables post shows that nothing is being firewalled, so that isn't your problem.

I'm running wu-ftpd; it has its own directory: /etc/wu-ftpd but I haven't found a file containing port numbers...

thanks for the ssh tip; I've tried that as well, but the problem seems to be general in the sense that ssh, telnet or ftp do not work from an outside IP address.
If the problem is that my ISP blocks the default ports for these services, testing ftp on a different port would be very useful! I'm quite new to linux and not very comfortable with changing stuff from default...

I'd say forget about the ftp (too prone to password sniffs) and concentrate on ssh/scp.

First, make sure that you can ssh to your box from within your local network.

Then try from outside. If that doesn't work, it's likely that your ISP is blocking port 22, but I haven't seen this too often - they are usually more interested in blocking port 80.

All of the following works most conveniently if you have a remote host where you can log in from home, be virtually outside, so to speak, so you can sit in front of your box and see what;'s happening. Otherwise this can be a bit tedious if you have to leave your home each time.


You can casually try a different ssh port by running a sshd (the demon that listens for incoming ssh connections) as root in a terminal by

sshd -d -D -p 7777

the -d -D means debug output + do not become a demon, so you see all there is in your terminal.

Then, from the remote machine, ssh -v -p 7777 your.machine.at.home
(the -v for added verbosity)

and watch what's happening in your ssh session. Note that if the connection is successful, the so-started sshd terminates when you log out, so this is a one-shot test - you need to restart the sshd on the test port again for the next try. If ssh'ing works, scp will work, too.

If not, well, your best bet are high-numbered ports, but if you can't find any open port, something else is wrong. If that 7777 port and a few more don't work, try

tcpdump -i eth0 port 7777

on your local box, then repeat the ssh from the remote location. This lists all packets received on port 7777, so if you don't get any chatter whatsoever, someone's blocking you, maybe your router. As a positive test, try the ssh -p 7777 from within your network and convince yourself that tcpdump is picking that up.

(Speaking of the router if you use it, you are aware that you need to forward the ssh port 22 (or port 7777 in this example) to the local machine, right? )

Then, once you have found a non-standard port (only if it's not the standard 22), edit /etc/ssh/sshd_config and change the port number for good. I believe (not positive) the "port" line takes a list of ports, so you could have sshd listening on 22 for your internal and, say, 7777 for your external connections.

Now, before you had the iptables -L output that showed that you have NO firewall activated whatsoever. Since you bring your machine directly on the Internet, that's a bad idea. Become familiar with iptables and block all incoming tcp connections on all ports except that new ssh port and ONLY from the machine(s) you actually going to ssh/scp from. No point in opening your sshd to the whole world.

Alright, long post, give it a shot, and good luck.

mlp

from the man pages:

ftpd [ -d ] [ -v ] [ -l ] [ -t timeout ] [ -T maxtimeout ]
[ -a ] [ -A ] [ -L ] [ -i ] [ -I ] [ -o ] [ -p ctrlport ]
[ -P dataport ] [ -q ] [ -Q ] [ -r rootdir ] [ -s ] [ -S ]
[ -u umask ] [ -V ] [ -w ] [ -W ] [ -X ]


The -p and -P options override the port numbers used by
the daemon. Normally, the daemon determines the port num_
bers by looking in /etc/services for "ftp" and "ftp-data".
If there is no /etc/services entry for "ftp-data" and the
-P option is not specified, the daemon uses the port just
prior to the control connection port. The -p option is
only available if running as a standalone daemon.

So, it looks as if you change the ports identified as ftp and ftp-data in /etc/services, that will do it. Unless you want to start the deamon on the ccommand line.

OK, thanks for the help people, allthough so far no luck! I've tried the ssh tricks by mlp and here's what I get:

first, if I connect locally everything works well, ssh on port 22 or on other ports (like 7777).

when I connect from the outside world to my linux box via ssh on port 22, I get response when listening with tcpdump on port 22. but the login does not come up and the ssh times out. the same happens when I change ports (like 7777). so the ssh request is being forwarded by the router to the linux box. unfortunately I can't determine from the output of the tcpdump why the connection is not being established.

on thing of which I'm not sure is the output from the sshd command; when I do :

sshd -d -D -p 7777

I get:
debug1: sshd version OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: Bind to port 7777 on 0.0.0.0.
Server listening on 0.0.0.0 port 7777.

Now is it normal to get 0.0.0.0 as I was expecting my local ip address (192.etc)? Or is there other output that I can post whicht might be helpful?

Ok, this gives the story a different twist - so you *can* get port 22 through from your ISP, all is fine in this department - unless you want to add security by obscurity (a non-standard port for that reason), there's no need for that.

Now, since you see packets trickle in, the other possibility is that your sshd's reply doesn't reach the remote host back. Try another tcpdump command,

tcpdump -i eth0 host <your remote host>

that logs packets not on a specific port but from and to your remote machine. (Be careful though - if you log in from home to your remote box and type the commands to ssh back in, all the packets from that traffic will be listed, too, but you can mask those by looking at their (session-specific, but fixed for a given session) ports and not list them ( "and not port xyz"). Type a few ls commands on the remote hosts to see the ports to mask.)

Do you have root access on that remote box? Because then you can play the same tcpdump game on the remote host and get the other side of the picture.

The "listening on 0.0.0.0" just means that the sshd will respond to any incoming connection on the port in question. You could cut down the IP space you allow in, but since this is *much* weaker than an actual firewall (the packets still reach the sshd, so malformed packets, say, for some expolit, will make it to their destination), I see that feature rarely used.

Ok, try that. Getting closer. Hope it helps.

mlp

Thanks again; here's another twist.

A friend who has access to a remote linux network tried an ssh to my linux box and it worked! however, when he tried it from his XP machine, it didn't. It didn't work either when trying to access my linux box from a Unix network.

So I'm a bit lost, in the sense that it seems my linux box hears the requests from the XP machines but the connection times out and the connection is established between linux machines. I'm not sure my linux box now is the problem, or maybe some router settings?