How To Enable Telnet For Root User

How To Enable Telnet For Root User

Just add entries to the end of /etc/securetty file :
...
pts/0
pts/1
pts/2
...
pts/10

I mistakenly entered 'pts0' etc. It should be 'pts/0' . There was no
need to restart in ReadHat 7.x. I could telnet as root both from WinNT
and another Linux host.

Using SSH is highly recommended as telnet as root is a definite secuirty
risk.

HTH
----------------------------------------------------------------------
You really shouldn't do this, you should login as another user and then
use 'su' to access the root account.
( Actually, you should disable telnet altogether and use ssh instead =)

The reasons for that are as follows:

1) Telnet is not an encrypted protocol. This means that any network you go through on your way to your system has the potential to sniff the packets you are sending, and gain the data you are transmitting, including your root password.
( Note that using su doesn't solve this problem.)

2) Instead of having to hack a user account first and THEN root, an intruder can go straight for the root account, so you have pretty much cut the time for a brute-force attack in half.

But, putting all security concerns aside, if you edit /etc/securetty and add pts[0-f] ( formerly ttyp[0-f] ) you should be able to login as root via telnet. ( Unsure if you need to reboot or not ).

This file controls which terminals root can login from, and ptsx are the ports used when telnetting into linux. ( On Redhat 6.2 anyway )

Alternatively, you can edit the /etc/pam.d/rlogin file and comment out the line:

auth required /lib/security/pam_securetty.so

which will disable the use of the securetty file altogether.
( Very much _not_ recommended, but I thought I should mention it )

Hope that helps.

These folks are right, you should disable telnet and use ssh only. Beyond that you should set ssh to refuse a root login. Login as a normal user and su to root.

Linux In a Windows Network with SAMBA

Linux In a Windows Network with SAMBA

Integrating Fedora Linux into a Windows network is reasonable and easy as long as you use the SAMBA utilities. I share every main step necessary to implement such a SAMBA server within a Windows environment.
Once integrated a Linux server looks and acts exactly like any other server on a Windows intranet. You will have the ability to drag and drop files, view server contents and directories using Windows File Manager, and even edit files on a Linux server from any Windows desktop.
This article is a guide to setting up a full fledged FEDORA LINUX/SAMBA server. If you need basic steps for connecting Linux with Windows please read my article Windows to Linux: Basic Networking. If you're a system administrator and are planning to integrate the Linux server into your AD server environment, I'm sorry I do not go into details how to configure smb.conf for ADS usernames, although it can be done. I will walk you through the main steps for installing a SAMBA Server. This, in my opinion, is the first part to any future more advanced integration.
First, you must allow the Linux server full rights and access to the Windows workgroup and local domain. That means that either in your Active Server environment you need to reserve an IP address for the Linux server, or you simply need to ensure a hard coded IP address is given to the Linux server. The server must have a reserved IP address whether you deliver it via DHCP or statically assign it in the DNS. This also means that you need to ALLOW SMB DAEMON to operate. You can ensure your system security does this by editing your Firewall setup or using system-config-securitylevel .
Second, you must ensure that SAMBA (SAMBA tools and the SMB protocol) is installed and running on the Linux server. Most versions of Fedora come with the necessary packages. You should also be sure to update your SAMBA security levels properly if you are having trouble accessing a shared directory. This is found under Samba Server Configuration tool, main menu Properties, option Server Settings, and then the tab: Security.
Now you are ready to configure your Fedora Linux/SAMBA machine... aka. SAMBA Server.
STEP 1: Enable Network Connectivity to the SAMBA Server
Using the Fedora Network Configuration tool you will need to ensure that the ethernet card is enabled and properly functioning. Get quick access to the tool through this command: system-config-network
Once in the Network Configuration tool, you should ensure that your ethernet device is enabled. If it is not, select the eth device and then click on the Edit button. This will allow you to input the vital network adapter settings including: statically set IP address, subnet mask, and gateway. You should also select the top checkbox labeled Activate device when computer starts. Read this article for more details regarding configuring a network card in Fedora, Mandrake, or SuSE.
Close and save any changes you've made. The main goal is to ensure you have an ACTIVE and functioning network card on the SAMBA server.
Restart the network services or simply reboot your SAMBA server. Now try a ping to the server from another PC on the same subnet. At a command prompt, for example, type: ping 10.2.2.3
The ping should come back good validating your network connection. If you need more Linux system administration help read my Admin Commands List.
STEP 2: Update Firewall Settings
In most cases the default Firewall setting on the SAMBA server locks out any inbound network requests. I've had a great many people come running to me about this issue. If you're setting up a basic SAMBA server within your business intranet, allow your ethernet connection to be a trusted device so others can get to your SAMBA server and not be bounced by the server's Firewall.
NOTICE: if you plan to use the SAMBA server outside of your business firewall/intranet you should NOT follow the next step. Instead you allow your local server to receive packets by making changes to your IPTABLES, such as:
iptables -A INPUT -s 192.168.0.0/255.255.255.0 -j ACCEPT
The following step is for those using an intranet business server configuration.
Okay, now to allow your intranet based SAMBA server to properly accept incoming requests, from your Main menu choose System Settings, then Security Level. You can access this also by typing the command:
system-config-securitylevel
Please select the box next to the ethernet card you are using for intranet connectivity so that it becomes a TRUSTED DEVICE. Otherwise you have a super secure server that bounces inbound requests. Notice, this selection effects all the items in the Services listing above it, so please be careful in what context you allow a trusted device!
Press OK when finished.

