I uninstalled vsftpd, but I can still connect with sftp

Question

I installed vsftpd and was in the process of configuring it. When I sent the vsftpd server stop command:

sudo service vsftpd stop

I received:

stop: Unknown instance

So I went ahead and uninstalled it and rebooted the system

sudo apt-get remove --purge vsftpd

when I 'stop' vsftpd now it says:

vsftpd: unrecognized service

If I try 'uninstalling' vsftpd its says:

Package vsftpd is not installed, so not removed

Issue: But I can still connect to my server using FTP client

I cannot somehow believe there is a zombie? process that is not getting killed even after reboot. Can someone please throw light on this?

System Configuration: Ubuntu 12.04.1 Server LTS as Guest VM on Windows 7 Host VM

TCP dump as requested: Command: sudo tcpdump port 22 >tcpdump.log Action taken: Used WinSCP to SFTP into the Guest OS Server

tcpdumplog:

17:00:42.745423 IP Brown.home.54199 > ubuntu-12.home.ssh: Flags [P.], seq 4076673955:4076673991, ack 3552872727, win 17520, length 36
17:00:42.745442 IP Brown.home.54199 > ubuntu-12.home.ssh: Flags [F.], seq 36, ack 1, win 17520, length 0
17:00:42.746192 IP ubuntu-12.home.ssh > Brown.home.54199: Flags [F.], seq 1, ack 37, win 16616, length 0
17:00:42.746406 IP Brown.home.54199 > ubuntu-12.home.ssh: Flags [.], ack 2, win 17520, length 0
17:00:50.181085 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [S], seq 8389211, win 8192, options [mss 1460,nop,nop,sackOK], length 0
17:00:50.181112 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [S.], seq 1127786298, ack 8389212, win 14600, options [mss 1460,nop,nop,sackOK], length 0
17:00:50.181262 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [.], ack 1, win 17520, length 0
17:00:50.186862 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [P.], seq 1:40, ack 1, win 14600, length 39
17:00:50.187152 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [P.], seq 1:31, ack 40, win 17481, length 30
17:00:50.187282 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [.], ack 31, win 14600, length 0
17:00:50.187476 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [P.], seq 31:639, ack 40, win 17481, length 608
17:00:50.187485 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [.], ack 639, win 15808, length 0
17:00:50.188653 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [P.], seq 40:1024, ack 639, win 15808, length 984
17:00:50.188900 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [P.], seq 639:655, ack 1024, win 16497, length 16
17:00:50.190537 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [P.], seq 1024:1304, ack 655, win 15808, length 280
17:00:50.240004 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [P.], seq 655:927, ack 1304, win 16217, length 272
17:00:50.254190 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [P.], seq 1304:2152, ack 927, win 17024, length 848
17:00:50.312380 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [P.], seq 927:943, ack 2152, win 17520, length 16
17:00:50.351847 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [.], ack 943, win 17024, length 0
17:00:50.352298 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [P.], seq 943:995, ack 2152, win 17520, length 52
17:00:50.352316 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [.], ack 995, win 17024, length 0
17:00:50.352579 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [P.], seq 2152:2204, ack 995, win 17024, length 52
17:00:50.361499 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [P.], seq 995:1063, ack 2204, win 17468, length 68
17:00:50.388593 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [P.], seq 2204:2272, ack 1063, win 17024, length 68
17:00:50.590761 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [.], ack 2272, win 17400, length 0
17:00:52.960712 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [P.], seq 1063:1147, ack 2272, win 17400, length 84
17:00:52.999659 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [.], ack 1147, win 17024, length 0
17:00:53.037972 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [P.], seq 2272:2308, ack 1147, win 17024, length 36
17:00:53.038482 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [P.], seq 1147:1215, ack 2308, win 17364, length 68
17:00:53.038510 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [.], ack 1215, win 17024, length 0
17:00:53.271416 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [P.], seq 2308:2360, ack 1215, win 17024, length 52
17:00:53.271628 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [P.], seq 1215:1299, ack 2360, win 17312, length 84
17:00:53.271661 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [.], ack 1299, win 17024, length 0
17:00:53.271864 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [P.], seq 1299:1367, ack 2360, win 17312, length 68
17:00:53.271872 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [.], ack 1367, win 17024, length 0
17:00:53.272369 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [P.], seq 2360:2448, ack 1367, win 17024, length 88
17:00:53.275151 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [P.], seq 1367:1419, ack 2448, win 17224, length 52
17:00:53.275347 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [P.], seq 2448:2628, ack 1419, win 17024, length 180
17:00:53.279576 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [P.], seq 1419:1471, ack 2628, win 17044, length 52
17:00:53.279717 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [P.], seq 2628:2728, ack 1471, win 17024, length 100
17:00:53.280194 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [P.], seq 1471:1539, ack 2728, win 16944, length 68
17:00:53.280339 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [P.], seq 2728:2796, ack 1539, win 17024, length 68
17:00:53.280546 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [P.], seq 1539:1607, ack 2796, win 16876, length 68
17:00:53.280869 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [P.], seq 2796:3504, ack 1607, win 17024, length 708
17:00:53.281105 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [P.], seq 1607:1675, ack 3504, win 16168, length 68
17:00:53.281218 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [P.], seq 3504:3588, ack 1675, win 17024, length 84
17:00:53.281416 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [P.], seq 1675:1743, ack 3588, win 16084, length 68
17:00:53.281543 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [P.], seq 3588:3656, ack 1743, win 17024, length 68
17:00:53.480952 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [.], ack 3656, win 17520, length 0
17:00:56.881662 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [P.], seq 1743:1779, ack 3656, win 17520, length 36
17:00:56.881688 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [F.], seq 1779, ack 3656, win 17520, length 0
17:00:56.881908 IP ubuntu-12.home.ssh > Brown.home.54223: Flags [F.], seq 3656, ack 1780, win 17024, length 0
17:00:56.882061 IP Brown.home.54223 > ubuntu-12.home.ssh: Flags [.], ack 3657, win 17520, length 0

