Author: Brian L. Shaver
SSH
Yes, you should stop using insecure remote login methods like Telnet and rlogin. We know that much, but SSH has other features aside from encryption that make it worth using.
I work on a large network of Linux and Solaris systems, and I often find it advantageous to display an application I am running remotely back to my laptop. After upgrading my laptop to a newer Linux distribution, I was at first bewildered at my remote display difficulties.
Despite executing xhost +, my remote display connections were being rejected because my new distribution included a more secure configuration for GDM. The gdm.conf contained DisallowTCP=true, which causes the X server to be started with a -nolisten option, thereby preventing my conventional remote display attempts.
While one could quickly change this parameter in gdm.conf, I used this as motivation to discover what alternative remote display methods should be used instead. What I arrived at was ssh, the foundation for all your secure remote connection needs.
OpenSSH has two configuration options for forwarding X11 connections. If you use -X (ForwardX11), your connection will be secure, but restrictions placed on clients may prevent some applications from functioning properly. The ForwardX11Trusted option, -Y, will tell SSH to consider the remote host to be trusted, allowing client applications complete access to the X server.
Be aware that using the trusted option carries some security risks. This option should only be used in connections to secure hosts.
Either option can be specified on the command line, or in your ~/.ssh/config file. The system you are connecting to needs to have X11Forwarding yes in its sshd_config file.
Using the -Y option has some benefits for remote X11 applications. When using -Y, xhost is not necessary, because the connection will be made directly to the X server from your local machine. You do not need to set your DISPLAY environment variable; it will be set for you. In fact, if you have any logic in your .bash_profile to set DISPLAY, you will want to get rid of it because it will likely clobber the setting made by the ssh connection. And of course, as with all the SSH applications, your transmissions will be encrypted.
One thing to be aware of when using SSH for X11 (or any other) port forwarding — you will be unable to terminate the SSH connection until all port forwarding connections are closed. This can sometimes prove tricky if connections are left to accumulate over an extended period of time. You can see a list of open connections, which will include a record of the open port forwarding connections, using the escape sequence ~#.
GNOME Display Manager (GDM)
The GNOME Display Manager (GDM) is the default login screen for many distributions, but it does a lot more than simply log you in. GDM has some useful advanced features.
Ever need to login as a different user, but you do not want to logout of your current session? Perhaps you are working on some large software installation, or trying to assist a user with desktop environment problems. Chances are you do not want to close all of your current applications, or get up out of your chair and walk to someone’s desk. Well, you may not have to.
If you are running GNOME, you will most likely have the New Login menu option, which will fire up another gdm process while leaving your current session completely intact. The first X session uses tty7 (Ctrl+Alt+F7), this new session will be on tty8 (Ctrl+Alt+F8).
You can switch back and forth between your two desktop sessions the same way you switch between any of the virtual consoles. When you log out of the second session, it will terminate the gdm process and you will be returned to your original session on tty7.
If you’re not running GNOME, or otherwise do not have the New Login menu option, you can run gdmflexiserver from the command line for the same effect.
Okay, so you have a new login screen. Nobody says you have to log in to the same box. GDM supports the classic remote desktop protocol, XDMCP. From the login screen, look for the option Run XDMCP Chooser. If you do not see it, your GDM may not be configured to allow you to run the chooser (ChooserButton=true) or your current GDM theme may not support the more advanced GDM features.
Launch gdmsetup to check these options. You can enable the XDMCP chooser from the Security tab, and you can switch your GDM theme from the Graphical Greeter tab. You are looking for a theme that offers an Action or System menu to access the more advanced GDM features. If you suspect your theme may be to blame, try the basic Happy GNOME theme. You can peruse additional theme options at art.gnome.org; however, I’ve found many themes do not support advanced GDM features. You may also find it helpful to allow configuration to be run from the login screen, at least while you are tweaking your GDM setup. After making some changes, you can use the gdmflexiserver to immediately see the effects, which allows you to catch any problems without having to reboot.
While the graphical gdmsetup application offers many options, even more features are available if you dive into your /etc/X11/gdm/gdm.conf configuration file. Through the gdm.conf, you can configure whether the chooser should broadcast XDMCP queries searching for responsive hosts, specify a specific list of hosts to query, allow users to enter their own desired host names, and even add friendly images for your various hosts. Like many complex Linux configuration files, the gdm.conf is well commented, making it easy to read and modify effectively.
If you have hosts with XDMCP enabled, you will want to block UDP port 177 on your firewall to avoid potential denial of service attacks. Nevertheless, enabling XDMCP on some systems may be worth it if your network is secure. Since XDMCP is a standard protocol, you can use it to connect with other non-Linux/non-GDM systems. For example, I use it to connect to my old Solaris 8 boxes. This feature could also serve as an inexpensive software KVM switch for a rack of servers (as long as they keep running well).
Even if you decide not to allow the use of XDMCP on your network, the chooser function is a valuable way to quickly check your entire network to see if any hosts are allowing remote XDMCP connections. If your network includes some legacy systems, they may already have XDMCP enabled.
Yum
The Yellow Dog Updater Modified (Yum), is an RPM package management utility. I use the yum utility to search for packages I would like to install on my home systems, and to search for updates to packages I already have installed. If you’re like me, and just too paranoid to allow anything to automatically update your systems, you can use Yum to add automation while keeping some control.
For my home systems, I pretty much want to install all updates, but I like to know what I’m installing and choose when to install it. For instance, if I’m installing a new kernel version, I need to manually install some additional kernel modules on the next reboot. So I use the following script to send myself an email whenever updates are available. Just drop the script in your /etc/cron.daily directory.
#!/bin/sh /usr/bin/yum check-update > /tmp/cu$$ 2>&1 # # look at return value from check-update, # - from yum man page: # 0 - no update # 100 updates pending # RET=$? if [ $RET -eq 100 ]; then cat /tmp/cu$$ | mail -s "system updates" root fi rm /tmp/cu$$ > /dev/null 2>&1
For systems at the office, you might want to take a different approach. Perhaps you want to install packages only after first trying them on a test system, or you might install only updates that fix known issues or address security concerns. You may even have some custom packages which you need to maintain on all your business systems. For any of these situations, a Yum repository is a handy solution.
You can configure a server to host your own Yum repository and place only the packages you wish to deploy to all systems in the repository. Then configure your client systems to automatically update from your custom repository nightly, weekly, or whenever you see fit.
You will find a number of articles on setting up your own Yum repository for various purposes (e.g. “How to run your own yum repository“), but you should keep a few points in mind when reading these articles.
First, if you are using Yum version 2.0.X or earlier on client systems, use yum-arch to create the repository, but for version 2.2.X or newer, createrepo is the utility to use. The createrepo utility is probably not part of your Yum installation, but it is available as a separate package.
If you need to support older and newer clients, you can run yum-arch and createrepo on the same repository. Each utility uses a different structure to store the RPM header information.
You do not have to host your Yum repository with a Web server; Yum repositories can use “file:/” URLs as well. This allows you to use a network drive to host the repository for your local network.
After you create your repository, update either the /etc/yum.conf or add a file to the /etc/yum.repos.d directory defining your local repository.
[local] name=Local Packages baseurl=file:<path> enabled=1
After modifying your Yum configuration, run an update to verify that it works, and then set up a cron job to continue pulling updates from your new repository.
Summary
Over the past few months, the time I have spent getting to know more about ssh, gdm, and yum has paid big dividends. It never hurts to put some shiny new tools in your toolbox.
Let us know about your most valuable utilities (there need not be 10 of them), and if we publish your work, we’ll pay you $100.