STEP 3: Enable SMB Services
Ironically, the SMB daemon and other core services are usually NOT started by default. You will need to change this so that your SMB daemon is now started.
Using the GUI from the main menu, go to System Settings, then Server Settings, then choose Services. You can also get to this using the command: system-config-services



While you're looking over this long list of services, please DISABLE things you know for sure you do not need to run on this SAMBA server. For instance apmd, isdn, etc. But also ensure that key services such as SMB are selected and RUNNING. Select SMB and press the Start button. If it is supposedly already running you can press the Restart button to be sure it is indeed running correctly now.
Now press the Save button to make sure the configuration changes have been saved for future restarts.
Sometimes using the GUI just does not properly restart the SMB daemon. In such odd cases, I want to suggest you force a manual restart from the command line with this command: /etc/rc.d/init.d/smb restart
If you keep having startup failures, where for every reboot you need to perform Step 3, you may need to manually configure your start up processes so that SMB will always be in the init.d bootup. Okay, if that sounded ridiculously confusing then how about just going to my article on manually starting services and configurations.

STEP 4: Create Server Users & Directories
You will need to ensure that people also have a login to the SAMBA server to do their work. Logins should be provided on an as needed basis. Obviously, in most cases the users accessing the SAMBA server will be a subset of the total users on the Windows business network.
Create user logins with the Gnome User Manager tool in Fedora. You can find this from the main menu by choosing System Settings, then Users & Groups. The command for this is: system-config-users
Notice this is the first step in creating SAMBA users, which comes later.
Add as many users as you need and then move on to the next part, which is creating directories (aka. folders) for use.
This is such an obvious step most people usually forget to think about it before hand. However, it is very helpful to think ahead what directories you will allow access to on the SAMBA Server for business use. In my case the people needing SAMBA server access will be updating webpages. Therefore, I do not need to add any other folders for file sharing or group interaction. Be sure you add any folders in a reasonable and ordered fashion.
A big TIP for those who are not aware, the permissions settings for your folders are very important. If you have no idea how to change permissions, then you may want to review this article on Linux filemanagement and permissions.

