Introduction

One of the most popular file transfer and remote login Linux applications is OpenSSH,
which provides a number of ways to create encrypted remote terminal and file transfer
connections between clients and servers. The OpenSSH Secure Copy (SCP) and Secure
FTP (SFTP) programs are secure replacements for FTP, and Secure Shell (SSH) is often
used as a stealthy alternative to TELNET. OpenSSH isn't limited to Linux; SSH and SCP
clients are available for most operating systems including Windows.

A Quick Introduction To SSH Encryption

Data encryption is accomplished by using special mathematical equations to scramble the
bits in a data stream to make it unreadable to anyone who does not have access to the
corresponding decryption equation. The process is usually made even harder through the
use of an encryption key that is used to modify the way the equations do the scrambling.
You can recover the original data only if you have access to this key and the
corresponding programs. Data encryption helps to prevent unauthorized users from
having access to the data.

SSH uses the concept of randomly generated private and public keys to do its encryption.
The keys are usually created only once, but you have the option of regenerating them
should they become compromised.

A successful exchange of encrypted data requires the receiver to have a copy of the
sender's public key beforehand. Here's how it's done with SSH.

When you log into an SSH server, you are prompted as to whether you want to accept the
download of the server's public key before you can proceed. The SSH client's key is
uploaded to the server at the same time. This creates a situation in which the computers at
each end of the SSH connection have each other's keys and are able to decrypt the data
sent from the other end of the encrypted link or "tunnel".

All the public keys that an SSH client's Linux user encounters are stored in a file named
~/.ssh/known_hosts along with the IP address that provided it. If a key and IP address no
longer match, then SSH knows that something is wrong. For example, reinstalling the
operating system or upgrading the SSH application might regenerate the keys. Of course,
keys changes can be caused by someone trying some sort of cyber attack, as well. Always
investigate changes to be safe. Your server's own public and private SSH keys are stored
in the /etc/ssh/ directory.

Note: The .ssh directory is a hidden directory, as are all files and directories whose
names begin with a period. The ls -a command lists all normal and hidden files in a
directory. The ~/ notation is a universally accepted way of referring to your home
directory and is recognized by all Linux commands.
Linux uses other key files also to provide the capability of password-less logins and file
copying to remote servers using SSH and SCP. In this case, the SSH connection is
established, then the client automatically sends its public key which the server uses to
match against a predefined list in the user's directory. If there is a match then the login is
authorized. These files are also stored in your ~/.ssh directory and need to be specially
generated. The id_dsa and id_dsa.pub files are your private and public keys respectively,
and authorized_keys stores all the authorized public keys from remote hosts that may log
into your account without the need for passwords (more on this later).

Starting OpenSSH
OpenSSH is installed by default during Linux installations. With Ubuntu / Debian, this
may not be the case and it will have to be installed after the initial installation. The apt-
get install ssh command will be sufficient to activate SSH using these latter
mentioned distributions.

Because SSH and SCP are part of the same application, they share the same configuration
file and are governed by the same /etc/init.d/sshd startup script.

You can configure SSH to start at boot by using the chkconfig command when running
Fedora / Redhat or with the sysv-rc-conf command with Debian / Ubuntu.

[root@bigboy tmp]# chkconfig sshd on

You can also start, stop, and restart SSH after booting by running the sshd initialization
script.

[root@bigboy tmp]# service sshd start

[root@bigboy tmp]# service sshd stop
[root@bigboy tmp]# service sshd restart

Remember to restart the SSH process every time you make a change to the configuration
files for the changes to take effect on the running process.

Testing The Status of SSH

You can test whether the SSH process is running with

[root@bigboy tmp]# pgrep sshd

You should get a response of plain old process ID numbers.

The /etc/ssh/sshd_config File

The SSH configuration file is called /etc/ssh/sshd_config. By default SSH listens on all
your NICs and uses TCP port 22. Take a look at a snippet from configuration:

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

#Port 22
#Protocol 2,1

#ListenAddress 0.0.0.0
#ListenAddress ::

SSH Versions 1 and 2

The original encryption scheme of SSH was adequate for its time but was eventually
found to have a number of limitations. The answer to these was version 2. Always force
your systems to operate exclusively with version 2 by setting the protocol statement in
the /etc/ssh/sshd_config file to 2. Remember to restart SSH to make this take effect.

