Remote Administration of Linux Systems

Remote Administration of Linux Systems Introducing Remote Adnministration

Any system administrator who has to deal with two or more network servers will have to, at one point or another, solve the task of remote administration. Such an option can lead to better centralized control and supervising and help allocate (with preset limits) access for end-users.

Linux provides useful services for remote administration that even allow you to disconnect a monitor and keyboard from the server, leaving only a very secure system case, while keeping the full functionality and comfort as working with a local console.

In this article we will examine remote administration using the Red Hat Linux distribution. Path names and the format of configuration files in other distributions may vary.

The text console is the most useful and exploitable tool f 22222r1721w or system administration of Linux. It's not exigent upon communication bandwidth, but from the point of view of the user, for remote and local administration tasks, using the text console has absolutely the same effect.

For remote administration we can use serial COM ports or modem and network (TCP/IP) connections.

In the case of a connection via serial port we will use the mgetty package. The configuration files for mgetty are located in /etc/mgetty+sendfax. To perform a standard setup, we can easily do these next steps:

1. In the file mgetty.config, we need to add a description of the serial port:

port ttyS0
speed 115200
data-only y
init-chat "" ATZ OK ATL1M1 OK

where

• port ttyS0 - The device name (port name), to which we will connnect the modem
• speed 115200 - Port speed. It depends on hardware properties
• data-only y - Directive to mgetty, that modem will care only data, and not voice functions;
• init-chat "" ATZ OK ATL1M1 OK - We will re-define initialization parameters, in the request-answer format, where answer is the ability to receive commands and for modems it's just an empty line
6. In the file login.config, we need to check that following string exists (usually, it's set by default):

- /bin/login @

10. In /etc/inittab we will append a record like this one:

S0:345:respawn:/sbin/mgetty /dev/ttyS0

13. Re-load all the configuration from this file by typing

init q

It goes without saying that the modem needs to be connected to the PC and phone line and should be powered up at this moment.

Now, if anyone calls with any terminal software tool to the modem's telephone number, that user will see the login prompt on his display and a password prompt--just like the one we have on our local console.

In case if we need to work in text mode via TCP/IP we can use telnet, rsh (Remote SHell), or ssh (Secure SHell). I strongly do not recommend telnet and rsh as they are unprotected from illegal access or any hack attempts. ssh uses encryption during send/receive operations as well as digital signatures (certificates) to keep things much safer.

It is very important to note, however, that even with ssh, you should use only the latest versions available on your distributor's site, and check the digital signature and checksum of the ssh package before installation.

ssh consists of two parts: server (daemon) and client. The configuration files are located in the /etc/ssh directory. We also have the local system keys there.

Let's configure the server part, first of all. We will take a look at the simplest and not very "paranoid" variant--allowing for any hostname and password authentification, using any known encryption methods. For that, we need to follow these steps:

1. In the file /etc/sshd_config
• Disallow log in for root user (security condition):

o            
o             PermitRootLogin no

• Allow password authentification

o            
o             PasswordAuthentication yes

• Disallow "empty" passwords. In this case a user without a password can not login to the system

o            
o             PermitEmptyPasswords no

2. Allow access in the tcp_wrappers configuration section of /etc/hosts.allow

sshd: ALL

Instead of ALL (all hostnames) we can write a more detailed rule, for example:

sshd: 127.0.0.1 10.0. 192.168.0.34

This means that access is allowed only for localhost, network 10.0.0.0/255.255.0.0, and hostname 192.168.0.34.

5. To start up the server

service sshd start
sshd started: [ ολ ]

and let's set up the server to auto-start upon system reload

chkconfig sshd on

Now the server part is ready. Let's try to connect to it. On a workstation we can type:

ssh -l username host.com

where username is a login name of an existing user on the server and host.com is the name or an IP address of the server.

During the first startup ssh will display a warning that the host is unknown and it will give us a "finger-print" of the received key.

The authenticity of host 'host.com (1.2.3.4)' can't be established.
RSA key fingerprint is 2f:75:e7:8e:35:37:cf:17:c4:5d:ac:54:1f:ff:6f:9b.
Are you sure you want to continue connecting (yes/no)?

We need to answer yes. We will never see this message again (provided the key is not changed). Now, we will be prompted to enter a password, which will complete this operation.

We also can implement RSA key authentification as opposed to password authentification. For this purpose, with the help of ssh-keygen utility we will need to create keys (on client-PC):

ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:


Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
3d:9a:35:65:c4:36:11:8c:0a:43:28:e4:26:4f:19:59 [email protected]

We need to add the contents of the id_rsa.pub file to the /home/user/.ssh/authorize_keys file out on the server.

After all these operations and steps are completed, we can connect to the server without entering a password, which is very useful when creating certain kinds of scripts.

Personally, I do not recommend using modem access, as described above, because of some pertinent considerations. First of all, it's not secure--all data will be transferd via phone lines without any encryption (plain-text). Second, it's not suitable--you can only open one terminal per session. If you will need to gain access to a text console via modem, I suggest you to configure mgetty in AutoPPP modem. If using a PPP connection (like a dialup connection to an ISP) you can run the TCP/IP protocol and work with that.

For very paranoid users, we can configure authentification in ssh with the help of a digital signature (RSA key), which we can keep not on a diskette, but rather loaded onto a smart card. For detailed information about ssh configuration in this mode, you will need to read the corresponding equipment manuals and HOW-TOs.

As a rule, you don't need X Window on your server. It's pretty undesirable because of security reasons and certainly not for wasting server resources to support graphics. But in some cases, we will need a graphic console running on the server. A big example: installing and configuring Sybase SQL.

Sometimes an administrator needs to execute only a few specific graphic applications on the remote computer--for example, monitoring system or configuration utilities. In this case, we can easily use the method described here (which can also be automated with the help of shell scripts).

It is a pretty sure thing that you will have to have the Xfree-libs package pre-installed on both machines to handle this operation. YOu may also need additional libraries, depending on the application being accessed.

For example, on the administrator's computer X Window is running on the null graphic console (variable DISPLAY=:0.0). So, we will need to do the following:

1. Run xterm or any other similar application (konsole for KDE, gnome-terminal for GNOME, etc.)
2. Type the command

xhost +1.2.3.5

where 1.2.3.5 is the IP address of the remote computer.

5. Log in with telnet or ssh to remote computer
6. Type the command

xterm -display 1.2.3.4:0

where the argument display is the same as the variable DISPLAY and 1.2.3.4 is the IP address of localhost.

In some cases you may still need to set the variable DISPLAY.

There will be some cases when an administrator needs to get acess to a full graphical console, such as when he is working directly behind a remote computer. For this purpose we can use a VNC package - Virtual Network Computing. It allows us to open a remote PC desktop window on our local desktop.

To configure vnc we need to follow next steps:

On remote PC:

1. In file /etc/sysconfig/vncservers we need to append next string:

VNCSERVERS="0:user"

where user is the username on the remote computer and the number (0) is the number of the graphic console. We need to mention that if we have running X Window on the remote computer, this will mean that graphic console 0 is already used and we should use 1 (or higher).

4. Run the vncpasswd tool with username rights:

vncpasswd
Password:
Verify:

Note: If a password isn't set, vncserver will not executed properly.

9. Run the vncserver service and turn on the autoloading mode upon system load:

service vncserver start
starting vncserver: 0:user [ ολ ]
chkconfig vncserver on

On the administrator's workstation we can run vncviewer (this application requires X Window to be running). In the just-opened window we will type the IP address and number of the graphic console on the machine running vncserver. A new window with a running X Window session will appear.

vnc has a few notes, which we will need to remember.

• From the point of view of a standard application - vncserver (to be more exact, Xvnc) works absolutely like the X server. And, if we run any application on any remote computer via the telnet utility, it will be perfectly displayed with vncviewer. We just need to make sure to set the DISPLAY variable correctly (or application argument -display).
• During vncserver startup, the script $/.vnc/xstartup is executed, too. By default, this script executes /etc/X11/xinit/xinitrc, which means that the specified window manager will also be started (just like in a regular X server), but on the local console of the remote computer you will not be able to see anything. From one point of view, this will speed up the remote computer connection process but from another, we will waste the system resources of the remote computer.

Remote administration in a graphic console in Linux will always have very high risks and very bad ways of providing security. That's why we need to pay more attention to configuring firewalls and setting tighter user passwords.

On the remote computer, you must close all of the ports from 6000 and higher (the number of ports depends on the running X Window and/or vnc servers) to access from all hostnames except the administrator's. If, for some reason, you must use that access, then use the ssh utility for additional authentification and traffic data encryption.

For vnc we must take additional care about passwords, which can be set up with vncpassword. Never run vnc with root rights.

So, with a little effort installing and configuring some basic tools for remote administration, a system administrator can get some very powerful tools for remote access, which will lighten his load tremendously. Just don't neglect the security side.