STEP 5: Configure the SAMBA Server
It's time to configure your SAMBA server to allow others on the intranet to login and use the server from Windows or Linux PCs.
From the main Fedora menu, choose System Settings, then Server Settings, then Samba. You can also get to this tool by typing the command: system-config-samba
You are about to make changes to the SAMBA Configuration file called smb.conf. This file is found under /etc/samba. If you encounter issues you may want to first start by using my example smb.conf file and then make the changes below. I also want you to be aware that you can edit configuration files with the web interface tool called Samba Web Administration Tool(SWAT) and several others. Now lets move ahead using the Configuration tool using the preloaded Fedora tools. NOTICE that many people begin by tinkering with their .conf file... this is NOT a good idea. First ensure that the basic samba connectivity works and THEN you can tinker with the smb.conf! (see troubleshooting below)
A. Begin by Making Changes to the Server Settings
Under the Preference menu item choose Server Settings...




Be sure to include the Windows workgroup name. In the example above the workgroup has been changed to net. Your situation may be different. In many cases naming the workgroup simply workgroup is fine, so long as your Windows PCs connect to this same name.
Under this same window, click on the Security tab. It comes by default with the appropriate settings for a basic SAMBA Server. The Authentication mode should be User. You would need to change this only if you plan to allow logins based on the Microsoft ADS.
Press OK to finish making basic changes to the server.
B. Select SAMBA Users
Under the Preference menu item choose Samba Users
In this window you must Add at least one user who will have access to the SAMBA Server. Notice that only user accounts you created in step 4 should be added to this listing.



Press the Add User button, then from the pull down select a user. Fill out the additional information needed for this SAMBA user. Press OK when finished.
C. Adding A Shared Folder
Under the SAMBA Server Configuration window, you must create at least one SAMBA share directory.
Press the Add button and then the Browse button. Now choose a folder you wish to make available to SAMBA users. Be careful, some folders have permissions settings that do not allow sharing. Now be sure to select the Read/Write option to allow people full access. Don't press OK yet!



You should see your shared folder appear under the listing as shown in the example above.
D. Adding Users
In the same window, select the second tab labeled Access. From here choose the first option labeled Only allow access to specific users and select the users you wish to give access to this specific SAMBA shared folder. Press OK when finished.
You can repeat steps C and D for each new shared folder.
Once completed, please choose File from the menu then choose Quit.
Hopefully this saved all of your settings properly. If you encounter issues with the graphic SAMBA configuration tool, such as it failing to accept your changes, then please read the Troubleshooting Tip 4 located below.

STEP 6: Restart the SAMBA Services
Now you need to restart all SAMBA services. You can use the process found in Step 3, except press the Restart button or use the word restart instead of the word start.
I mentioned earlier that sometimes your changes do not get properly picked up. I've installed so many different Fedora SAMBA configurations that I can't recall every reason. This may be a very good time to simply reboot the LINUX/SAMBA Server. Rebooting will ensure everything gets properly started up and all of the configuration changes are included. More importantly, this is likely the last time you will ever restart your SAMBA server again. Some of my FEDORA servers haven't been restarted in years.

STEP 7: Access the SAMBA Server from Windows
You're now ready to fully utilize your new intranet SAMBA Server for work. On any Windows PC you can access the server by simply going to the main Start menu, choosing Run and typing in the hostname of your SAMBA server. For example: \\linuxserver
Please notice that in the Windows environment you use different slashes and you need to ensure this syntax.


If this does not work, perhaps if the server is not yet included in your DNS, try accessing the SAMBA Server through its IP address: \\10.2.2.3
Obviously you need to use an actual hostname or IP address and not my example.
If all works well you should instantly see a SERVER LOGIN window. Now login using a SAMBA created username.

You should then instantly see the shared folder as well as the individual user's personal folder that exist on the SAMBA Server



Congratulations, you're done.