#
# File: /etc/ssh/sshd_config
#

Protocol 2

How To Change The TCP Port On Which SSH Listens

If you are afraid of people trying to hack in on a well known TCP port, then you can
change port 22 to a location that won't interfere with other applications on your system,
such as port 435. This is a rudimentary precaution only, because good network scanning
programs can detect SSH running on alternative ports.

What you need to do is:

1) Use the netstat command to make sure your system isn't listening on port 435, using
grep to filter out everything that doesn't have the string "435":

[root@bigboy root]# netstat -an | grep 435

[root@bigboy root]#

2) No response allows us to proceed. Change the Port line in /etc/ssh/sshd_config to

mention 435 and remove the # at the beginning of the line. If port 435 is being used, pick
another port and try again.

Port 435
3) Restart SSH:

[root@bigboy tmp]# service sshd restart

4) Check to ensure SSH is running on the new port:

[root@bigboy root]# netstat -an | grep 435

tcp 0 0 192.168.1.100:435 0.0.0.0:* LISTEN
[root@bigboy root]#

Next you'll discover how to actually login to systems using SSH.

Using SSH To Login To A Remote

Machine
Using SSH is similar to Telnet. To login from another Linux box use the ssh command
with a -l to specify the username you wish to login as. If you leave out the -l, your
username will not change. Here are some examples for a server named smallfry in your
/etc/hosts file.

If you are user root and you want to log in to smallfry as yourself, use the command

[root@bigboy tmp]# ssh smallfry

User root can also log in to Smallfry as user peter via the default port 22:

[root@bigboy tmp]# ssh -l peter smallfry

or via port 435 using the username@remote_server alternative login format:

[root@bigboy tmp]# ssh -p 435 peter@smallfry

What To Expect With Your First Login

The first time you log in, you get a warning message saying that the remote host doesn't
know about your machine and prompting you to store a copy of the remote host's SSH
identification keys on your local machine. It will look something like this:

[root@bigboy tmp]# ssh smallfry

The authenticity of host 'smallfry (smallfry)' can't be established.
RSA key fingerprint is 5d:d2:f5:21:fa:07:64:0d:63:1b:3b:ee:a6:58:58:bb.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'smallfry' (RSA) to the list of known hosts.
root@smallfry's password:
Last login: Thu Nov 14 10:18:45 2002 from 192.168.1.98
No mail.
[root@smallfry tmp]#

The key is stored in your ~/.ssh/known_hosts file and you should never be prompted for
this again.

SSH Failures Due To Linux Reinstallations

If Linux or SSH is reinstalled on the remote server then the keys are regenerated and your
SSH client will detect that this new key doesn't match the saved value in the known_hosts
file. The SSH client will fail giving an error like this, erring on the side of caution to alert
you to the possibility of a form of hacking attack.

[root@bigboy tmp]# ssh 192.168.1.102

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle
attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
5d:d2:f5:21:fa:07:64:0d:63:1b:3b:ee:a6:58:58:bb.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this
message.
Offending key in /root/.ssh/known_hosts:2
RSA host key for 192.168.1.102 has changed and you have requested
strict checking.
Host key verification failed.
[root@bigboy tmp]#

If you are confident that the error is due to a reinstallation, then edit your
~/.ssh/known_hosts text file, removing the entry for the offending remote server. When
you try connecting via SSH again, you'll be prompted to add the new key to your
~/.ssh/known_hosts file and the login session should proceed as normal after that.

Deactivating Telnet After Installing SSH

You should always consider SSH over TELNET, because of the inherent data encryption
features of SSH and the current widespread availability of SSH clients for both Linux and
Windows.

By default, the TELNET server isn't installed with Fedora Linux. If you do decide to
deactivate an active TELNET server, then use procedures detailed in Chapter 16, "Telnet,
TFTP, and xinetd".
Executing Remote Commands on
Demand with SSH
A nice feature of SSH is that it is capable of logging in and executing single commands
on a remote system. You just have to place the remote command, enclosed in quotes, at
the end of the ssh command of the local server. In the example below, a user on server
smallfry who needs to know the version of the kernel running on server bigboy
(192.168.1.100) remotely runs the uname -a command. The command returns the version
of 2.6.8-1.521 and the server's name, bigboy.

