Belits Computer Systems

2.6. Logging in and initial server configuration.

If network configuration is incomplete at this point, or has to be changed, the initial configuration should be performed from a console. In some configurations it is necessary to press Enter once or twice before logging in at the login prompt.

Enter the username at the login prompt, press Enter and enter the password at the prompt (Linux and FreeBSD do not display any password entry feedback on the console), then press Enter again.

Fig. 16: User "user" logged in on the serial console

Preconfigured username and password should be included in the configuration sheet. If there are separate entries for system administrator and a regular user in the configuration sheet, log in as a regular user first on Linux or FreeBSD, and as an administrator on a Windows-based system.

If the only username supplied is "root" (on Linux or FreeBSD) or "Administrator" (on Windows), this is the administrator user, and logging in as that user is sufficient to get access to the system configuration.

Fig. 17: root login

If there is another supplied username, this is a regular user with sudo or su access. To perform system administration tasks on Linux or FreeBSD after logging in as that user, either:

• If there is a separate "root" user, in shell enter "su", then root user's password at the password prompt.
• If there is no root password supplied with the system, this means that computer is configured with disabled root login, and supplied user ID has sudo access. Enter "sudo sh", then enter the regular user's password at the password prompt.

The shell prompt will change to include a '#' sign, indicating that it is running as a root user.

Fig. 18: su command is used to run the root user's shell

Enter "exit" to return back from the privileged shell.

Linux and FreeBSD may have ssh, xdm/gdm/kdm, VNC and other remote login services preconfigured. Windows-based systems may have Terminal Services, VNC and various utilities from Cygwin installed for similar purpose. Refer to the configuration sheet to determine, which ones are installed and enable/disable/restrict them as necessary.

The particular utilities used to perform system administration tasks vary between operating systems, distributions and versions. Use the particular operating system's manual to determine how to configure local and network-attached storage/RAID, network parameters, services, users, authentication, etc.

If necessary, use text editor, utilities and other system administration tools to configure network, users and services. Change users' passwords from their default values. Always use secure passwords that can not be trivially guessed using dictionary attacks or personal data. When configuring remote login, network access, services, encryption and authentication keys, passwords, etc., follow a reasonable security policy. On any computer that should be accessed over the network enable a non-administrator user that has access to su, sudo or other utility that can allow him an administrator access after entering the password, and login as that user instead of root.

After the initial configuration is done, you may need to reboot the system while monitoring output on the console. In Linux and FreeBSD this is done by entering "reboot" (or "halt" to shut down the box) in the root shell, in Windows it's an item in the Start menu.

After shutdown, the server will turn off its power supply. If you use a serial console, the messages will remain on it while the server is off. A reboot command will cause the server to immediately restart instead of turning off.

Fig. 19: Server is powered off

2.7. Logging in remotely over the network.

After the server is properly configured on the network, and remote login services such as ssh, xdm/gdm/kdm, VNC or Windows Terminal Services are enabled, you can login to the server remotely over the network instead of using a local VGA + keyboard or serial console. The most common protocols used to login to the server remotely over the network are:

to Linux and FreeBSD:	to Microsoft Windows:
ssh X Window System (X11) VNC	Windows Terminal Services VNC ssh (with Cygwin installed)

Once server and client software is configured, the server becomes accessible from any point on the network that can establish a connection to it. ssh provides an encrypted link that allows to access the server through a remote terminal in a secure manner, with multiple simultaneous sessions. It also allows to forward TCP connections for other software, and to provide an encrypted link for X applications. Those features made ssh the most common and convenient way of accessing remote servers running Linux and FreeBSD.

Windows-based systems commonly use Windows Terminal Services or VNC.

Additionally, Linux and FreeBSD often are configured with xdm/gdm/kdm X display managers that allow users to login from other computers, and run full X sessions over the network. If local network segment is fast and secure (what is usually the case with switched Gigabit Ethernet), this allows to offload graphics-related processing to desktops/workstations, while running multiple users' desktop/workstation-oriented software on the server, as shown on Fig. 22 - 25.

To login to the server remotely, run the client application on the desktop/workstation computer, supplying it the server's address and, if necessary, username. Once logged in, user's access is similar to the access from a console, with three notable exceptions:

1. Multiple connections are allowed with separate, unrelated sessions.
2. Text is sent at the speed of the network, that is thousands times higher than the speed of a serial port, so the user doesn't have to wait for scrolling and screen refresh.
3. It's possible to reconfigure the network in a manner that hangs the connection, or locks the user out. When this happens, the system administrator should either use another computer that still has access to the server, to reverse or complete the configuration change, or use a console (serial or VGA + keyboard) to login.