TROUBLESHOOTING TIPS
NOTICE: I've had a number of people who encountered issues because they seriously screwed with their smb.conf file or forgot to update their Samba Server Security settings found under the Server Setup, Security tab. Please, please, before you start tinkering with your smb.conf file try to use the BASIC samba settings to ensure you ACTUALLY CAN CONNECT properly. Then when you make changes you can far better identify what goes wrong. Following the steps above should work in almost every situation IF you first start with the basic configuration.
1. SAMBA Server is not accessible
First and foremost try a reboot to the server itself! It is vital you do this before someone talks you into changing configs, playing with your network card settings etc. Just reboot and try again to see if it clears up the issue.
2. Network Unreachable or Host Unreachable From Linux PCs
Trying to connect from another Linux PC and nothing happens or "network unreachable" may be as ridiculous as an incorrect SAMBA connection. Make absolutely certain that the connection is typed in exactly as follows (obviously changing the workgroup name to your windows workgroup): smb://WORKGROUP
On some KDE desktops, attempts failed because the syntax incorrectly tries: smb:/workgroup Those // are quite important!
3. Failure to Connect from Windows PCs
Not connecting to the server from Windows PCs may be a result of bad network configuration. Are you absolutely certain you entered the correct network details? Please double check to make sure that you have a proper hostname for the Samba server, that you have a working IP address, and the correct Subnet and Gateway included. In most cases these last two should simply match what your windows PCs have designated.
4. Changes to the configuration are not being picked up
The Gnome SAMBA Configuration GUI often encounters errors when trying to update new SAMBA settings. I've seen the GUI tool write a whole lot of garbage into the SAMBA configuration file (smb.conf). For this reason, as I mentioned earlier, you may need to start with a fresh clean smb.conf file (copy my example into a text editor) and try again, or you may need to manually adjust settings without the GUI.

5. Can't Share Folder in Home Directory
First, it's always a good idea NOT to make a Samba share out of directories inside your Home folder for security reasons. Making unique share folders is often the best bet. However, there are times when you need to share a folder and the way to do so is to update your Samba Share's security settings. Under the Samba Configuration, highlight your shared directory and press Properties. Here you can see the "Basic Permissions" list and usually the default is "Read Only." Select the "Read/Write" option and be sure to save your changes by quitting and then restarting the smb daemon. If this doesn't resolve the issue of directory shares, you may have a more fundamental security issue. You need to ensure that the over all Samba security settings under "Preferences", then "System Settings" and then the Security tab are correct.
For further troubleshooting these two webpages may be helpful as well:

Allow and deny IP for ssh in Linux

Allow and deny IP for ssh in Linux

We can allow and deny IP for ssh. To do this we have to change some configuration at /etc/host.deny and /etc/host.allow files. Suppose we want to deny 192.168.100.5, then we will edit the /etc/host.deny file and do some changes as follows.
vi /etc/host.deny
sshd:192.168.100.5
Save & exit
This will deny 192.168.100.5 to ssh.
Suppose we want to allow only 192.168.100.5 to ssh. Then we will edit two files as follows:
vi /etc/host.deny
sshd:all
save & exit
vi /etc/host.allow
sshd:192.168.100.5
save & exit
We can do the same by changing only at /etc/host.deny as follows:
vi /etc/host.deny
sshd:all except 192.168.100.5
save & exit

Deny root user for ssh

Deny root user for ssh

We can deny root user for ssh. For this we have to edit the sshd-config file. To do this we have to write the following command:
vi /etc/ssh/sshd-config
Now we will find out a line
PermitRootLogin=yes
We will replaced the yes with no.
PermitRootLogin=no
Now not only the root, but also all super user can not ssh at this ssh server.
To allow any user we have to add the following line at the last line of the configuration.
AllowUsers reza
This command will allow reza user.
AllowUsers reza nayem
This command will allow reza and nayem, both users.
We must have to restart the service after editing the file. Otherwise it wont work.
Any advice regarding this issue is highly expected

Changing The Port Number at SSH

Changing The Port Number at SSH

We can change the port number of ssh. By default the port number of ssh is 22. To change the port address we have to edit the file /etc/ssh/sshd-config. We can do this with the following command.
vi /etc/ssh/sshd-config
In this file we will find a line
port 22
We will replace the 22 with 29 and then save the file.
Now we will restart the service sshd.
service sshd restart
/etc/init.d/sshd restart
Now to ssh at this server or os we have to write the following line
ssh -p 29 root@192.168.100.5

Logging at a Server With SSH

Logging at a Server With SSH