[root@smallfry tmp]# ssh 192.168.1.100 "uname -a"

root@192.168.1.100's password:
Linux bigboy 2.6.8-1.521 #1 Mon Aug 16 09:01:18 EDT 2004 i686 i686 i386
GNU/Linux
[root@smallfry tmp]#

This feature can be very useful. You can combine it with password-free login, explained
later in this chapter, to get the status of a remote server whenever you need it. More
comprehensive monitoring may best be left to such purpose built programs as MRTG,
which is covered in Chapter 22, " Monitoring Server Performance".

SSH Tunneling
You already know that SSH creates an encrypted data session between a client and
server. With SSH tunneling the server computer can also receive data from other
computers on the client's network over the very same session. The client is configured to
listen on a specified TCP port and all data received on that port will be automatically
SSH encrypted and relayed to the remote server. It is for this reason that SSH tunneling is
also called SSH port forwarding.

There are two types of forwarding:

Local Forwarding: Forwards traffic coming to a local port to a specified remote port.
This is also known as outgoing tunneling, as the tunnel is established to the remote
server.

Remote Forwarding: Forwards traffic coming to a remote port to a specified local port.
This is also known as incoming tunneling, as the tunnel is established from the remote
server.

As always it is best to explain these methodologies with some examples.

Local Forwarding
The syntax for local forwarding relies on the -L SSH command line qualifier which is
configured like this:

-L bind-address:bind-port:remote-server-address:remote-port

Where the bind-address and bind-port are the IP address and TCP port on which the local
computer will listen for connections from its neighbors. If the bind-address isn't listed,
then the server will only accept connections from localhost. The remote-server-address
and remote-port specify the same options for the remote server.

Note: Sometimes an intermediary relay host for the data can be used. In this case
the data passes through an encrypted SSH connection for the part of the journey
between the local server and the intermediary. The connection between the
intermediary and remote host is not. This is not a security issue when forwarding
SSH traffic, which is already encrypted, but it can be so when forwarding
unencrypted data such as POP mail, SMTP mail or, telnet.
Intermediaries can be useful especially when the intermediary host is the only
host on the local network with access to the remote host.

Here are some explanatory examples:

Example 1: The local computer forwards any connection to its NIC IP address on a
specified port to a remote host.

[root@bigboy ~]# ssh -L 192.168.1.100:9999:216.10.135.26:22

root@192.168.1.100
root@192.168.1.100's password:
Last login: Sat Mar 17 22:00:50 2007 from 192.168.1.201
[root@bigboy ~]#

Here server bigboy is configured to forward any connections its NIC IP address of
192.168.1.100 receives on port 9999 to port 22 on server 216.10.135.26.

The outbound connection to 216.10.135.26 is managed by a separate shell process with

the login credentials you specify. In this case the connection will be created on bigboy
itself, 192.168.1.100, and will run as user root. This can be tricky, as after executing this
command it will appear as if you have logged into bigboy all over again and nothing
appears to be happening. Don't be fooled, the new login is shell is the master process for
the connection that needs to be created. If you log out, the forwarding will be broken.

This can easily be tested. Using SSH to connect to bigboy on port 9999 actually logs you
into the remote server web-003.

[root@smallfry ~]# ssh -p 9999 root@192.168.1.200

root@192.168.1.200's password:
Last login: Sat Mar 17 21:56:03 2007 from home.my-web-site.org
[root@web-003 ~]#
You can then use the netstat and ps commands to verify that the shell process has been
created and that the connection has been established.

[root@bigboy ~]# netstat -an | grep 216.10.135.26

tcp 0 0 192.168.1.100:36342 216.10.135.26:22 ESTABLISHED
[root@bigboy ~]#

[root@bigboy ~]# ps -ef | grep 216.10.135.26

root 22901 21955 0 13:59 pts/0 00:00:00 ssh -L
192.168.2.200:9999:216.10.135.26:222 -p 222 root@192.168.1.100
[root@bigboy ~]#

Forwarding can be useful! Let's see some more examples.

Example 2: The local computer forwards any connection to localhost on a specified port,
to a remote host via an intermediary server. Connection's to the local computer's NIC on
the specified port is not allowed.