To login using ssh, run ssh client and supply the hostname or IP address of the server, and user name on the server. If ssh client never connected to the particular host before as this user, it will ask to confirm installation of the server's public key — if confirmed, the key will be stored and used to confirm the identity of the host, to prevent man-in-the-middle attacks in the future. To authenticate the user for a server, client's public key may be configured on the server in the list of authorized keys, or password authentication over the encrypted channel will be used every time the user logs in.

In the example on Fig. 20, a user serveradmin on a monitoring computer venus logs in to the server at the address 192.168.10.97 as the user user. This is his first connection to the server, so the client asks the user to confirm the server's key, and requests a password to authenticate the user on the server. User interface varies between clients, and may include preconfigured sessions, options, dialog boxes instead of text prompts, etc.

Fig. 20: Remote login over ssh

X11 and VNC allow users to run graphical environments and applications, with physical display device on a client computer, and applications running on the server (or on multiple servers).

If the server runs a display manager (xdm, kdm or gdm) that accepts client connections, it allows the user to login to the server (that would run X11 client applications in X11 terminology) in a manner similar to the login on the console:

On the client computer the user runs X server software. In the following example the user runs Xorg X server as root on a Linux computer, connecting to the display manager on the host with IP address 192.168.10.97. The command line places X server in a background, and exit the root shell:

Fig. 21: Running X server on the client computer

X11 server program starts, initializes a new screen, connects to gdm (display manager) running on a server over the network. gdm displays a login screen:

Fig. 22: GDM login screen, as seen from a remote computer

After the user enters or chooses the username and types his password, desktop environment is started on the server, displaying its user interface on the remote computer. Modern X11 implementations use various kinds of accelerated graphics, including OpenGL 3D acceleration, and allow users to combine resources of the server with graphical capabilities of desktops and workstations.

Usually X servers are not started manually from a command line but are included in automatic startup scripts on users' workstations, or users are given scripts and permissions to run them with sudo.

There are many different desktop environments for X11 — in this example the user on the server had configured GNOME desktop to run by default after he is logged in:

Fig. 23: GNOME desktop environment on Debian Linux (initial configuration)

GNOME is one of the most commonly used desktop environments on Linux. In Fig. 24 - 25 the same GNOME environment is configured on the server with a different theme, various monitoring applets are added to the panel, and typical GUI applications are started:

Fig. 24: Calculator running in the GNOME environment on the server.

Fig. 25: OpenOffice.org Writer running in GNOME environment on the server.

To end X11 session, log out from the desktop environment (in GNOME it's “Desktop” → “Log Out” in menu) and wait for gdm login screen to appear. That will ensure that all applications and services in X11 session were cleanly shut down.

VNC is used to access servers remotely in a manner similar to remote GUI provided by X11. While X11 is primarily designed as an interface to accelerated graphics consoles over a fast, low-latency network, VNC is optimized for potentially unreliable, slow, high-latency connections, and has limited graphics optimization. It allows connecting, disconnecting and reconnecting to an existing session, sharing access to the same session between multiple users, and other features useful for remote maintenance and assistance. In a typical setup under Linux or FreeBSD VNC server automatically runs a lightweight session that remote users can connect to. In Windows VNC allows shared access to the local screen (that may be real, or virtual under VMware or other virtualization framework).

In the following example VNC server is started on the server from the serial console. Before starting the server (vnc4server executable) user runs vncpasswd to assign the password used for authentication of remote users.

Fig. 26: VNC server program is started on a server

Then the user can log out and disconnect from the console — VNC server at this point is running X session.

To remotely attach to VNC, the user can run VNC client and supply the hostname or IP address, and a display number. Client connects to the server and asks for the password to authenticate with it:

Fig. 27: VNC client program started on a client computer under GNOME environment

After successful authentication, VNC client displays a window with the remote desktop. In the example on Fig. 28 the client computer runs GNOME under Ubuntu Linux, server runs Xfce session under Debian Linux. VNC window, containing the remote desktop, is seen as one of the application windows within the local GNOME environment. If necessary, VNC client can be switched into a fullscreen mode.

Fig. 28: VNC client is connected to VNC server, running Xfce session

VNC session can be disconnected and reconnected again, with all programs continuing running. VNC also is the most platform-independent remote GUI — both servers and clients run on Windows, MacOS X, Linux, FreeBSD, and various Unix variants.

Prev Home Up Next