O'Reilly logo

Fedora Linux by Chris Tyler

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Remote Management Using SSH

It’s often useful to be able to log in to a machine remotely to perform some management operation. To enable secure remote access, Fedora provides the Secure Shell (SSH).

How Do I Do That?

SSH consists of two components: ssh (the client) and sshd (the server). The server is configured automatically when Fedora is installed.

To connect to a Fedora system from another Fedora system (or another Linux system), run the ssh client, providing the remote username and hostname (or IP address) as a single argument (user @ host). For example, to log in to a host with the IP address 10.0.0.1 using the user ID jon:

$ ssh 
               
                  jon@10.0.0.1
               
The authenticity of host '10.0.0.1 (10.0.0.1)' can't be established.
RSA key fingerprint is 1d:dd:20:72:b1:0c:28:90:9a:ff:43:69:03:12:71:02.
Are you sure you want to continue connecting (yes/no)?
                   
               
               yes
Warning: Permanently added '10.0.0.1' (RSA) to the list of known hosts.
jon@10.0.0.1's password:
                   AnotherSecret
               
Last login: Tue Oct 25 23:13:40 2005 from london-office
$

The question about the authenticity of the remote host will be asked only the first time you connect. The fingerprint value displayed can be used to verify the identify of the remote host and ensure that you’re not being conned by a computer located between you and the computer you’re trying to connect to; if you’re really paranoid, you can check this value, but for most normal applications this isn’t necessary. The fingerprint is cached, though, so if it changes in the future you will be warned. It’s necessary to type in yes to confirm that you want to continue connecting; y won’t suffice.

Once you are connected to the remote machine, you can use the shell as you normally would.

Reducing the use of passwords

It’s possible to configure ssh to enable you to connect from your account on one machine to your account on another machine using public-key cryptography instead of a password. Unfortunately, this means that if your account on one machine is compromised, your account on the other machine will be compromised, too; to prevent this, you can use a passphrase, a master password that you enter once per session that permits you to connect multiple times to remote systems without entering a password each time.

To set this up, enter these commands on the client machine (i.e., the machine from which you will be connecting to the remote host):

$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/chris/.ssh/id_dsa):
                     Enter
                  
Enter passphrase (empty for no passphrase):
                     BigSecret
                  
Enter same passphrase again:
                     BigSecret
                  
Your identification has been saved in /home/chris/.ssh/id_dsa.
Your public key has been saved in /home/chris/.ssh/id_dsa.pub.
The key fingerprint is:
3a:f7:e8:88:59:fb:56:f7:0f:55:6b:fe:f6:ec:e2:2c chris@super
$ ssh 
                  
                     jon@remoteMachine
                   
                  "cat > ~/.ssh/authorized_keys" <~/.ssh/id_dsa.pub
jon@remoteMachine's password:
                      AnotherSecret
                  

Warning

The entire SSH security model revolves around the fact that the private key is private. If you permit access to your private key, the security is completely compromised.

This generates a public key and installs it on the remote system. If you will be connecting to multiple host systems, distribute your key to all of the systems by repeating the previous ssh command for each host.

Once the public key is installed on the remote host, you can use the ssh-add command to enter your passphrase:

$ ssh-add
Enter passphrase for /home/jon/.ssh/id_dsa: 
                     BigSecret
                  
Identity added: /home/jon/.ssh/id_dsa (/home/jon/.ssh/id_dsa)

Tip

If you’re not logged in to your Fedora system through the GUI, you will need to enter this command before using ssh-add:

$ eval $(ssh-agent)Agent pid 15431

When you log in using the GUI, Fedora starts the ssh-agent program automatically.

You can now connect to remote hosts without logging in:

$ ssh 
                  
                     jon@remoteMachine
                  
Last login: Wed Oct 26 00:20:29 2005 from toronto-office

If you wish to run just a single command, you can enter it on the ssh command line instead of logging in:

$ ssh 
                  
                     jon@remoteMachine
                   
                  cal 3 1967
     March 1967
Su Mo Tu We Th Fr Sa
          1  2  3  4
 5  6  7  8  9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31

Using graphical applications remotely

The -X option (uppercase) causes ssh to set up an encrypted tunnel for graphical X connections alongside the shell connection. This permits you to start graphical apps on the remote machine and display the output on the local machine (assuming that you’re connecting from a graphical session):

$ ssh -C -X 
                  
                     jon@10.0.0.1
                  