[root@smallfry ~]# ssh -L localhost:9999:216.10.135.26:22 \

root@192.168.1.100
root@192.168.1.100's password:
[root@bigboy ~]#

Here server smallfry is configured to local forward any connections its localhost IP
address receives on port 9999 to port 22 on a remote server with an IP address of
216.10.135.26. Server bigboy is used as the intermediary.

[root@smallfry ~]# ssh -p 9999 localhost

root@localhost's password:
Last login: Sat Mar 17 20:11:09 2007 from home.my-web-site.org
[root@web-003 ~]#

You can use the netstat command on smallfry and bigboy to verify that connections have
been established between bigboy and web-003, and smallfry and bigboy.

[root@smallfry ~]# netstat -an | grep EST | grep 192.168.1.100

tcp 0 0 192.168.1.50:40679 192.168.1.100:22 ESTABLISHED
[root@smallfry ~]#
[root@bigboy ~]# netstat -an | grep EST | grep 216.10.135.26
tcp 0 0 192.168.1.100:56236 216.10.135.26:22 ESTABLISHED
[root@bigboy ~]#

SSH connections to the NICs of either bigboy or smallfry fail.

[root@smallfry ~]# ssh -p 9999 192.168.1.100

ssh: connect to host 192.168.1.100 port 9999: Connection refused
[root@smallfry ~]# ssh -p 9999 192.168.1.50
ssh: connect to host 192.168.1.50 port 9999: Connection refused
[root@smallfry ~]#

The final example which follows discusses forwarding unencrypted protocols.

Example 3: The local computer forwards any POP mail queries to localhost directly to
the remote POP mail server over an SSH tunnel.

[root@smallfry ~]# ssh -L 9999:mailserver:110 root@mailserver

root@mailserver's password:
Last login: Sat Mar 17 20:11:09 2007 from home.my-web-site.org
[root@mailserver ~]#

In this case an SSH connection is created to mailserver using a shell process owned by
user root. The server mailserver then creates an unencrypted POP session (TCP port 110)
to itself. The advantage of this configuration is that POP data never leaves the POP server
unencrypted.

POP mail users on smallfry can then get their mail over the encrypted link by configuring
localhost as the POP mail server in their mail client, and not mailserver.

Remote Forwarding
The syntax for local forwarding relies on the -R SSH command line qualifier which is
configured like this:

-R bind-address:bind-port:remote-server-address:remote-port

The syntax is similar to that of the -L option. The bind-address and bind-port are the IP
address and TCP port on which the local computer will listen for connections from its
neighbors. If the bind-address isn't listed, then the server will only accept connections
from localhost. The remote-server-address and remote-port specify the same options for
the remote server and are from the remote server's perspective. If you specify localhost as
the remote-server-address, SSH will be interpret it to mean the Internet IP address of the
remote server.

This can be useful in a number of scenarios. For example, you cannot connect to your
office workstation via VPN due to network maintenance, but during this time your
workstation still has access to the Internet. Remote forwarding could provide you with
access.

Here's another scenario. You are moving into a new Internet data center, all the network
gear has been configured, but the installation of the data circuits has been delayed. This
has caused the configuration of the servers to be delayed. If one server wired to your
network can get access to a server on the Internet, via a wireless card, or otherwise, then
remote access to the data center could be achieved using remote forwarding.

Example 1: The local computer forwards any connection to localhost on a specified port
to a remote host. Forwarding occurs over a previously established connection from the
remote host. If we revisit our scenario where VPN access will be down due to
maintenance, the first thing to be done is to configure your workstation at work to
establish a remote forwarding SSH session to your home server.

[root@work-001 ~]# ssh -R localhost:9999:localhost:22 root@home.my-web-

site.org
root@home.my-web-site.org's password:
Last login: Sat Mar 17 21:15:36 2007 from 216.10.135.26
[root@bigboy ~]# ping localhost
PING bigboy (127.0.0.1) 56(84) bytes of data.
64 bytes from bigboy (127.0.0.1): icmp_seq=1 ttl=64 time=0.091 ms
64 bytes from bigboy (127.0.0.1): icmp_seq=2 ttl=64 time=0.082 ms
64 bytes from bigboy (127.0.0.1): icmp_seq=3 ttl=64 time=0.097 ms
64 bytes from bigboy (127.0.0.1): icmp_seq=4 ttl=64 time=0.078 ms