We can log in at a server or pc with ssh. For this here is some instruction.
1. Suppose we are at 192.168.100.1 and trying to ssh at 192.168.100.5 .
ssh 192.168.100.5
This command will try to connect the 192.168.100.5 as the user that he already logged in the 192.168.100.1. Suppose we are at the root user in the 192.168.100.1. Then the command will try to connect at 192.168.100.5 as the root user.
2. ssh reza@192.168.100.5
This command will try to ssh at 192.168.100.5 as the reza user.
3. ssh -l nayem 192.168.100.5
This command will try to ssh at 192.168.100.5 as nayem user.
4. ssh -p 29 root@192.168.100.5
This command will try to ssh at 192.168.100.5 using the port 29.
Thats all my knowledge about this issue. Expect to get any advice from you.

service start-up configuration For SSH

service start-up configuration For SSH

We almost everyone know about the start-up configuration at operating system. The operating system starts the services from start-up configuration while the OS starts. At Linux the same thing happens.
To check whether a service is at start-up configuration we can use the following command
chkconfig –list sshd
This command will show the start-up configuration for the sshd service.
We can add any service at startup in many ways.
1. chkconfig sshd on
With this command the service will start only in that run level in which the OS is running now. Suppose the OS is running on run level 3, then this command add the sshd service at startup of run level 3.
2. chkconfig –level 35 sshd on
This command sets the sshd to start at run level 3 and 5.
3. We know that for every run level there are files. Suppose for run level 3 there is a file /etc/init.d/rc3.d .
Here we will find some files that starts their name with either K or S . Starting with K means the service is not at startup config. S means it will start automatically.
If the sshd service is not setup at run level 3, then we will find a file K20sshd . If we rename the file S20sshd, then sshd service will be set for run level 3.
mv K20sshd S20sshd
Wish to get any comments and better advice from you.

SSH In Linux

SSH In Linux

Packages for ssh at Linux & Starting the service
openssh-server This package is for configuring the ssh at the server pc.
openssh-client This package is for configuring the ssh at the pc that will try to connect to other with that configuration.
We can check with the following command whether the packages are installed or not.
rpm -qa | grep openssh-server
We can install the packages with the following command.
rpm -ivh openssh-server
rpm -ivh openssh-client
Then we have to start the service with the following command
service sshd start
/etc/init.d/sshd start
At Debian we have to install with the following command
apt-get install ssh
At Debian after installing a package, the service starts automatically.
To start the ssh service at any time at Debian we have to use the following command
/etc/init.d/sshd start —- starts the service
/etc/init.d/sshd restart —- restarts the service
/etc/init.d/sshd stop —— stops the service
/etc/init.d/sshd reload —– reloads the service

Breaking root password at Debian

Breaking root password at Debian

Sometimes we may forget the root password. Then we need to login by breaking password. If we do not know how to break it, then we need to reinstall the OS and loose many important data. I want to share one way of breaking password at debian.
While booting you will be prompted some options like debian kernel XXX options. If you does not press any key the OS get boot on its by default type. To break the password you must stop the booting by pressing a key.
1. Then press e to edit
2. then type
boot: Linux init=/bin/sh
and press enter.
3. This will boot OS on run level 1, which wont want any password. Here you will need to mount the following things.
init-2.03# mount -n -o remount,rw /
init-2.03# mount -avt nonfs,noproc,nosmbfs
4. Now you can go to /etc and remove the password. To do so you have to remove root password from /etc/passwd and /etc/shadow. So…..
init-2.03# cd /etc
init-2.03# vi passwd
init-2.03# vi shadow
That’s all. Now restart your OS and you will find that there is no root password. After logging as root just set a new root password.
Hope to hear from you about better procedure of breaking password.
There is another way to break password using knoppix. As far as I know knoppix is also a boot loader s/w that helps us to break root password of linux. But I did not ever break password using knoppix.

Configuring FTP in Linux

Configuring FTP in Linux

