Mastering Root Logins, Selectively Blocking Server Access, Preventing a bash History

My server will not let me ssh in as root, but I need to copy over files while preserving ownerships and permissions. Can I still do this?


My server will not let me ssh in as root, but I need to copy over files while preserving ownerships and permissions. Can I still do this?

Absolutely. Many ssh installations default to disallowing ssh logins as root for security reasons. (Actually, most inetd installations restrict this also, which generally restricts root from remote ftp, telnet, and other inetd-started services.)

However, you can copy files while preserving permissions without scping as root. The simplest way to do this is with the tar command. If you run the command as root, tar should default to preserving ownerships and permissions of archived files. Create and extract the tar file as root and copy it over as any user.

You may also allow root logins over ssh. The sshd daemon is generally configured by editing the file /etc/ssh/ sshd_config. There is a configuration directive named PermitRootLogin that defaults to No in many installations. Changing this to Yes allows root logins via ssh.

Many system administrators will want to limit the typing of the root password as much as possible, including root logins. Even though sshd encrypts all transmission, there are very good reasons to avoid logging in as the superuser.

You can avoid root logins altogether by continuing to deny remote (telnet, ftp, ssh) root authentication and using the sudo program to gain shells with superuser privileges. sudo allows certain users to run specified programs as root. Your distribution likely includes sudo as an installation option; you should see http://www.courtesan.com/sudo to find more information about this program.

Once you have set up your box to avoid using the root password altogether, you should change it to a long password consisting of many random characters. Ideally, you’ll never have to use it again.


When I run a process in the background, it terminates when the shell goes away. Is there a way to keep it running without the shell?

The command nohup will execute a program, instruct it to ignore all hang-up signals and allow it to run after you log out. The syntax is:

# nohup command -args &

(Essentially, tack a nohup before the normal command line and don’t forget to background the task.)

nohup will write all output (including stderr) to a file called nohup.out, located in either the current directory or your home directory.


I would like to disallow all connections to my server from all but a specific list of IP addresses. Can a server properly operate under these conditions? If so, how do I set this up?

A server can definitely operate under these conditions, although there may be some side effects you haven’t thought of. For instance, blocking all access, except for specific hosts, will stop you from using the server as a client for http, ftp, ssh, or any other network service without first explicitly allowing the remote machine access to talk back.

If you don’t need to service connections from unknown clients, however, this is a great way to help secure a server. I’ll explain this using ipchains, the Linux command-line firewall configurator that works with Linux 2.2 series kernels. There is also a backwards compatible ipchains replacement in Linux 2.4.

ipchains is commonly used on Linux firewalls, which are placed in front of several other boxes on a network for security purposes. All traffic is routed through the firewall, following delivery rules for source and destination as set on it. ipchains may also be used as a “personal firewall” on a server, regulating network traffic. The filter we will be setting up is called a “packet filter.”

First, you will need to make sure that Linux firewalling is compiled into your kernel. In the makefile, under “Networking Options,” you should turn on “Network Firewalls” and “IP: Firewalling.”

You’ll also need the ipchains package, which should be available in every Linux distribution. If you don’t have this compiled in your kernel, running ipchains will result in the appropriate error message.

I’ll go over the basic set of commands for this simple task. To learn more about ipchains and Linux firewalls, visit the appropriate HOWTO at http://netfilter.kernelnotes.org/ipchains/HOWTO.html.

We’ll be configuring the machine to REJECT all input to the machine except from specific IP addresses.

To clear ipchains of all current input rules, first type:

# ipchains -F input

Next, we need to set the default input rule to reject all incoming packets. Note: If you are running this one command at a time, this must be run from a local terminal, otherwise you will lose your remote session due to the ipchains rule (makes sense, doesn’t it?). If you must make these modifications from a remote terminal, you should put these commands in a shell script and run them all at once. (It is still a good idea to test this at a local terminal, just in case.) To reject all incoming packets, type the following:

# ipchains -A input -s 0/0 -d 0/0 -j REJECT

You can now explicitly list machines from which ipchains should allow packets. I’ll use my server, dtype.org (, as the example machine in the following command:

# ipchains -A input -s -d 0/0 -j ACCEPT

You can continue to add hosts in this manner.

Eventually, you’ll probably want a script that sets up these rules at boot time. That script should be placed in the appropriate init directory for your distribution (probably /etc/rc.d/rc.local or /etc/rc.boot). Listing One contains a sample script.

Listing One: Sample ipchains Script

/sbin/ipchains -F input
/sbin/ipchains -A input -s 0/0 -d 0/0 -j REJECT
/sbin/ipchains -A input -s -d 0/0 -j ACCEPT
/sbin/ipchains -A input -s -d 0/0 -j ACCEPT

As time progresses, you can continue to add hosts that need access. There are many other options for ipchains; this is a very basic example of its usage. Please read the ipchains HOWTO for further information.

To complete this security exercise, take the final step and place your server on a completely switched network that you trust (at least to a reasonable degree).

Assuming all of the hosts that you explicitly listed are trusted, the remaining security concern is spoofed IP addresses. Verifying your network up to the routers of a major provider should impart a small peace of mind. The traceroute tool can provide you with a list of routers between you and the outside world.


For privacy reasons, I don’t want bash to keep a history of the commands I’ve run on a server. When I delete my .bash_history file, it keeps reappearing. Can I stop this?

There are a few ways you can stop bash from keeping a valid history file. On most installations, the example I outline below will work; however, it will still be possible for a system administrator to keep information about your use.

In short, logging into a system implies some trust of the system administrator. Deleting a shell history file may provide some level of privacy comfort, but it is not a way of keeping actions hidden from capable system administrators.

bash reads the ~/.bash_history file once upon starting and normally writes history to it upon exit. Deleting the file will not get rid of it because as soon as you exit the shell a new one will be written.

You can prevent bash from writing to this file upon shell exit by setting the HISTFILE environment variable with the following command:

# export HISTFILE=”

If you place this export command in ~/.bash_profile and delete the history file, you should be rid of the written history record.

Another good way to do this is to create a symlink from the history file to /dev/null, as follows:

# rm ~/.bash_history

This will keep the file around but ensure that it is always empty.

If you want to clear the history from the current shell, try using the bash built-in command, history. The -c option will delete all history entries from the running bash shell:

# history -c

On the other hand, if you are a system administrator and require logs of user behavior on a system, you may consider a logging program such as snoopy (http://www.citi.umich.edu/u/marius/snoopy/). If you are going to be logging user activity in this manner though, it is probably polite to let them know that this is your system policy.

Drew Streib is a coder, writer, and free software advocate with VA Linux Systems. He was a founding developer of SourceForge.net and can be reached at tech@linux-mag.com.

Comments are closed.