Here workstation work-001 creates an SSH session to server bigboy at home. It also tells
bigboy to use this session to forward data to work-001 when bigboy receives SSH
connections to localhost on port 9999. Remember, the remote-server-address of the -R
option is from the remote server's perspective (work-001). If you specify localhost as the
remote-server-address, SSH will be interpret it to mean the Internet IP address of the
remote server.

We have setup a ping session to ensure that there is constant traffic between bigboy and
work-001 over the connection so that any intermediary firewall doesn't kill it due to
inactivity.

When you arrive home, all you have to do is SSH to localhost on your home system to
gain access to your workstation at work.

[root@bigboy ~]# ssh -p 9999 root@localhost

root@localhost's password:
Last login: Sun Mar 18 15:50:16 2007 from 65.115.71.35
[root@work-001 ~]#

As you can see, remote forwarding can be both useful, convenient and productivity
enhancing.

Example 2: The local computer forwards any connection to it's NIC on a specified port
to a remote host. Forwarding occurs over a previously established connection from the
remote host.

This is more fitting for our limited connectivity data center scenario. In this case the local
computer can be accessed by anyone on the Internet and it will forward any SSH
connections it receives on the specified port to the server in the data center with the
wireless access. Here's how it's done:

• Your local computer may be configured to only accept SSH connections for
remote forwarding on the loopback localhost interface. Edit your sshd_config file
and make sure the GatewayPorts setting is set to yes.
#
# File: /etc/ssh/sshd_config
#

GatewayPorts yes
Restart the SSH daemon to activate the setting.
[root@netserver-001 ~]# /etc/init.d/sshd restart
Stopping sshd: [ OK ]
Starting sshd: [ OK ]
[root@netserver-001 ~]#

• The next step is to establish the remote port forwarding session. Set up a ping if
you need constant activity on the link. In this case Internet server is netserver-
001.my-web-site.org.

[root@datacenter-001 ~]# ssh -R netserver-001.my-web-

site.org:9999:localhost:22 root@netserver-001.my-web-site.org
root@netserver-001.my-web-site.org's password:
Last login: Sat Mar 17 21:15:36 2007 from 216.10.135.26
[root@netserver-001 ~]# ping localhost
PING netserver-001 (127.0.0.1) 56(84) bytes of data.
64 bytes from netserver-001 (127.0.0.1): icmp_seq=1 ttl=64 time=0.091 ms
64 bytes from netserver-001 (127.0.0.1): icmp_seq=2 ttl=64 time=0.082 ms
64 bytes from netserver-001 (127.0.0.1): icmp_seq=3 ttl=64 time=0.097 ms
64 bytes from netserver-001 (127.0.0.1): icmp_seq=4 ttl=64 time=0.078 ms
Here workstation datacenter-001 creates an SSH session to Internet server
netserver-001. It also tells netserver-001 to use this session to forward data to
datacenter-001 when netserver-001 receives SSH connections on any interface IP
address (*) on port 9999.

• Now it's time to test it. From our home server bigboy, we can SSH into server
netserver-001 on port 9999 and get access to the data center.

[root@bigboy~]# ssh -p 9999 root@netserver-001.my-web-site.org

root@ netserver-001.my-web-site.org's password:
Last login: Sun Mar 18 15:50:16 2007 from 65.115.71.35
[root@datacenter-001 ~]#

Success! You have saved the day with your ingenuity.

Configuring Forwarding with GUI Clients

You won't always have SSH command line access for the servers at both end of a port
forwarding connection. Sometimes a GUI is either easier to use, or is your only option.

Most GUI clients will have SSH forwarding capabilities and it will be configurable on
each of your saved connections, not globally. The options to do this should be found
under the advanced properties or equivalent tab and with your new Linux command line
knowledge, the setup should be relatively easy.
Troubleshooting SSH Port Forwarding
There can be many complications with SSH port forwarding, and they are mostly related
to typographical errors. Here are a few symptoms that are easy to overcome:

• If remote forwarding doesn't work from a remote server, but works from
localhost, then make sure you have activated the GatewayPorts setting on your
computer. If not, change it, restart the SSH daemon and try again.