Please let me know in case you require any additional information

Solution 1

SFTP is not FTP. It's the sftp subsystem of ssh, it's handled by the sshd daemon, not vsftpd or any FTP server. It's on the ssh TCP port (22), not the FTP port 21 (well FTP commands are on 21 while data connections are on arbitrary ports, and those multiple connections in FTP are one of the many reasons why SFTP is so much better than FTP).

ss -lp sport = :22

or

ss -lp sport = :ssh

would show you that sshd is handling the connections there.

If you want to disable SFTP but retain ssh access (though that would make little sense unless users land with a restricted shell on that machine), you have to disable sftp in sshd_config by commenting out the Subsystem sftp... line.

Solution 2

It sounds likely that the vsftpd that is installed has not been as part of a package.

You can identify which process is handling ftp connections with (as root):

ss -pl sport = :ftp

If it says inetd or xinetd, you'd need to have a look at their configuration to see what command is actually run for those.

If it doesn't, then given the process' pid ($pid), do a

dpkg -S "$(readlink -f "/proc/$pid/exe")"

That should identify which package if any that command is part of. If there's no package, you may have to find out how the software was installed in the first place as it would probably come with instructions on how to remove it.

(note that a zombie process in Unix refers to something quite different).

Solution 3

From your other comments, it doesn't sound like you do have a FTP server running. One possibility is that there is a firewall, either on your machine or elsewhere, that is redirecting the FTP port to another host, or that it's being intercepted by the virtualization software. Or, you're mistaken and you're simply not connecting to the machine you think you're connecting to. Providing the output of your FTP client might help clarify. Even better could be TCP logs from the server, e.g. the output of tcpdump 'port 21'.

Another possibility, although very unlikely, is that you have a rootkit that is hiding the presence of the server process.

Solution 4

It's not a zombie. Most likely uninstall script did not managed to stop it as well but deleted all files and information on package. To recover from the situation without reboot, please try the following:

ps -A|grep vsftp

You will see a line with its PID.

Then as root use the command

kill -KILL PID

I hope you will get rid of that zombie

View more solutions

Comments

[Vikram]

what I am surprised is ps -A |grep vsftp returns nothing... hence nothing to kill....even a reboot does not work :(

[Serge]

then try netstat -ltp|grep ftp

[Serge]

run netstat -ltp|grep ftp as root - otherwise you will not see PID

[Vikram]

thanks Serge!....netstat -ltp | grep ftp returns empty however, if i run netstat -ltp it shows all other daemons (about 8-10) and none of them appears to be FTP

[Vikram]

thanks! ss -pl sport = :ftp returns no rows..only column headers: State Recv-Q Send-Q Local Address:Port Peer Address:Port. The process pid is what I am unable to find

[Vikram]

thanks for your answer. The networking configuration I have is Windows 7 machine hosting Ubuntu LAMP server Guest VM on Virtual box in a Bridged Adapter mode. I checked ifconfig of Guest VM and it is correct in my case ....I will have tcpdump uploaded

[cheshirecatalyst]

Those logs are for port 22 (SSH), not port 21 (FTP). Use the filter I suggested (port 21), not dst port 22.

[Vikram]

I get empty dump file for port 21. I had enabled only SFTP transfer (no unencrypted connection). I have updated the log file output in the question for port 22

[cheshirecatalyst]

You sound incredibly confused. FTP and SFTP are entirely different beasts. vsftpd and the FTP port (21) are completely unrelated to sshd, the sftp subsystem, and the SSH port (22).

[Vikram]

Thanks for this answer it clarified a lot! I wasnt aware of this. I also have openssh-server installed (to allow remote connections to server ofcourse). I am using this as a server for LAMP and I thought I would require VSFTPD for SFTP...but looks like openssh server is sufficient. Thanks I have learned something!