By Robert Chase on Mar 26, 2014
In a previous blog, Oracle Linux Tips and Tricks, I covered alternative ways to use SSH. In this article, I will cover some additional tips and tricks for using SSH for remote access, as well as some other ways to connect remotely to a server.
SSH's primary use is for remote access to hosts. SSH is not only able to provide us a terminal interface to a server, it's also able to provide us a transport for a graphical interface. In order to utilize this functionality, we must have an X server running on our local workstation. On a Linux workstation with a graphical environment, this functionality is built in. On other systems, such as a Windows machine or a Mac, this functionality is not built in. Both XQuartz on the Mac and MobaXTerm are X servers for these platforms. There are also a number of other open source and paid products available for both platforms.
Once you have an acceptable X server installed on your local workstation, you can connect with SSH using the following
ssh command. The
-X enables X11 forwarding for the connection. Keep in mind that the X11 forwarding is based on the user who originally connected. Logging in with one user and then using
sudo often will not work, depending on the permissions and ownership needed to complete a task.
[user@laptop ~]$ ssh -X 10.0.0.12
Once you authenticate, you drop directly to a standard prompt. If you look closely, though, and examine the environment variables in your terminal, you will find an additional environment variable that has the IP address of your workstation. You can examine your environment variables using the
Now you can launch an application that has a graphical interface, and the interface will be displayed on your local workstation. The following example will launch
gedit. The ampersand symbol is useful for forking the process in the background so we can retain the use of our terminal.
[user@remotehost ~]$ gedit &
Using X11 connections over SSH can be quite useful for using application installers that are graphical, such as the Oracle Universal Installer for Oracle Database.
screen application is a great compliment to SSH and is quite useful for sharing an SSH session with another user. Because of the way
screen preserves sessions for the user, it is also great for high-latency network connections that have frequent disconnects and for maintaining sessions that time out due to security policies. With a regular SSH connection, if you are disconnected, any processes that were running are not preserved. Unlike SSH, the
screen application keeps the session alive so it can be connected to again later.
One of the simplest things you can do with
screen is share a session. You can launch
screen on the terminal you wish to share by issuing the
screen command. Once you do this, a new shell is running inside of
screen. Another user can log in to the same machine and use the command
screen -x to be immediately connected to your shell. They see everything you type. Even if you disconnect from the machine on either terminal, the shell will continue to run. This can be quite useful for sharing a terminal for a demonstration in a remote office or for running a terminal-based console that is shared between many users.
To see all of the active screen sessions, you can use
screen -list, which will show active and detached sessions. To connect to a detached session, you can use
screen -r and the
pid.session name listed in the
screen -list output. In the following example, there are five screen sessions running. One of them is detached.
[user@server ~]$ screen -list There are screens on: 24565.pts-1.server (Attached) 24581.pts-2.server (Attached) 24597.pts-3.server (Attached) 24549.pts-0.server (Attached) 24613.pts-4.server (Detached) 5 Sockets in /var/run/screen/S-user.
screen -x can be used to connect to a currently attached session. In the following example, a connection to session 24565 is made:
[user@server ~]$ screen -x 24565
If you need access to a full graphical desktop environment remotely, there are a number of packages that can accomplish this. The package
tigervnc-server is useful for connections to a remote machine providing a full Linux desktop experience. To set up and install the package, perform the following steps.
First, run the following command to install the package:
[root@server ~]# yum install tigervnc-server
Once the package is installed, you need to edit the file
VNCSERVERS line establishes the user accounts that you want to enable the VNC server for and their display number. In the example below, the user
bob is configured for display 2 and the user
sue is configured for display 3. The
VNCSERVERARGS[#] section allows you to specify options for each display. In this example, we are specifying a 1280 x 1024 resolution for display 2 and a 1024 x 768 resolution for display 3:
VNCSERVERS="2:bob 3:sue" VNCSERVERARGS="-geometry 1280x1024 " VNCSERVERARGS="-geometry 1024x768"
/etc/sysconfig/vncservers file has been edited, you need to set passwords for each user account. This is accomplished with the
vncpasswd command. In the following example, the user
bob sets a password using the
[bob@server ~]$ vncpasswd Password: Verify:
Once the package is installed, the configuration file is edited, and passwords are set, you are ready to turn on the
vncserver service. The following two commands start the service and set the service to start automatically at the next boot:
chkconfig vncserver on service vncserver start
Once configured and running, you can connect to your Linux system using a standard VNC client. When connecting, be sure to specify the display and password credentials that are needed in order to connect.
I hope these tips and tricks have been useful and that you will take advantage of some of them in the course of your day. We will be publishing more of these tips-and-tricks articles in the future. Feel free to leave a comment for further topics that you would like to see in this series.
About the Author
Robert Chase is a member of the Oracle Linux product management team. He has been involved with Linux and open source software since 1996. He has worked with systems as small as embedded devices and with large supercomputer-class hardware.
About the Photograph
Photograph taken by Rick Ramsey in Durango in the Fall of 2012