• If you get a message like this stating that the address is already in use, then you
may have another port forwarding session already started on the port or the port
you intend to use for forwarding is already in use by another application.

bind: Address already in use

channel_setup_fwd_listener: cannot listen to port: 9999
Could not request local forwarding.

• "Connection closed" messages like this one could be caused by typing in an

incorrect forwarding address.

ssh_exchange_identification: Connection closed by remote host

• If you are attempting remote forwarding using your server's NIC IP address and
get this message, then it could be because the GatewayPorts setting has been
disabled. With local forwarding, it could be caused by specifying an incorrect port
on which the server should listen.

[root@bigboy ~]# ssh -p 9999 192.168.1.100

ssh: connect to host 192.168.1.200 port 9999: Connection refused
[root@bigboy ~]

SSH port forwarding is a very useful tool that can provide you with a great deal of
versatility when administering your servers. It's always a good thing to remember.

SCP: A Secure Alternative to FTP

From a networking perspective, FTP isn't very secure, because usernames, passwords,
and data are sent across the network unencrypted. More secure forms such as SFTP
(Secure FTP) and SCP (Secure Copy) are available as a part of the OpenSSH package
that is normally installed by default on RedHat and Fedora Core. Remember, unlike FTP,
SCP doesn't support anonymous downloads like FTP.

The Linux scp command for copying files has a format similar to that of the regular
Linux cp command. The first argument is the source file and the second is the destination
file. When copying to or from a remote server, SCP logs in to the server to transfer the
data and this therefore requires you to supply a remote server name, username, and
password to successfully execute the command. The remote filename is therefore
preceded by a prefix of the remote username and server name separated by an @ symbol.
The remote filename or directory then follows separated by a colon. The format therefore
looks like this:

username@servername:filename
username@servername:directoryname

For example, file /etc/syslog.conf on a server with IP address 192.168.1.100 that needs to
be retrieved as user peter would have the format peter@192.168.1.000:/etc/syslog.conf,
the entire /etc directory would be peter@192.168.1.000:/etc/.

Note: You can download an easy-to-use Windows SCP client called WinSCP from
http://winscp.vse.cz/eng/

Copying Files To The Local Linux Box

If you understand how scp represents remote filenames, you can start copying files fairly
easily. For example, to copy file /tmp/software.rpm on the remote machine to the local
directory /usr/rpm use the commands

[root@bigboy tmp]# scp root@smallfry:/tmp/software.rpm /usr/rpm

root@smallfry's password:
software.rpm 100% 1011 27.6KB/s 00:00
[root@bigboy tmp]#

To copy the file /tmp/software.rpm on the remote machine to the local directory /usr/rpm
using TCP port 435, use the commands

[root@bigboy tmp]# scp -P 435 root@smallfry:/tmp/software.rpm /usr/rpm

root@smallfry's password:
software.rpm 100% 1011 27.6KB/s 00:00
[root@bigboy tmp]#

Copying Files To The Remote Linux Box

Copying files to the local Linux server now becomes intuitive. For examples, to copy
file /etc/hosts on the local machine to directory /tmp on the remote server

[root@bigboy tmp]# scp /etc/hosts root@192.168.1.103:/tmp

root@192.168.1.103's password:
hosts 100% 1011 27.6KB/s 00:00
[root@bigboy tmp]#

To copy file /etc/hosts on the local machine to directory /tmp on the remote server via
TCP port 435, use the commands

[root@bigboy tmp]# scp -P 435 /etc/hosts root@192.168.1.103:/tmp

hosts 100% 1011 27.6KB/s 00:00
[root@bigboy tmp]#

SFTP: Another Secure Alternative to FTP

OpenSSH also has the SFTP program, which runs over an encrypted SSH session but
whose commands mimic those of FTP. SFTP can be more convenient to use than SCP
when you are uncertain of the locations of the files you want to copy, because it has the
directory browsing abilities of FTP. Unlike FTP, SFTP doesn't support anonymous
logins.

Here is a sample login sequence that logs in, gets help on the available commands and
downloads a file to the local server.

[root@bigboy tmp]# sftp 192.168.1.200

