Secure Remote Logins and File Copying

Secure Remote Logins and File Copying

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 limi= ted 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 scram= ble 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 hel= ps 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 su= ccessful exchange of encrypted data requires the receiver to have a copy of the send= er'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 l= ink 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 k= ey 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.

N= ote: 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.

 

Linu= x 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 connecti= on 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 late= r).

Starting OpenSSH

Open= SSH 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.

Beca= use 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.

[roo= t@bigboy tmp]# chkconfig sshd on

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

[roo= t@bigboy tmp]# service sshd start

[roo= t@bigboy tmp]# service sshd stop

[roo= t@bigboy tmp]# service sshd restart

Reme= mber to restart the SSH process every time you make a change to the configuration f= iles for the changes to take effect on the running process.

Testing The Status of SSH<= /o:p>

You = can test whether the SSH process is running with

[roo= t@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

# Op= enSSH is to specify options with their default value where

# po= ssible, but leave them commented. Uncommented options change a

# de= fault value.

 

#Por= t 22

#Pro= tocol 2,1

 

#Lis= tenAddress 0.0.0.0

#Lis= tenAddress ::

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 for= ce 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.

#

# Fi= le: /etc/ssh/sshd_config

#

 

Prot= ocol 2

<= /a>

How To Change The TCP Port On Which SSH Listens

If y= ou 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, becau= se good network scanning programs can detect SSH running on alternative ports.=

What= you need to do is:

1) U= se 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':=

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

[roo= t@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 b= eing used, pick another port and try again.

Port= 435

3) R= estart SSH:

[roo= t@bigboy tmp]# service sshd restart

4) C= heck to ensure SSH is running on the new port:

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

tcp<= span style=3D'mso-spacerun:yes'>    0    0    192.168.1.100:435    0.0.0.0:*    LISTEN

[roo= t@bigboy root]#

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

Using SSH To Login To A Remote Machine

Usin= g 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, y= our username will not change. Here are some examples for a server named smallfr= y in your /etc/hosts file.

If y= ou are user root and you want to log in to smallfry as yourself, use the command <= o:p>

[roo= t@bigboy tmp]# ssh smallfry

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

[roo= t@bigboy tmp]# ssh -l peter smallfry

or v= ia port 435 using the username@remote_server alternative login format: <= /span>

[roo= t@bigboy tmp]# ssh -p 435 peter@smallfry

<= span class=3Dmw-headline>

What To Expect With Your First = Login

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