How To Download And Install VSFTPD
Most Linux software products are available in a precompiled package format. Downloading and installing packages isn't hard. If you need a refresher, Chapter 6, "Installing Linux Software", covers how to do this in detail. It is best to use the latest version of VSFTPD.
When searching for the file, remember that the VSFTPD packages' filename usually starts with the word vsftpd followed by a version number, as in vsftpd-1.2.1-5.i386.rpm for Redhat/Fedora or vsftpd_2.0.4-0ubuntu4_i386.deb for Ubuntu.
How To Get VSFTPD Started
With Fedora, Redhat, Ubunbtu and Debian You can start, stop, or restart VSFTPD after booting by using these commands:
[root@bigboy tmp]# /etc/init.d/vsftpd start
[root@bigboy tmp]# /etc/init.d/vsftpd stop
[root@bigboy tmp]# /etc/init.d/vsftpd restart
With Redhat / Fedora you can configure VSFTPD to start at boot you can use the chkconfig command.
[root@bigboy tmp]# chkconfig vsftpd on
With Ubuntu / Debian the sysv-rc-conf command can be used like this:
root@u-bigboy:/tmp# sysv-rc-conf on
Note: In RedHat Linux version 8.0 and earlier, VSFTPD operation is controlled by the xinetd process, which is covered in Chapter 16, "Telnet, TFTP, and xinetd". You can find a full description of how to configure these versions of Linux for VSFTPD in Appendix III, "Fedora Version Differences."