Connecting to 192.168.1.200...
root@192.168.1.200's password:
sftp> help
Available commands:
cd path Change remote directory to 'path'
lcd path Change local directory to 'path'
chgrp grp path Change group of file 'path' to 'grp'
chmod mode path Change permissions of file 'path' to
'mode'
...
...
sftp> ls
...
...
anaconda-ks.cfg
install.log
install.log.syslog
...
...
sftp> get install.log
install.log 100% 17KB 39.4KB/s 00:00
sftp> exit
[root@bigboy tmp]#

Using SSH and SCP without a password

From time to time you may want to write scripts that will allow you to copy files to a
server, or login, without being prompted for passwords. This can make them simpler to
write and also prevents you from having to embed the password in your code.

SCP has a feature that allows you to do this. You no longer have to worry about prying
eyes seeing your passwords nor worrying about your script breaking when someone
changes the password. You can configure SSH to do this by generating and installing
data transfer encryption keys that are tied to the IP addresses of the two servers. The
servers then use these pre-installed keys to authenticate one another for each file transfer.
As you may expect, this feature doesn't work well with computers with IP addresses that
periodically change, such as those obtained via DHCP.

There are some security risks though. The feature is automatically applied to SSH as
well. Someone could use your account to log in to the target server by entering the
username alone. It is therefore best to implement this using unprivileged accounts on both
the source and target servers.

The example that follows enables this feature in one direction (from server bigboy to
server smallfry) and only uses the unprivileged account called filecopy.

Configuration: Client Side

Here are the steps you need to do on the computer that acts as the SSH client:

1) Generate your SSH encryption key pair for the filecopy account. Press the Enter key
each time you are prompted for a password to be associated with the keys. (Do not enter a
password.)

[filecopy@bigboy filecopy]# ssh-keygen -t dsa

Generating public/private dsa key pair.
Enter file in which to save the key
(/filecopy/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in
/filecopy/.ssh/id_dsa.
Your public key has been saved in
/filecopy/.ssh/id_dsa.pub.
The key fingerprint is:
1e:73:59:96:25:93:3f:8b:50:39:81:9e:e3:4a:a8:aa
filecopy@bigboy
[filecopy@bigboy filecopy]#

2) These keyfiles are stored in the.ssh subdirectory of your home directory. View the
contents of that directory. The file named id_dsa is your private key, and id_dsa.pub is
the public key that you will be sharing with your target server. Versions other than
RedHat/Fedora may use different filenames, use the SSH man pages to verify this.

[filecopy@bigboy filecopy]# cd ~/.ssh

[filecopy@bigboy filecopy]# ls
id_dsa id_dsa.pub known_hosts
[filecopy@bigboy .ssh]#

3) Copy only the public key to the home directory of the account to which you will be
sending the file.

[filecopy@bigboy .ssh]# scp id_dsa.pub filecopy@smallfry:public-key.tmp

Now, on to the server side of the operation.

Configuration - Server Side

Here are the steps you need to do on the computer that will act as the SSH server.

1) Log into smallfry as user filecopy. Create an .ssh subdirectory in your home directory
and then go to it with cd.

[filecopy@smallfry filecopy]# ls
public-key.tmp
[filecopy@smallfry filecopy]# mkdir .ssh
[filecopy@smallfry filecopy]# chmod 700 .ssh
[filecopy@smallfry filecopy]# cd .ssh

2) Append the public-key.tmp file to the end of the authorized_keys file using the >>
append redirector with the cat command. The authorized_keys file contains a listing of all
the public keys from machines that are allowed to connect to your Smallfry account
without a password. Versions other than RedHat/Fedora may use different filenames, use
the SSH man pages to verify this.

[filecopy@smallfry .ssh]# cat ~/public-key.tmp >> authorized_keys

[filecopy@smallfry .ssh]# rm ~/public-key.tmp

From now on you can use ssh and scp as user filecopy from server bigboy to smallfry
without being prompted for a password.

Conclusion
Most Linux security books strongly recommend using SSH and SCP over TELNET and
FTP because of their encryption capabilities. Despite this, there is still a place for FTP in
the world thanks to its convenience in providing simple global access to files and
TELNET, which is much easier to implement in price-sensitive network appliances than
SSH. Consider all options when choosing your file transfer and remote login programs
and select improved security whenever possible as the long term benefits eventually
outweigh the additional cost over time.