Last login: Wed Oct 26 00:31:42 2005 from parisoffice
$ 
                     oowriter 
                  

In order for this to work, the remote host must have X11Forwarding set to yes in its /etc/ssh/sshd_config file.

Warning

The -X option may cause remote X clients to be counted as untrusted from the point of view of the X server. This is perfect for most purposes, but if you want the remote client to be able to do screen captures (for example, if the remote application is the GIMP and you want to acquire a screenshot), substitute -Y for -X to configure the remote client as trusted.

How Does It Work?

SSH uses a variety of ciphers to encrypt your data as it travels across the network. The exact ciphers used can be configured in /etc/ssh/ssh_config (for the client) and /etc/ssh/sshd_config (for the server). Configuring a stronger cipher will provide better protection, but will use more CPU power and possibly reduce communication speed; the default settings are a good compromise between security and performance.

Public-key authentication relies upon the fact that two extremely large numbers—the public key and private key, which are derived mathematically from a single large random number, can be used with cryptographic formulas to encrypt and decrypt data. Anything encrypted with the public key can be decrypted only with the private key (not with the public key or any other number), and anything encrypted with the private key can be decrypted only with the public key. If the private key is kept secret and the public key is distributed to the whole world, then any message that can be decrypted by the public key must have been encrypted with the private key, proving the identity of the sender ( authentication); any message that is encrypted with the public key can only be decrypted by the private key, ensuring secrecy ( authorization).

In the case of SSH, the ssh-keygen command generates a public/private key pair, placing the private key in ~/.ssh/id_dsa and the public key in ~/.ssh/id_dsa.pub. When the public key is copied to the remote machine and placed in ~/.ssh/authorized_keys, an access request encrypted with the private key can be authenticated using the public key. If the public key is protected with a passphrase, you will be prompted for it each time you connect to a remote machine; to reduce this burden, the ssh-agent program can store your passphrase for you. The ssh-add command prompts you for your passphrase(s) and hands them over to ssh-agent (which is run automatically when the GUI starts up).

SSH is very susceptible to man-in-the-middle attacks, where a system between the client and server intercepts communication and presents itself as the client to the server, and the server to the client. However, this type of attack is a lot harder to set up than it would first appear and is rarely encountered. The caching of the host key (presented onscreen in summary format as the fingerprint) guards against this after the first contact between the client and server systems has been made.

What About...

...compressing data?

The -C option (note the capital letter!) causes ssh to compress data with gzip before encryption. This can significantly improve performance in some cases:

$ ssh -C 
                  
                     jon@10.0.0.1
                  

...connecting to a Fedora system from a Windows system using SSH?

To do this, you need a Windows SSH client. There are several available, but for most purposes I’d recommend the free (libre et gratuit) program Putty, downloadable from http://www.chiark.greenend.org.uk/~sgtatham/putty/. Of course, you won’t be able to use graphical applications unless you’ve also installed an X server on your windows system—but that’s not impossible (see http://x.cygwin.com/ for one possibility).

...connecting to a Fedora system from a Mac OS X system?

Mac OS X and most other Unix/Linux/BSD-based systems generally have an SSH client installed.

...connecting to my home system from another location?

If you’re using a broadband connection with a router or gateway, you’ll have to configure the router to pass incoming connections on the SSH port to your Fedora system. Use the router’s Applications and Gaming, Port Forwarding, or Servers configuration options to forward TCP/IP port 22 to your Fedora system. Then you can connect to the Fedora system by specifying the address of the gateway system in the ssh client arguments.

For example, if the external IP address of the gateway is 1.2.3.4, and the LAN IP address of your Fedora system is 10.0.0.1, configure the router to pass incoming connections on TCP/IP port 22 to 10.0.0.1, and then use the gateway IP address in the client arguments:

$ ssh 
                  
                     jon@1.2.3.4
                  

Warning

You may also need to configure Fedora’s firewall to permit SSH connections.

...using public/private keys without a passphrase?

Just leave the passphrase blank when running ssh-keygen. This is convenient because you won’t need to use ssh-agent and ssh-add, and can always log in to remote systems without the passphrase. However, it’s also dangerous because any attacker who obtains access to your local account will automatically gain access to your remote accounts as well.

Where Can I Learn More?

  • The OpenSSH web site: http://openssh.org/

  • The manpages for ssh, sshd, ssh_config, sshd_config, ssh-agent, ssh-add, and ssh-keygen

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required