Testing the Status of VSFTPD
You can always test whether the VSFTPD process is running by using the netstat -a command which lists all the TCP and UDP ports on which the server is listening for traffic. This example shows the expected output.
[root@bigboy root]# netstat -a | grep ftp
tcp 0 0 *:ftp *:* LISTEN
[root@bigboy root]#
If VSFTPD wasn't running, there would be no output at all.
The vsftpd.conf File
VSFTPD only reads the contents of its vsftpd.conf configuration file only when it starts, so you'll have to restart VSFTPD each time you edit the file in order for the changes to take effect. The file may be located in either the /etc or the /etc/vsftpd directories depending on your Linux distribution.
This file uses a number of default settings you need to know about.
• VSFTPD runs as an anonymous FTP server. Unless you want any remote user to log into to your default FTP directory using a username of anonymous and a password that's the same as their email address, I would suggest turning this off. The configuration file's anonymous_enable directive can be set to no to disable this feature. You'll also need to simultaneously enable local users to be able to log in by removing the comment symbol (#) before the local_enable instruction.
• If you enable anonymous FTP with VSFTPD, remember to define the root directory that visitors will visit. This is done with the anon_root directive.
anon_root=/data/directory
• VSFTPD allows only anonymous FTP downloads to remote users, not uploads from them. This can be changed by modifying the anon_upload_enable directive shown later.
• VSFTPD doesn't allow anonymous users to create directories on your FTP server. You can change this by modifying the anon_mkdir_write_enable directive.
• VSFTPD logs FTP access to the /var/log/vsftpd.log log file. You can change this by modifying the xferlog_file directive.
• By default VSFTPD expects files for anonymous FTP to be placed in the /var/ftp directory. You can change this by modifying the anon_root directive. There is always the risk with anonymous FTP that users will discover a way to write files to your anonymous FTP directory. You run the risk of filling up your /var partition if you use the default setting. It is best to make the anonymous FTP directory reside in its own dedicated partition.
The configuration file is fairly straight forward as you can see in the snippet below where we enable anonymous FTP and individual accounts simultaneously.
# Allow anonymous FTP?
anonymous_enable=YES
...
# The directory which vsftpd will try to change
# into after an anonymous login. (Default = /var/ftp)
anon_root=/data/directory
...
# Uncomment this to allow local users to log in.
local_enable=YES
...
# Uncomment this to enable any form of FTP write command.
# (Needed even if you want local users to be able to upload files)
write_enable=YES
...
# Uncomment to allow the anonymous FTP user to upload files. This only
# has an effect if global write enable is activated. Also, you will
# obviously need to create a directory writable by the FTP user.
#anon_upload_enable=YES
...
# Uncomment this if you want the anonymous FTP user to be able to create
# new directories.
#anon_mkdir_write_enable=YES
...
# Activate logging of uploads/downloads.
xferlog_enable=YES
...
# You may override where the log file goes if you like.
# The default is shown below.
xferlog_file=/var/log/vsftpd.log
...
To activate or deactivate a feature, remove or add the # at the beginning of the appropriate line.
Other vsftpd.conf Options
There are many other options you can add to this file:
• Limiting the maximum number of client connections (max_clients)
• Limiting the number of connections by source IP address (max_per_ip)
• The maximum rate of data transfer per anonymous login. (anon_max_rate)
• The maximum rate of data transfer per non-anonymous login. (local_max_rate)
Descriptions on this and more can be found in the vsftpd.conf man pages.
FTP Security Issues
FTP has a number of security drawbacks, but you can overcome them in some cases. You can restrict an individual Linux user's access to non-anonymous FTP, and you can change the configuration to not display the FTP server's software version information, but unfortunately, though very convenient, FTP logins and data transfers are not encrypted.
The /etc/vsftpd.ftpusers File
For added security, you may restrict FTP access to certain users by adding them to the list of users in the /etc/vsftpd.ftpusers file. The VSFTPD package creates this file with a number of entries for privileged users that normally shouldn't have FTP access. As FTP doesn't encrypt passwords, thereby increasing the risk of data or passwords being compromised, it is a good idea to let these entries remain and add new entries for additional security.
Anonymous Upload
If you want remote users to write data to your FTP server, then you should create a write-only directory within /var/ftp/pub. This will allow your users to upload but not access other files uploaded by other users. The commands you need are:
[root@bigboy tmp]# mkdir /var/ftp/pub/upload
[root@bigboy tmp]# chmod 722 /var/ftp/pub/upload
FTP Greeting Banner
Change the default greeting banner in the vsftpd.conf file to make it harder for malicious users to determine the type of system you have. The directive in this file is.
ftpd_banner= New Banner Here
Using SCP As Secure Alternative To FTP
One of the disadvantages of FTP is that it does not encrypt your username and password. This could make your user account vulnerable to an unauthorized attack from a person eavesdropping on the network connection. Secure Copy (SCP) and Secure FTP (SFTP) provide encryption and could be considered as an alternative to FTP for trusted users. SCP does not support anonymous services, however, a feature that FTP does support.
Troubleshooting FTP
You should always test your FTP installation by attempting to use an FTP client to log in to your FTP server to transfer sample files.
The most common sources of day-to-day failures are incorrect usernames and passwords.
Initial setup failures could be caused by firewalls along the path between the client and server blocking some or all types of FTP traffic. Typical symptoms of this are either connection timeouts or the ability to use the ls command to view the contents of a directory without the ability to either upload or download files. Follow the firewall rule guidelines to help overcome this problem. Connection problems could also be the result of typical network issues outlined in Chapter 4, "Simple Network Troubleshooting".
Tutorial
FTP has many uses, one of which is allowing numerous unknown users to download files. You have to be careful, because you run the risk of accidentally allowing unknown persons to upload files to your server. This sort of unintended activity can quickly fill up your hard drive with illegal software, images, and music for the world to download, which in turn can clog your server's Internet access and drive up your bandwidth charges.
FTP Users with Only Read Access to a Shared Directory
In this example, anonymous FTP is not desired, but a group of trusted users need to have read only access to a directory for downloading files. Here are the steps:
1) Disable anonymous FTP. Comment out the anonymous_enable line in the vsftpd.conf file like this:
# Allow anonymous FTP?
anonymous_enable=NO
2) Enable individual logins by making sure you have the local_enable line uncommented in the vsftpd.conf file like this:
# Uncomment this to allow local users to log in.
local_enable=YES
3) Start VSFTP.
[root@bigboy tmp]# service vsftpd start
4) Create a user group and shared directory. In this case, use /home/ftp-users and a user group name of ftp-users for the remote users
[root@bigboy tmp]# groupadd ftp-users
[root@bigboy tmp]# mkdir /home/ftp-docs
5) Make the directory accessible to the ftp-users group.
[root@bigboy tmp]# chmod 750 /home/ftp-docs
[root@bigboy tmp]# chown root:ftp-users /home/ftp-docs
6) Add users, and make their default directory /home/ftp-docs
[root@bigboy tmp]# useradd -g ftp-users -d /home/ftp-docs user1
[root@bigboy tmp]# useradd -g ftp-users -d /home/ftp-docs user2
[root@bigboy tmp]# useradd -g ftp-users -d /home/ftp-docs user3
[root@bigboy tmp]# useradd -g ftp-users -d /home/ftp-docs user4
[root@bigboy tmp]# passwd user1
[root@bigboy tmp]# passwd user2
[root@bigboy tmp]# passwd user3
[root@bigboy tmp]# passwd user4
7) Copy files to be downloaded by your users into the /home/ftp-docs directory
8) Change the permissions of the files in the /home/ftp-docs directory for read only access by the group
[root@bigboy tmp]# chown root:ftp-users /home/ftp-docs/*
[root@bigboy tmp]# chmod 740 /home/ftp-docs/*
Users should now be able to log in via FTP to the server using their new usernames and passwords. If you absolutely don't want any FTP users to be able to write to any directory, then you should set the write_enable line in your vsftpd.conf file to no:
write_enable = NO
Remember, you must restart VSFTPD for the configuration file changes to take effect.
Sample Login Session To Test Functionality
Here is a simple test procedure you can use to make sure everything is working correctly:
1) Check for the presence of a test file on the ftp client server.
[root@smallfry tmp]# ll
total 1
-rw-r--r-- 1 root root 0 Jan 4 09:08 testfile
[root@smallfry tmp]#
2) Connect to bigboy via FTP
[root@smallfry tmp]# ftp 192.168.1.100
Connected to 192.168.1.100 (192.168.1.100)
220 ready, dude (vsFTPd 1.1.0: beat me, break me)
Name (192.168.1.100:root): user1
331 Please specify the password.
Password:
230 Login successful. Have fun.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
As expected, we can't do an upload transfer of testfile to bigboy.
ftp> put testfile
local: testfile remote: testfile
227 Entering Passive Mode (192,168,1,100,181,210)
553 Could not create file.
ftp>
But we can view and download a copy of the VSFTPD RPM located on the FTP server bigboy.
ftp> ls
227 Entering Passive Mode (192,168,1,100,35,173)
150 Here comes the directory listing.
-rwxr----- 1 0 502 76288 Jan 04 17:06 vsftpd-1.1.0-1.i386.rpm
226 Directory send OK.
ftp> get vsftpd-1.1.0-1.i386.rpm vsftpd-1.1.0-1.i386.rpm.tmp
local: vsftpd-1.1.0-1.i386.rpm.tmp remote: vsftpd-1.1.0-1.i386.rpm
227 Entering Passive Mode (192,168,1,100,44,156)
150 Opening BINARY mode data connection for vsftpd-1.1.0-1.i386.rpm (76288 bytes).
226 File send OK.
76288 bytes received in 0.499 secs (1.5e+02 Kbytes/sec)
ftp> exit
221 Goodbye.
[root@smallfry tmp]#
As expected, anonymous FTP fails.
[root@smallfry tmp]# ftp 192.168.1.100
Connected to 192.168.1.100 (192.168.1.100)
220 ready, dude (vsFTPd 1.1.0: beat me, break me)
Name (192.168.1.100:root): anonymous
331 Please specify the password.
Password:
530 Login incorrect.
Login failed.
ftp> quit
221 Goodbye.
[root@smallfry tmp]#
Now that testing is complete, you can make this a regular part of your FTP server's operation.
Conclusion
FTP is a very useful software application that can have enormous benefit to a Web site or to collaborative computing in which files need to be shared between business partners. Although insecure, it is universally accessible, because FTP clients are a part of all operating systems and Web browsers. If data encryption security is of great importance to you, then you should probably consider SCP as a possible alternative. You can find more information on it in Chapter 17, "Secure Remote Logins and File Copying".