[roo= t@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.<= /span>

Are = you sure you want to continue connecting (yes/no)? yes

Warn= ing: Permanently added 'smallfry' (RSA) to the list of known hosts. root@smallfr= y's password:

Last= login: Thu Nov 14 10:18:45 2002 from 192.168.1.98

No m= ail.

[roo= t@smallfry tmp]#

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

<= /a>

SSH Failures Due To Linux Reinstallations

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

[roo= t@bigboy tmp]# ssh 192.168.1.102

@@@@= @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @

@@@@= @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Some= one could be eavesdropping on you right now (man-in-the-middle attack)!

It i= s also possible that the RSA host key has just been changed.

The fingerprint for the RSA key sent by the remote host is

5d:d= 2:f5:21:fa:07:64:0d:63:1b:3b:ee:a6:58:58:bb.

Plea= se contact your system administrator.

Add = correct host key in /root/.ssh/known_hosts to get rid of this message.

Offe= nding key in /root/.ssh/known_hosts:2

RSA = host key for 192.168.1.102 has changed and you have requested strict checking.<= /o:p>

Host= key verification failed.

[roo= t@bigboy tmp]#

If y= ou 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 procee= d as normal after that.

<= /a>

Deactivating Telnet After Insta= lling 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 d= efault, 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'.

<= /a>

Executing Remote Commands on De= mand with SSH

A ni= ce 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 t= he example below, a user on server smallfry who needs to know the version of t= he 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 na= me, bigboy.

[roo= t@smallfry tmp]# ssh 192.168.1.100 'uname -a'

root= @192.168.1.100's password:

Linu= x bigboy 2.6.8-1.521 #1 Mon Aug 16 09:01:18 EDT 2004 i686 i686 i386 GNU/Linux

[roo= t@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 ne= ed 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.

Ther= e are two types of forwarding:

L= ocal Forwarding: Fo= rwards traffic coming to a local port to a specified remote port. This is also kno= wn as outgoing tunneling, as the tunnel is established to the remote server. <= o:p>

R= emote Forwarding: Fo= rwards traffic coming to a remote port to a specified local port. This is also kno= wn as incoming tunneling, as the tunnel is established from the remote server.=

As a= lways it is best to explain these methodologies with some examples.

Local Forwarding<= span style=3D'font-size:12.0pt;font-family:Arial'>

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<= /p>

Wher= e the bind-address and bind-port are the IP address and TCP port on which the loc= al 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 remo= te server.

N= ote: Sometimes an intermediary rela= y 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 no= t. 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 ma= il, SMTP mail or, telnet.

Inte= rmediaries 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:

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

[roo= t@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

[roo= t@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 bigb= oy 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. <= /p>

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

[roo= t@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

[roo= t@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.

[roo= t@bigboy ~]# netstat -an | grep 216.10.135.26

tcp<= span style=3D'mso-spacerun:yes'>   0   0   192.168.1.100:36342   216.10.135.26:22   ESTABLISHED

[roo= t@bigboy ~]#

 

[roo= t@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

[roo= t@bigboy ~]#

Forw= arding can be useful! Let's see some more examples.

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

[roo= t@smallfry ~]# ssh -L localhost:9999:216.10.135.26:22

  root@192.168.1.100

root= @192.168.1.100's password:

[roo= t@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 addr= ess of 216.10.135.26. Server bigboy is used as the intermediary.

[roo= t@smallfry ~]# ssh -p 9999 localhost

root= @localhost's password:

Last= login: Sat Mar 17 20:11:09 2007 from home.my-web-site.org

[roo= t@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.

[roo= t@smallfry ~]# netstat -an | grep EST | grep 192.168.1.100

tcp<= span style=3D'mso-spacerun:yes'>   0   0   192.168.1.50:40679   192.168.1.100:22   ESTABLISHED

[roo= t@smallfry ~]#

[roo= t@bigboy ~]# netstat -an | grep EST | grep 216.10.135.26

tcp<= span style=3D'mso-spacerun:yes'>    0   0   192.168.1.100:56236  216.10.135.26:22   ESTABLISHED

[roo= t@bigboy ~]#

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

[roo= t@smallfry ~]# ssh -p 9999 192.168.1.100

ssh:= connect to host 192.168.1.100 port 9999: Connection refused

[roo= t@smallfry ~]# ssh -p 9999 192.168.1.50

ssh:= connect to host 192.168.1.50 port 9999: Connection refused

[roo= t@smallfry ~]#

The = final example which follows discusses forwarding unencrypted protocols.

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

[roo= t@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

[roo= t@mailserver ~]#

In t= his case an SSH connection is created to mailserver using a shell process owned by u= ser root. The server mailserver then creates an unencrypted POP session (TCP po= rt 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<= /p>

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 serv= er's perspective. If you specify localhost as the remote-server-address, SSH wil= l 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 of= fice workstation via VPN due to network maintenance, but during this time your workstation still has access to the Internet. Remote forwarding could provi= de 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 delaye= d. If one server wired to your network can get access to a server on the Inter= net, via a wireless card, or otherwise, then remote access to the data center co= uld be achieved using remote forwarding.

E= xample 1: The local computer forwards any connection to localhost on a specified port to a remo= te 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.

[roo= t@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

[roo= t@bigboy ~]# ping localhost

PING bigboy (127.0.0.1) 56(84) bytes of data.

64 b= ytes from bigboy (127.0.0.1): icmp_seq=3D1 ttl=3D64 time=3D0.091 ms

64 b= ytes from bigboy (127.0.0.1): icmp_seq=3D2 ttl=3D64 time=3D0.082 ms

64 b= ytes from bigboy (127.0.0.1): icmp_seq=3D3 ttl=3D64 time=3D0.097 ms

64 b= ytes from bigboy (127.0.0.1): icmp_seq=3D4 ttl=3D64 time=3D0.078 ms

Here workstation work-001 creates an SSH session to server bigboy at home. It al= so 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 perspect= ive (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 h= ave 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.

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

root= @localhost's password:

Last= login: Sun Mar 18 15:50:16 2007 from 65.115.71.35

[roo= t@work-001 ~]#

 

As y= ou can see, remote forwarding can be both useful, convenient and productivity enhancing.

E= xample 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 forwar= ding on the loopback localhost interface. Edit your sshd_config file and make su= re the GatewayPorts setting is set to yes.

#

# Fi= le: /etc/ssh/sshd_config

#

 

Gate= wayPorts yes

Rest= art the SSH daemon to activate the setting.

[roo= t@netserver-001  ~]# /etc/init.d/sshd restart<= /o:p>

Stop= ping sshd: [  OK  ]

Star= ting sshd: [  OK  ]

[roo= t@netserver-001  ~]#

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

[roo= t@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

[roo= t@netserver-001 ~]# ping localhost

PING netserver-001 (127.0.0.1) 56(84) bytes of data.

64 b= ytes from netserver-001 (127.0.0.1): icmp_seq=3D1 ttl=3D64 time=3D0.091 ms<= /o:p>

64 b= ytes from netserver-001 (127.0.0.1): icmp_seq=3D2 ttl=3D64 time=3D0.082 ms<= /o:p>

64 b= ytes from netserver-001 (127.0.0.1): icmp_seq=3D3 ttl=3D64 time=3D0.097 ms<= /o:p>

64 b= ytes from netserver-001 (127.0.0.1): icmp_seq=3D4 ttl=3D64 time=3D0.078 ms<= /o:p>

Here workstation datacenter-001 creates an SSH session to Internet server netserver-001. It also tells netserver-001 to use this session to forward d= ata to datacenter-001 when netserver-001 receives SSH connections on any interf= ace 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.

[roo= t@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

[roo= t@datacenter-001 ~]#

Succ= ess! You have saved the day with your ingenuity.

Confi= guring 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 Lin= ux command line knowledge, the setup should be relatively easy.

Troub= leshooting SSH Port Forwarding

Ther= e 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 r= emote 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 y= ou 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

chan= nel_setup_fwd_listener: cannot listen to port: 9999

Coul= d not request local forwarding.

&quo= t;Connection closed' messages like this one could be caused by typing in an incorre= ct forwarding address.

ssh_= exchange_identification: Connection closed by remote host

If y= ou 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 disable= d. With local forwarding, it could be caused by specifying an incorrect port on which the server should listen.

[roo= t@bigboy ~]# ssh -p 9999 192.168.1.100

ssh:= connect to host 192.168.1.200 port 9999: Connection refused

[roo= t@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 FT= P

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 Open= SSH 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 L= inux 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 t= he server to transfer the data and this therefore requires you to supply a rem= ote 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:

user= name@servername:filename

user= name@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/.

N= ote: You can download an easy-to-use Windows SCP client called WinSCP from https://winscp.vse.cz/eng/ =

<= span class=3Dmw-headline>Copyi= ng Files To The Local Linux Box

If y= ou 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 =

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

root= @smallfry's password:

soft= ware.rpm        =            =    100% 1011    27.6KB/s   00:00

[roo= t@bigboy tmp]#

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

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

root= @smallfry's password:

soft= ware.rpm        =             &nb= sp;  100% 1011    = 27.6KB/s   00:00

[roo= t@bigboy tmp]#

= Copyi= ng Files To The Remote Linux Box

Copy= ing 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=

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

root= @192.168.1.103's password:

host= s        =             &nb= sp;        100% 1011    27.6KB/s   00:00   

[roo= t@bigboy tmp]#

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

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

host= s        =             &nb= sp;        100% 1011    27.6KB/s   00:00   

[roo= t@bigboy tmp]#

SFTP: Another Secure Alternativ= e to FTP

Open= SSH 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 wh= en 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 suppo= rt 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.

[roo= t@bigboy tmp]# sftp 192.168.1.200

Conn= ecting to 192.168.1.200

root= @192.168.1.200's password:

sftp= > help

Avai= lable commands:

cd p= ath        =             &nb= sp;  Change remote directory to 'path'

lcd path        =             &nb= sp; Change local directory to 'path'

chgr= p grp path        =         Change group of file 'path' to 'grp'

chmo= d mode path        =        Change permissions of file 'path' to 'mode'

<= o:p>

<= o:p>

sftp= > ls

<= o:p>

<= o:p>

anac= onda-ks.cfg

inst= all.log

inst= all.log.syslog

<= o:p>

<= o:p>

sftp= > get install.log

inst= all.log        =                =  100%   17KB  39.4KB/s   00:00

sftp= > exit

[roo= t@bigboy tmp]#

<= span class=3Dmw-headline>Using SSH and SCP without a pas= sword

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 som= eone 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 authentic= ate 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.

Ther= e 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 ente= ring the username alone. It is therefore best to implement this using unprivileg= ed 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) G= enerate 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.)

[fil= ecopy@bigboy filecopy]# ssh-keygen -t dsa

Gene= rating public/private dsa key pair.

Ente= r file in which to save the key

(/fi= lecopy/.ssh/id_dsa):

Enter passphrase (empty for no passphrase):

Ente= r same passphrase again:

Your identification has been saved in

/fil= ecopy/.ssh/id_dsa.

Your= public key has been saved in

/fil= ecopy/.ssh/id_dsa.pub.

The = key fingerprint is:

1e:7= 3:59:96:25:93:3f:8b:50:39:81:9e:e3:4a:a8:aa

file= copy@bigboy

[fil= ecopy@bigboy filecopy]#

2) T= hese 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.

[fil= ecopy@bigboy filecopy]# cd ~/.ssh

[fil= ecopy@bigboy filecopy]# ls

id_d= sa  id_dsa.pub  known_hosts

[fil= ecopy@bigboy .ssh]#

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

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

Now,= on to the server side of the operation.

Confi= guration - Server Side

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

1) L= og into smallfry as user filecopy. Create an .ssh subdirectory in your home directo= ry and then go to it with cd.

[fil= ecopy@smallfry filecopy]# ls

publ= ic-key.tmp

[fil= ecopy@smallfry filecopy]# mkdir .ssh

[fil= ecopy@smallfry filecopy]# chmod 700 .ssh

[fil= ecopy@smallfry filecopy]# cd .ssh

2) A= ppend 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.

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

[fil= ecopy@smallfry .ssh]# rm ~/public-key.tmp

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

Conclusion

Most= Linux security books strongly recommend using SSH and SCP over TELNET and FTP bec= ause 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 netw= ork 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.