Linux SSH - Automation with Send & Expect Scripts

By Ken Hess

Expect is a natural and intuitive automation scripting language that operates in much the same way humans do when interacting with a system. You type in commands and expect a certain response to your command. When you receive the expected response, you enter another command and so on. Expect works in the same way, except you have to provide the script with commands and expected responses to those commands. Basically, you have to script out the entire two-way “conversation.”

You can think of an Expect script as a dialog script written for two actors: a sender and a receiver. One of the more popular activities to automate is an SSH session between two hosts, in which one host is the sender (local host) and the other is the receiver (remote host). Being able to emulate every keystroke and create a true interactive session between two systems via a script is an exciting proposition.

Expect Setup

Most Linux distributions include Expect as part of the available and installable software packages. In other words, you won’t have to download and install from source code. Use your system’s package manager to download and install Expect and any required dependencies or associated packages. For example:

$ sudo yum install expect
or
$ sudo apt-get install expect

Once you have Expect installed, you can begin writing scripts.

Creating an Interactive SSH Session

As stated previously, you must provide both sides of the conversation in your script because you’re setting up an interactive system. Look at a few essential items before diving right into a script.

To make an Expect script executable as a standalone program, you must do two things: Make the script executable, and supply the path to the script for expect . The path on my system is: /usr/bin/expect ; therefore, enter that path on the first line of your script with a preceding “shebang” (#! ):

#!/usr/bin/expect -f

The -f switch tells Expect that it is reading commands from a file.

The spawn command spawns or launches an external command for you. In this case, ssh to a remote host (aspen ):

spawn ssh aspen

Change the host aspen to your remote host. When you SSH to a remote system, you’re prompted for a password. This password prompt is what you “expect” from the remote system; therefore, you enter that expected response:

expect "password: "

From the local side, you have to enter your password at the password prompt. To send anything to the remote system, it must be included in double quotes and must include a hard return (\r ). Change PASSWORD to your password:

send "PASSWORD\r"

Again, you have to enter the expected response from the remote system, which in this case is a user prompt ($ ).

expect "$ "

Now that you’re logged in to the remote system, you can begin your interactive session on that remote host. The following send command issues the ps -ef |grep apache command:

send "ps -ef |grep apache\r"

Output will appear as STDOUT. After the command has executed, you’re returned to a prompt, so tell the Expect script that bit of information:

expect "$ "

Finally, send the exit command to the remote system to log out. Don’t forget that hard return (\r ):

send "exit\r"

The script in its entirety looks as follows:

#!/usr/bin/expect -f
spawn ssh aspen
expect "password: "
send "PASSWORD\r"
expect "$ "
send "ps -ef |grep apache\r"
expect "$ "
send "exit\r"

Change permissions on the script so that it is executable; for example,

$ chmod 755 script.sh

and try it for yourself.

Expect Caveats

If your script hangs and doesn’t continue, try the command manually yourself and look for the response. If the remote system drops you to a prompt as its final act, then place that in your script (e.g., expect "$ " ). Be sure you have entered the hard return (\r ) inside the closing quotation mark in your send line. You might also find that your system needs two backslashes on the send line for a hard return (\r ).

Sometimes Expect scripts execute too fast, and you won’t see your expected response. If that happens, place a sleep command and a number of seconds for the command preceeding it to wait for a response, or your data might be ignored.
For example, if you connect to a remote system and there’s a delay in creating that connection, your script will continue to execute and fail because it sends commands before the remote system has time to respond.

You have to think about network delays, shell responses and system timing when scripting in Expect. Like any scripting language, Expect has its quirks, but you’ll find that it’s an easy way to automate those repetitious keystrokes and procedures. The time you spend debugging your scripts is well worth the effort.

Autoexpect

Of course, some lazy system administrators take lazy to a higher level and even cheat at writing Expect scripts by invoking a shell “watcher” or recorder script named Autoexpect. Once invoked, Autoexpect watches your every keystroke and records it to a file named, script.exp by default. You’ll almost certainly have to edit and prune this script to achieve your desired results; however, it can save hours of script debugging to have an almost complete script from which to work.

If you simply run a freshly created Autoexpect script, it will likely fail because, if you issued a command that answers your request by displaying information to the screen, the script picks up that answer, too, and copies it into the script file.
For example, if during your Autoexpect session, you type, ls , the result of that command appears in your script.exp file as well. After you’ve created a few Expect scripts by hand, you’ll appreciate the cleanup editing you have to do in an Autoexpect-created script.
To install Autoexpect, issue a command like:

$ sudo apt-get install expect-dev

You’ll likely require many more dependencies for this feature, so prepare yourself for a slight delay while everything installs.

Creating an Interactive SSH Session with Autoexpect

After installing Autoexpect and all of its required packages, you’re ready to create Expect scripts automatically by stepping through the procedures you want to automate. Using the above example, SSH to a remote system and run a

ps -ef |grep apache

command and then log out.
Invoking Autoexpect is easy:

$ Autoexpect

Autoexpect started, file is script.exp
$

Although it looks as if nothing has happened or is happening, every keystroke you type will be recorded into script.exp . Every STDOUT response you receive will also be copied into that same file. Your entire session is recorded – but not just recorded, it is also formatted in Expect script style. To stop recording keystrokes to your script, press Ctrl+D on your keyboard to stop Autoexpect and copy the buffer to your file.

The complete transcription of this simple procedure is very long and includes a lot of commentary from the author, Don Libes:

#!/usr/bin/expect -f
#
# This Expect script was generated by Autoexpect on Thu Oct 11 15:53:18 2012
# Expect and Autoexpect were both written by Don Libes, NIST.
#
# Note that Autoexpect does not guarantee a working script.  It
# necessarily has to guess about certain things.  Two reasons a script
# might fail are:
#
# 1) timing - A surprising number of programs (rn, ksh, zsh, telnet,
# etc.) and devices discard or ignore keystrokes that arrive "too
# quickly" after prompts.  If you find your new script hanging up at
# one spot, try adding a short sleep just before the previous send.
# Setting "force_conservative" to 1 (see below) makes Expect do this
# automatically - pausing briefly before sending each character.  This
# pacifies every program I know of.  The -c flag makes the script do
# this in the first place.  The -C flag allows you to define a
# character to toggle this mode off and on.

set force_conservative 0  ;# set to 1 to force conservative mode even if
                           ;# script wasn’t run conservatively originally
if {$force_conservative} {
         set send_slow {1 .1}
         proc send {ignore arg} {
                 sleep .1
                 exp_send -s -- $arg
         }
}

#
# 2) differing output - Some programs produce different output each time
# they run.  The "date" command is an obvious example.  Another is
# ftp, if it produces throughput statistics at the end of a file
# transfer.  If this causes a problem, delete these patterns or replace
# them with wildcards.  An alternative is to use the -p flag (for
# "prompt") which makes Expect only look for the last line of output
# (i.e., the prompt).  The -P flag allows you to define a character to
# toggle this mode off and on.
#
# Read the man page for more info.
#
# -Don

set timeout -1
spawn $env(SHELL)
match_max 100000
expect -exact "]0;khess@trapper: ~khess@trapper:~\$ "
send -- "ssh aspen\r"
expect -exact "ssh aspen\r
khess@aspen’s password: "
send -- "PASSWORD\r"
expect -exact "\r
Linux aspen 2.6.32-43-server #97-Ubuntu SMP Wed Sep 5 16:56:41 UTC 2012 x86_64 GNU/Linux\r
Ubuntu 10.04.4 LTS\r
\r
Welcome to the Ubuntu Server!\r
  * Documentation:  http://www.ubuntu.com/server/doc\r
\r
   System information as of Thu Oct 11 15:55:28 CDT 2012\r
\r
   System load:  1.09               Temperature:         40 C\r
   Usage of /:   1.0% of 454.22GB   Processes:           168\r
   Memory usage: 22%                Users logged in:     1\r
   Swap usage:   0%                 IP address for eth0: 192.168.1.250\r
\r
   Graph this data and manage this system at https://landscape.canonical.com/\r
\r
7 packages can be updated.\r
7 updates are security updates.\r
\r
New release ‘precise’ available.\r
Run ‘do-release-upgrade’ to upgrade to it.\r
\r
*** System restart required ***\r
Last login: Thu Oct 11 15:53:41 2012 from trapper\r\r
]0;khess@aspen: ~khess@aspen:~\$ "
send -- "ps -ef|grep apache\r"
expect -exact "ps -ef|grep apache\r
www-data   555 23171  0 Oct07 ?        00:00:00 /usr/sbin/apache2 -k start\r
www-data   556 23171  0 Oct07 ?        00:00:00 /usr/sbin/apache2 -k start\r
www-data   557 23171  0 Oct07 ?        00:00:00 /usr/sbin/apache2 -k start\r
www-data   558 23171  0 Oct07 ?        00:00:00 /usr/sbin/apache2 -k start\r
www-data   559 23171  0 Oct07 ?        00:00:00 /usr/sbin/apache2 -k start\r
khess    21504 21433  0 15:55 pts/1    00:00:00 grep apache\r
root     23171     1  0 Sep27 ?        00:00:28 /usr/sbin/apache2 -k start\r
]0;khess@aspen: ~khess@aspen:~\$ "
send -- "exit\r"
expect -exact "exit\r
logout\r
Connection to aspen closed.\r\r
]0;khess@trapper: ~khess@trapper:~\$ "
send -- "^D"
expect eof
khess@trapper:~$
You can see that you have a lot of cleanup to do before you distill this transcript down to its essential parts. Autoexpect also changes permissions on the script.exp file so that it is executable.
The parts you needed for this script to execute correctly are shown below in my cleaned up version.
#!/usr/bin/expect -f

set force_conservative 0  ;# set to 1 to force conservative mode even if
                           ;# script wasn’t run conservatively originally
if {$force_conservative} {
         set send_slow {1 .1}
         proc send {ignore arg} {
                 sleep .1
                 exp_send -s -- $arg
         }
}

set timeout -1
spawn $env(SHELL)
match_max 100000
expect -exact "$ "
send -- "ssh aspen\r"
expect -exact "password: "
send -- "PASSWORD\r"
expect -exact "$ "
send -- "ps -ef|grep apache\r"
expect -exact "$ "
send -- "exit\r"
expect -exact "$ "

You can see that the complex prompts, such as

expect -exact "exit\r
logout\r
Connection to aspen closed.\r\r
]0;khess@trapper: ~khess@trapper:~\$ "

have been shortened significantly to:

expect -exact "$ "

The prompt still works because Expect looks for the last few characters in an expect line and not the entire string. You could shorten the line that expects the password prompt from:

expect -exact "password: "
to
expect -exact ": "

A word of caution against shortening your expect lines too much – it makes the script more difficult, not easier, to read and interpret in the future when you try to figure out what’s going on.

You might not realize that ": " is a password prompt. Unless you’re great at including comments in your scripts, you might spend hours debugging this shortened version.

Summary

To be perfectly honest, I only use Autoexpect when building an Expect draft script. To sit down and attempt writing Expect line-by-line just isn’t appealing after being seduced and ruined by the ease of removing unwanted lines from an Autoexpect-created script. Autoexpect makes using Expect fun and more intuitive by letting you perform a procedure one time instead of many. After discovering and using Autoexpect, my Expect scripting creation time and debug time has been cut by at least two-thirds. I suspect you’ll have much the same return on your time as well.

Taken From: http://www.admin-magazine.com/Articles/Automating-with-Expect-Scripts

Linux/Raspberry - Web SSH Shell (No client needed)

You probably access you linux machines via SSH using a client like Putty.

With Shell In A Box, you get the same SSH access but without any client, you just use a browser that shows you the the SSH connection via HTTPS.

This might be usefull in some scenario, so I’m going to show you how to set up it bellow.

To install just type:

sudo apt-get install shellinabox

and that’s it once it finished installing, Shell In A Box is running, just go to you browser and enter this

https://<Machine_IP>:4200/

and you should get this

now just login and that’s it.

If you want to change something (ex: the 4200 port) you just edit this file:

nano /etc/default/shellinabox

FILE: shellinabox
----------------------------

# Should shellinaboxd start automatically
SHELLINABOX_DAEMON_START=1

# TCP port that shellinboxd's webserver listens on
SHELLINABOX_PORT=4200

# Parameters that are managed by the system and usually should not need
# changing:
# SHELLINABOX_DATADIR=/var/lib/shellinabox
# SHELLINABOX_USER=shellinabox
# SHELLINABOX_GROUP=shellinabox

# Any optional arguments (e.g. extra service definitions).  Make sure
# that that argument is quoted.
#
#   Beeps are disabled because of reports of the VLC plugin crashing
#   Firefox on Linux/x86_64.
SHELLINABOX_ARGS="--no-beep"

and do

 sudo service shellinabox restart

to load the new configuration.

Windows – SSH SOCKS Proxy

If you have a Raspberry Pi or any Linux machine at home, you can use it as an SSH Proxy with the help of SSH and exit to the Internet via you home conection/IP.

Some of the advantages are:

• Privacy (SSH Traffic is Encrypted)
• Bypassing Local Security Policies (Access Blocked Services)

no aditional configuration needed on the SSH server

You only need to forward port 22 on your internet router to the linux host on your LAN (no aditional configuration needed on youre Linux SSH server).

Now that you have port 22 forwarded to you Linux in you home Lan, from somewhere on the Internet setup an Dynamic SSH Tunnel on Putty like show bellow (replace the 98.125.80.38  with your own Public IP):

The tunnel will remain working as long this Putty windows is open:

Now on your Browser (or any other aplication that supports it) you must configure the Socks Proxy to point to the local end of the Dynamic SSH Tunnel, and that’s it.

Now all your browser’s traffic will be sent to the local port 8080 wich SSH wil tunnel it to you home where it will exit via you linux machine.

Here I show how to set up the Socks Proxy on IE (Internet Explorer).

Tools > Internet Options > Connections > LAN Settings > Proxy Server > Advanced

You can go on your browser to:

• http://whatismyipaddress.com/

to confirm see Public IP and confirm from wich connection you entering the internet

Linux – SSH Reverse Tunnel to Bypass NAT

Have you ever wanted to reach a server via some application, for example ssh, but you couldn’t because the remote computer (LinuxB) was beind NAT, and you didn’t had access to the router (CPE2-NAT) to add a port forwarding:

but if you add another server with a Public IP (LinuxM) in the midlle you can set up a Reverse SSH Tunel between the destination (LinuxB) and the server in the middle (LinuxM) that will forward conection to a local port on LinuxM to the destination port  on LinuxB via the established ssh session that has the reverse/remote tunel configured.

To test the Reverse SSH Tunel to bypass NAT I’m going to do a proof of concept (POC), with some linux (Ubuntu) machines with private addressing, the cenario looks like this:

Linux_M – Middleman
===========================================================

## Hostname ##
sudo nano /etc/hostname
LinuxM
hostname LinuxM
hostname

sudo nano /etc/hosts
127.0.1.1       LinuxM
 
 
## Interfaces ##
sudo ifdown eth0                                                                 
sudo ifconfig eth0 192.168.1.254 netmask 255.255.255.0
sudo ifup eth0                                      

sudo ifdown eth1                                                                 
sudo ifconfig eth1 172.16.1.254 netmask 255.255.255.0
sudo ifup eth1                                      

## IP Forwarding (Routing) ##
sudo  sysctl -w net.ipv4.ip_forward=1

## Activate Gateway Ports ##
sudo nano /etc/ssh/sshd_config
GatewayPorts yes
sudo service ssh stop
sudo service ssh start

#####################################################
# When you forward a TCP port (either locally or
# remotely), by default SSH only listens for
# connections to the forwarded port on the loopback
# address (localhost, 127.0.0.1). This means only
# other programs running on the same host as the
# listening side of the forwarding can connect to
# the forwarded port. This is a security feature,
# since there is no authentication applied to such
# connections. Also, such a forwarded connection is
# potentially insecure, since a portion of it is
# carried over the network in a plain TCP connection
# and not protected by SSH.
#####################################################

       

Linux_B – Destination
===========================================================

## Hostname ##
sudo nano /etc/hostname
LinuxB
hostname LinuxB
hostname

sudo nano /etc/hosts
127.0.1.1       LinuxB
 
 
## Interface ##
sudo ifdown eth0                                                                 
sudo ifconfig eth0 172.16.1.1 netmask 255.255.255.0
sudo ifup eth0                                      

## Route (default) ##
sudo route add default gw 172.16.1.254 eth0

## Reverse/Remote SSH Tunnel ##
ssh -R 10002:localhost:22 lubuntu@172.16.1.254

######################################################
# This sets up the reverse/remote ssh tunnel
# between the destination (LinuxB) and the server
# in the middle (LinuxM) that will forward connection
# on the local port 10002 on LinuxM to the
# destination port 22 LinuxB via the established
# ssh session that has the reverse/remote tunel
# configured.
#
# After this command you will have the reverse/remote
# ssh thunnel configured and the bash/CLI of LinuxM.
#
# YOU MUST MAINTAIN THE BASH/CLI OF LinuxM ON LinuxB
# VIA SSH, FOR THE FORWARDING/TUNNELING TO WORK
#####################################################

At this point you have this:

the reverse/remote ssh tunnel wating for a connection on LinuxM on port 10002 to forward LinuxB on port 22 (ssh)

 

Linux_A – Client
===========================================================

## Hostname ##
sudo nano /etc/hostname
LinuxA
hostname LinuxA
hostname

sudo nano /etc/hosts
127.0.1.1       LinuxA

 
## Interface ##
sudo ifdown eth0                                                                 
sudo ifconfig eth0 192.168.1.1 netmask 255.255.255.0
sudo ifup eth0                                      

## Route (default) ##
sudo route add default gw 192.168.1.254 eth0   

## Connect LinuxM (will forward to LinuxB) ##
## Gateway Ports = ON on LinuxM                ##
ssh lubuntu@192.168.1.254 -p 10002

or

## Connect LinuxM (will not forward to LinuxB) ##
## Gateway Ports = OFF on LinuxM                      ##
ssh lubuntu@192.168.1.254         
ssh lubuntu@localhost -p 10002
######################################################
# Assuming the "Gateway Ports" is OFF, then the
# reverse/remote ssh tunnel will only be accessible
# on LinuxM locally
#
# So in the above commands we first connect via SSH
# to LinuxM, and from there connect local ports of the
# reverse/remote ssh tunnel so that it will forward
# the connection on the local port 10002 of LinuxM
# to the destination port 22 LinuxB
#####################################################

At this point you have this (Gateway Ports = ON):

and you should be in the bash/CLI of LinuxB

 

Related Links:

• http://www.marksanborn.net/howto/bypass-firewall-and-nat-with-reverse-ssh-tunnel/
• http://www.snailbook.com/faq/gatewayports.auto.html
  

 

Raspberry Pi (Linux) – TigthVNC Server + File Transfer

How to Configure Your Raspberry Pi for Remote Shell, Desktop, and File Transfer

So you have a Raspberry Pi and you would like to maximize its tiny footprint by turning into a totally stand alone box—no monitor, keyboard, or other input peripherals. Read on as we show you how to set up remote shell, desktop, and file transfer access on your Pi.

Why Do I Want to Do This?

The Pi, even clad in a sturdy case, is a tiny computer. It’s perfect for tucking somewhere out of sight without a gaggle of wires sticking off of it—for many projects you simply don’t need a permanent monitor and peripheral accompaniment.

That doesn’t mean, however, that you won’t need to connect to the box to make changes, update things, transfer files, and so on. A perfect example of this is the cool little rain indicator we built as part of our Build an LED Indicator with a Raspberry Pi (for Email, Weather, or Anything) article. It doesn’t need all that stuff attached right to it, but we still would like the ability to hop onto the device and easily make changes or try out a new experiments with the LED module without having to drag it back into the workshop, and hook it up to a monitor, keyboard, mouse, etc. By configuring it for remote shell, remote desktop, and remote file transfer, we make it super simple to always interact with our Pi unit from the comfort of our desktop computer as if we’ve hooked the unit up to a full work station.

What Do I Need?

If you’re brand new to working with the Raspberry Pi, we strongly suggest checking out The HTG Guide to Getting Started with Raspberry Pi to get a handle on the basics of the device and get up to speed.

For this tutorial you will need the following things:

• A Raspberry Pi running Raspbian.
• A desktop or laptop computer.
• A local Wi-Fi or wired network to connect the Pi and your computer.

First, most of the steps in this tutorial should work with other Linux-based Pi distributions butwe’re going to be using Raspbian. You should have little trouble adapting the tutorial to other distributions.

Second, we’re using a Windows machine as our networked computer to interact with the Raspberry Pi unit as the remote head/interface. When appropriate, we’ll do our best to link to tutorials and suggested reading regarding performing parallel tasks and tools on OS X and Linux.

Setting Up and Connecting to the SSH Server

Remote command line access to your Raspbian installation is about the handiest little tweak you can make to your system, and it’s down right simple to enable.

Open up the terminal in Rasbian, the shortcut is LXTerminal on the desktop, and type in the following command:

sudo raspi-config

Navigate down to ssh and hit enter. When prompted about the SSH server, select Enable and hit enter again. You will be returned to the Raspi-config panel; navigate down to Finish and hit enter to close out the configuration tool. That’s all you need to do to turn on SSH access to your Pi. The default SSH login and password is pi and raspberry, respectively.

While you’re still sitting at the command line, now is a great time to check the IP of your Raspberry Pi unit on the local network. Type ifconfig at the prompt and then look at the output of the command. If you’re using the Ethernet port you want to look for the init addr in the eth0section; if you’re using Wi-Fi, you want to look for the init addr in the wlan0 section. In addition to checking and noting the IP address, this is also a great time to set up a static IP entry in your router so you don’t have to hunt for the IP in the future.

Now that we have the SSH server enabled, we know the login, and we know the IP address of the machine, it’s time to connect in via SSH and test it out. To do so from Linux and OS X you can simply use the ssh command at the terminal. Windows users, however, will need an SSH client like PuTTY.

Since we’re using a Windows box to remotely manage our Pi, PuTTY it is. Install a copy of PuTTY or extract the portable version and fire it up. There are a lot of settings you can mess with in PuTTY, but we only need to worry about a single thing to connect to our Pi. On the main Session interface, just type in the IP address of your Pi and select SSH below it:

Hit Open at the bottom and PuTTY will launch a terminal window for you, connect to your Pi, and prompt you to log in. Go ahead and log in with pi / raspberry:

Once your SSH connection is functional, you could technically complete the rest of this tutorial remotely from the comfort of your desk—although we’d advise leaving the head and keyboard on your system until you have finish the whole project and have everything running smoothly.

Before we move on, there’s some extra functionality we can squeeze out of SSH. In addition to managing the command line remotely, you can also remotely transfer files using Secure Copy. It’s command line intensive and not particularly convenient for transferring a large number of files sourced from multiple directories, but for a one-off configuration file transfer or other small dump, it’s pretty handy. Check out our guide to copying files over SSH using the SCP command here.

We’re going to be looking closer more user-friendly/GUI-based file transfer techniques later in the tutorial.

Setting Up and Configuring Your Remote Desktop

Remote command line access is awesome, but so is having access to the desktop for GUI-focused activities. Let’s bring the powers of the command line and the powers of the desktop together.

Although we’ve been referring to it as “remote desktop” to this point, the tool we’re actually installing is known as Virtual Network Computing (VNC)—iterations of which many are familiar with such as RealVNC and TightVNC. For this tutorial, we’ll be installing TightVNC on the Pi. In order to access the Pi-based TightVNC session, you will need a remote client such as:

• TightVNC desktop client for Windows
• TightVNC desktop client for Linux/Unix-like Systems
• RealVNC desktop client for OSX

Grab a copy now, and we’ll be trotting it out later in this section. For now, let’s get down to installing the TightVNC server on your Raspberry Pi. Open up the terminal. Enter the following command to get started:

sudo apt-get install tightvncserver

This will download and unpack the installation files; when prompted to continue press Y. After the installation is complete, you’ll be returned to the prompt.  You can start the VNC one of two ways. Simply running the command for the server like so:

tightvncserver

Will prompt you enter a password to access your VNC desktop—as seen in the screenshot above. The password needs to be 4-8 characters long. Once you confirm the password, you will be prompted to set a view-only password (you can opt out of the step, as we did).

 

Continue reading to learn how to configure your server and setup file transfer tools.

Alternatively, you can use a much more precise, albeit longer to type out, command that gives you more control over how the remote computer will see the desktop—most importantly, what resolution the desktop will display so you can enjoy a full screen view on the remote computer. To specify the resolution of the VNC desktop, use the following command, swapping out the resolution value (the fourth item in the command) for the resolution of the remote desktop:

vncserver :1 -geometry 1600×900 -depth 16 -pixelformat rgb565:

If at any point you make a mistake in setting up your VNC server instance and/or you want to shut down the VNC server, simply enter the following (changing the number after the colon to the number of the VNC instance you want to kill):

vncserver –kill :1

Now that we have the VNC server up and running, let’s connect into it from our remote desktop. Fire up TightVNC viewer on your computer and plug in the IP address of the Raspberry Pi unit followed by :1 like so:

And here’s our reward for successfully configuring our VNC server—a nice full screen view of our remote Raspberry Pi unit:

There’s a known issue with TightVNC and Rasbian that, thanks to a wonky permission change, will cause trouble with the actual monitor-is-attached desktop (while leaving the remote desktop interface provided by the VNC server untouched).  To fix this issue before it even becomes a problem for you, head right to the command line and enter the following command:

sudo chown pi /home/pi/.Xauthority

This command changes the ownership of the .Xauthority file back to the user pi—for the curious, the .Xauthority file is used by the X-windows system in Rasbian and something during the TightVNC server installation and configuration process causes that little permissions hiccup.

With that little minor detour out the way, let’s get back to finishing our remote desktop configuration.

Now that we have full command line and desktop access to the Raspberry Pi, there’s one not-so-trivial tweak we need to make. The Raspi-config tool set the SSH server to automatically start on boot for us, but the VNC server is not yet configured in such a fashion. You can skip this step and manually start the server at the command line via SSH when you need it, but we’re trying to make this as fuss-free as possible for future use. Let’s take a minute now and create a startup file for the VNC server.

In order to automatically start the VNC server, we need to set up an init, or initialization, file that Raspbian will use to cleanly start and shut down the server during the boot and shut down process. Let’s create the init file now. At the command line type in the following command:

sudo nano /etc/init.d/tightvnc

This will create a file in the initialization directory called “tightvnc” and open the nano editor so we can paste in our script. In the nano editor, paste the following code (make sure to change the 1600×900 resolution value to match the screen of your remote computer:

#!/bin/sh
### BEGIN INIT INFO
# Provides: tightvncserver
# Required-Start:
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start vnc server
# Description:
### END INIT INFO

case “$1″ in
start)
su pi -c ‘vncserver :1 -geometry 1600×900 -depth 16 -pixelformat rgb565:’
echo “VNC Started”
;;
stop)
pkill Xtightvnc
echo “VNC Terminated”
;;
*)
echo “Usage: /etc/init.d/tightvnc {start|stop}”
exit 1
;;
esac

In addition to modifying the screen resolution portion of the script, there is one other thing you can modify. In line 14 you can change the command “su pi -c” to any other user account besides “pi” if you wish to VNC to the specific desktop for that account.

Once you have pasted and modified the code, it’s time to save it. Press CTRL+X to exit and save your work in nano. Once you are back at the command line, we need to make a few quick changes to the permissions of the file:

sudo chmod 755 /etc/init.d/tightvnc

Now the initialization file is executable. We can test it from the prompt:

sudo /etc/init.d/tightvnc start

sudo /etc/init.d/tightvnc stop

The last change we’re going to make is to update the rc.d file (which tracks which initilization scripts are in the /init.d/ folder):

sudo update-rc.d tightvnc defaults

After you enter that command, you’ll get a confirmation that the file was updated. Now it’s time for the real test: does the file load properly after reboot? Enter the following at the command line to reboot and be prepared with your VNC client to test the connection in a moment:

sudo reboot

Once the system has finished rebooting, log in with your VNC client. If your VNC session fails, visit the command prompt and run the tightvnc start command (from the test portion above) again to double check that the file is executable and that the password was saved properly.

At this point, we’re even further along in our mission to totally remote-control our Raspberry Pi unit. With remote command line access via SSH and remote desktop access via VNC under our belts, let’s move on to simplifying the process of transferring files between our Pi and desktop computer.

 

Setting Up and Configuring File Transfer Tools

Since we already have SSH set up, the easiest way to set up dead simple file transfer between our Pi and remote computers is to piggy back a GUI interface on the SSH connection. Remember how we talked about using SCP over SSH earlier in the tutorial? Running it from the command line gets real tedious, real fast. With a GUI wrapper, we’ll be able to spend more time moving files and playing with our Pi and less time pecking at the keyboard.

While there are a variety of GUI wrappers for the SCP command, we’re going to go with a cross-platform tool that many people already know, have, and love (and may even be unaware that it does SCP transfers): FileZilla. It’s available for Windows, OS X, and Linux—you can grab a copy here.

Once you have installed FileZilla, fire it up and go to File –> Site Manager. Create a new site entry, name it, and plug in user name and password for your Pi.

Finally, make sure to set the port to 22 and the Servertype to SFTP – SSH File Transfer Protocol. Click connect at the bottom and you’ll be treated to a view similar to this one:

Your local directories are in the left-hand pane and the remote directories on the Pi are in the right-hand pane. Moving files between the two is as simple as drag and dropping them.

Taking advantage of the existing SSH file transfer is the easiest way to get at the files on the Pi with no additional configuration necessary but if you want to configure your Pi to receive and share files without the remote user requiring any fancy tools (like an SCP capable FTP client such as FileZilla), we highly recommend checking out the Samba configuration portion of our guide:How to Turn a Raspberry Pi into a Low-Power Network Storage Device. Reading over that will familiarize you with setting up a basic Samba share on Pi to create a shared folder easily accessible by just about anyone on your network without any additional tools.

You’ve configured SSH, you’ve configured VNC, and you’ve set up simple SFTP and/or Samba access to your Pi—at this point you can boot down your Raspberry Pi, strip away the monitor, keyboard, and mouse, and tuck it away as a silent and headless machine.

Have an idea for Raspberry Pi project and you’re dying for us to write a tutorial for it? Sound off in the comments or shoot us an email at tips@howtogeek.com and we’ll do our best to help.

Taken From: http://www.howtogeek.com/141157/how-to-configure-your-raspberry-pi-for-remote-shell-desktop-and-file-transfer/all/

Display Linux Applications (X11) on Windows – via Putty (SSH)

X Forwarding with Putty on Windows

Intro to X Forwarding

Unix machines have been able to run software on a remote machine and display the GUI locally for almost two decades. Linux and Mac OS X support X Forwarding with no extra software. Any terminal on Linux should do X Forwarding, Mac users need to run "Applications > Utilities > XTerm". In a command line terminal run "ssh -Y jdoe@compute.example.edu matlab" and you'll be running matlab on "compute.example.edu" but seeing it on your desktop.

Windows users need two pieces of software: an secure shell program (ssh) to establish the remote connection and an X Server to handle the local display.

Prerequisites

• · Putty for SSH
• · Xming for the XServer

Configuring Putty

• 1. Add Unix hostname
• 2. Switch Protocol to SSH
• 3. Type name of session in saved sessions
• 4. Click 'Save'

• 5. Expand the 'SSH' tab from the 'Category' list
• 6. Choose 'X11' from 'SSH' list
• 7. Check 'Enable X11 Forwarding'

• 8. Choose 'Session' from 'Category' list
• 9. Click 'Save'

Starting the X Server on Windows

Configuring Xming

Just run "All Programs > Xming Xming" and leave all at it’s defaults as show in the picture bellow. It should work if you've got PuTTY configured.

Connecting

• 1. Start Xming
• 2. Start Putty
• 3. Double click on the saved session you want

• 4. Enter username and password as requested
• 5. You should now be able to run X applications from the host
  on your local desktop

Based On: http://www.math.umn.edu/systems_guide/putty_xwin32.html

PuTTY With Multiple Windows (Tabs)

Get Tabs for your PuTTY

It seems like everybody uses the free PuTTY client for accessing SSH from Windows, but the lack of a tabbed interface has kept me using the commercial SecureCRT application for years… until now.

With the PuTTY Connection Manager you can not only use tabs, but also wrap PuTTY in a slick interface. The underlying client is still the same putty.exe that you are used to… in fact the application doesn’t even come bundled with it.

The first time you launch the application you’ll be asked to enter the location to your copy of PuTTY.

And finally, a tabbed version of PuTTY!

The connection manager can be docked to the side by using the little pushpin button.

Right-clicking on a tab or using the Tools menu will allow you to get to the PuTTY menu

In the configuration dialog you can specify a bunch of options including an automatic login macro or passing command line parameters to putty.

You can either click the configuration button above, or choose PuTTY Configuration from the tools menu.

Which brings up the PuTTY Configuration dialog for the actual putty.exe underlying application.

There’s a lot more features to this application that I haven’t gotten to yet… you can even change the theme.

Download PuTTY Connection Manager from puttycm.free.fr

Taken From: http://www.howtogeek.com/howto/the-geek-blog/get-tabs-for-your-putty/

Remote Applications via X11 - Easy Way (over ssh)

Here I will show you how to interact with applications remotely. This is quite useful when you have for example an Ubuntu Server that doesn't have a graphical environment (Gnome or KDE) and a Desktop that has and you need to use some graphical applications on the Ubuntu Server but you can't because you don't have a graphical environment.

So whit this you can show and interact with the graphical applications on the Ubuntu Server, using your Desktop's, graphical environment. So in the X11 world you have the following:

Ubuntu Server - X11 Client --> Application is executed
Ubuntu Desktop - X11 Server --> Application is shown

It's a bit confusing at first, that your Ubuntu Server is your X11 Client, and you Desktop is the X11 Server.

Note: this was tested on Ubuntu 8.04 and 9.04.

X11 Server - Where the remote apps will be shown
===================================

my_user@my_desktop:~$ ssh -X root@remote_server
root@remote_server:~$

Now you have a what looks like a normal ssh remote terminal on the "remote_server". But when you execute an graphical apps on the remote server it will be displayed on your desktop, for example:

root@remote_server:~$ gedit

With this you can make a text file on your machine tha will be saved on the remote server.

If you want ssh to always act like this, have the following line in your /etc/ssh/ssh_config:

ForwardX11 yes

With this method all the data over the network will be encrypted, because of ssh, but if you want to kick it old school, whit no encryption an a lot more complicated using X11 directly, you can check the post "Run Applications Remotely via X11 - Hard Way"

Based on: http://wiki.linuxquestions.org/wiki/X11_forwarding_with_OpenSSH

Secured Remote Desktop/Application Sessions

Run graphical applications from afar, securely.

There are many different ways to control a Linux system over a network, and many reasons you might want to do so. When covering remote control in past columns, I've tended to focus on server-oriented usage scenarios and tools, which is to say, on administering servers via text-based applications, such as OpenSSH. But, what about GUI-based applications and remote desktops?

Remote desktop sessions can be very useful for technical support, surveillance and remote control of desktop applications. But, it isn't always necessary to access an entire desktop; you may need to run only one or two specific graphical applications.

In this month's column, I describe how to use VNC (Virtual Network Computing) for remote desktop sessions and OpenSSH with X forwarding for remote access to specific applications. Our focus here, of course, is on using these tools securely, and I include a healthy dose of opinion as to the relative merits of each.

Remote Desktops vs. Remote Applications

So, which approach should you use, remote desktops or remote applications? If you've come to Linux from the Microsoft world, you may be tempted to assume that because Terminal Services in Windows is so useful, you have to have some sort of remote desktop access in Linux too. But, that may not be the case.

Linux and most other UNIX-based operating systems use the X Window System as the basis for their various graphical environments. And, the X Window System was designed to be run over networks. In fact, it treats your local system as a self-contained network over which different parts of the X Window System communicate.

Accordingly, it's not only possible but easy to run individual X Window System applications over TCP/IP networks—that is, to display the output (window) of a remotely executed graphical application on your local system. Because the X Window System's use of networks isn't terribly secure (the X Window System has no native support whatsoever for any kind of encryption), nowadays we usually tunnel X Window System application windows over the Secure Shell (SSH), especially OpenSSH.

The advantage of tunneling individual application windows is that it's faster and generally more secure than running the entire desktop remotely. The disadvantages are that OpenSSH has a history of security vulnerabilities, and for many Linux newcomers, forwarding graphical applications via commands entered in a shell session is counterintuitive. And besides, as I mentioned earlier, remote desktop control (or even just viewing) can be very useful for technical support and for security surveillance.

Using OpenSSH with X Window System Forwarding

Having said all that, tunneling X Window System applications over OpenSSH may be a lot easier than you imagine. All you need is a client system running an X server (for example, a Linux desktop system or a Windows system running the Cygwin X server) and a destination system running the OpenSSH dæmon (sshd).

Note that I didn't say “a destination system running sshd and an X server”. This is because X servers, oddly enough, don't actually run or control X Window System applications; they merely display their output. Therefore, if you're running an X Window System application on a remote system, you need to run an X server on your local system, not on the remote system. The application will execute on the remote system and send its output to your local X server's display.

Suppose you've got two systems, mylaptop and remotebox, and you want to monitor system resources on remotebox with the GNOME System Monitor. Suppose further you're running the X Window System on mylaptop and sshd on remotebox.

First, from a terminal window or xterm on mylaptop, you'd open an SSH session like this:

mick@mylaptop:~$ ssh -X admin-slave@remotebox
admin-slave@remotebox's password: **********
Last login: Wed Jun 11 21:50:19 2008 from dtcla00b674986d
admin-slave@remotebox:~$

Note the -X flag in my ssh command. This enables X Window System forwarding for the SSH session. In order for that to work, sshd on the remote system must be configured with X11Forwarding set to yes in its /etc/ssh/sshd.conf file. On many distributions, yes is the default setting, but check yours to be sure.

Next, to run the GNOME System Monitor on remotebox, such that its output (window) is displayed on mylaptop, simply execute it from within the same SSH session:

admin-slave@remotebox:~$ gnome-system-monitor &

The trailing ampersand (&) causes this command to run in the background, so you can initiate other commands from the same shell session. Without this, the cursor won't reappear in your shell window until you kill the command you just started.

At this point, the GNOME System Monitor window should appear on mylaptop's screen, displaying system performance information for remotebox. And, that really is all there is to it.

This technique works for practically any X Window System application installed on the remote system. The only catch is that you need to know the name of anything you want to run in this way—that is, the actual name of the executable file.

If you're accustomed to starting your X Window System applications from a menu on your desktop, you may not know the names of their corresponding executables. One quick way to find out is to open your desktop manager's menu editor, and then view the properties screen for the application in question.

For example, on a GNOME desktop, you would right-click on the Applications menu button, select Edit Menus, scroll down to System/Administration, right-click on System Monitor and select Properties. This pops up a window whose Command field shows the name gnome-system-monitor.

Figure 1 shows the Launcher Properties, not for the GNOME System Monitor, but instead for the GNOME File Browser, which is a better example, because its launcher entry includes some command-line options. Obviously, all such options also can be used when starting X applications over SSH.

Figure 1. Launcher Properties for the GNOME File Browser (Nautilus)

If this sounds like too much trouble, or if you're worried about accidentally messing up your desktop menus, you simply can run the application in question, issue the command ps auxw in a terminal window, and find the entry that corresponds to your application. The last field in each row of the output from ps is the executable's name plus the command-line options with which it was invoked.

Once you've finished running your remote X Window System application, you can close it the usual way (selecting Exit from its File menu, clicking the x button in the upper right-hand corner of its window and so forth). Don't forget to close your SSH session too, by issuing the command exit in the terminal window where you're running SSH.

Virtual Network Computing (VNC)

Now that I've shown you the preferred way to run remote X Window System applications, let's discuss how to control an entire remote desktop. In the Linux/UNIX world, the most popular tool for this is Virtual Network Computing, or VNC.

Originally a project of the Olivetti Research Laboratory (which was subsequently acquired by Oracle and then AT&T before being shut down), VNC uses a protocol called Remote Frame Buffer (RFB). The original creators of VNC now maintain the application suite RealVNC, which is available in free and commercial versions, but TightVNC, UltraVNC and GNOME's vino VNC server and vinagre VNC client also are popular.

VNC's strengths are its simplicity, ubiquity and portability—it runs on many different operating systems. Because it runs over a single TCP port (usually TCP 5900), it's also firewall-friendly and easy to tunnel.

Its security, however, is somewhat problematic. VNC authentication uses a DES-based transaction that, if eavesdropped-on, is vulnerable to optimized brute-force (password-guessing) attacks. This vulnerability is exacerbated by the fact that many versions of VNC support only eight-character passwords.

Furthermore, VNC session data usually is transmitted unencrypted. Only a couple flavors of VNC support TLS encryption of RFB streams, and it isn't clear how securely TLS has been implemented even in those. Thus, an attacker using a trivially hacked VNC client may be able to reconstruct and view eavesdropped VNC streams.

Luckily, as it operates over a single TCP port, VNC is easy to tunnel through SSH, through Virtual Private Network (VPN) sessions and through TLS/SSL wrappers, such as stunnel. Let's look at a simple VNC-over-SSH example.

But Don't Real Sysadmins Stick to Terminal Sessions?

If you've read my book or my past columns, you've endured my repeated exhortations to keep the X Window System off of Internet-facing servers, or any other system on which it isn't needed, due to X's complexity and history of security vulnerabilities. So, why am I devoting an entire column to graphical remote system administration?

Don't worry. I haven't gone soft-hearted (though possibly slightly soft-headed); I stand by that advice. But, there are plenty of contexts in which you may need to administer or view things remotely besides hardened servers in Internet-facing DMZ networks.

And, not all people who need to run remote applications in those non-Internet-DMZ scenarios are advanced Linux users. Should they be forbidden from doing what they need to do until they've mastered using the vi editor and writing bash scripts? Especially given that it is possible to mitigate some of the risks associated with the X Window System and VNC?

Of course they shouldn't! Although I do encourage all Linux newcomers to embrace the command line. The day may come when Linux is a truly graphically oriented operating system like Mac OS, but for now, pretty much the entire OS is driven by configuration files in /etc (and in users' home directories), and that's unlikely to change soon.

Tunneling VNC over SSH

To tunnel VNC over SSH, your remote system must be running an SSH dæmon (sshd) and a VNC server application. Your local system must have an SSH client (ssh) and a VNC client application.

Our example remote system, remotebox, already is running sshd. Suppose it also has vino, which is also known as the GNOME Remote Desktop Preferences applet (on Ubuntu systems, it's located in the System menu's Preferences section). First, presumably from remotebox's local console, you need to open that applet and enable remote desktop sharing. Figure 2 shows vino's General settings.

Figure 2. General Settings in GNOME Remote Desktop Preferences (vino)

If you want to view only this system's remote desktop without controlling it, uncheck Allow other users to control your desktop. If you don't want to have to confirm remote connections explicitly (for example, because you want to connect to this system when it's unattended), you can uncheck the Ask you for confirmation box. Any time you leave yourself logged in to an unattended system, be sure to use a password-protected screensaver!

vino is limited in this way. Because vino is loaded only after you log in, you can use it only to connect to a fully logged-in GNOME session in progress—not, for example, to a gdm (GNOME login) prompt. Unlike vino, other versions of VNC can be invoked as needed from xinetd or inetd. That technique is out of the scope of this article, but see Resources for a link to a how-to for doing so in Ubuntu, or simply Google the string “vnc xinetd”.

Continuing with our vino example, don't close that Remote Desktop Preferences applet yet. Be sure to check the Require the user to enter this password box and to select a difficult-to-guess password. Remember, vino runs in an already-logged-in desktop session, so unless you set a password here, you'll run the risk of allowing completely unauthenticated sessions (depending on whether a password-protected screensaver is running).

If your remote system will be run logged in but unattended, you probably will want to uncheck Ask you for confirmation. Again, don't forget that locked screensaver.

We're not done setting up vino on remotebox yet. Figure 3 shows the Advanced Settings tab.

Figure 3. Advanced Settings in GNOME Remote Desktop Preferences (vino)

Several advanced settings are particularly noteworthy. First, you should check Only allow local connections, after which remote connections still will be possible, but only via a port-forwarder like SSH or stunnel. Second, you may want to set a custom TCP port for vino to listen on via the Use an alternative port option. In this example, I've chosen 20226. This is an instance of useful security-through-obscurity; if our other (more meaningful) security controls fail, at least we won't be running VNC on the obvious default port.

Also, you should check the box next to Lock screen on disconnect, but you probably should not check Require encryption, as SSH will provide our session encryption, and adding redundant (and not-necessarily-known-good) encryption will only increase vino's already-significant latency. If you think there's only a moderate level of risk of eavesdropping in the environment in which you want to use vino—for example, on a small, private, local-area network inaccessible from the Internet—vino's TLS implementation may be good enough for you. In that case, you may opt to check the Require encryption box and skip the SSH tunneling.

(If any of you know more about TLS in vino than I was able to divine from the Internet, please write in. During my research for this article, I found no documentation or on-line discussions of vino's TLS design details whatsoever—beyond people commenting that the soundness of TLS in vino is unknown.)

This month, I seem to be offering you more “opt-out” opportunities in my examples than usual. Perhaps I'm becoming less dogmatic with age. Regardless, let's assume you've followed my advice to forego vino's encryption in favor of SSH.

At this point, you're done with the server-side settings. You won't have to change those again. If you restart your GNOME session on remotebox, vino will restart as well, with the options you just set. The following steps, however, are necessary each time you want to initiate a VNC/SSH session.

On mylaptop (the system from which you want to connect to remotebox), open a terminal window, and type this command:

mick@mylaptop:~$ ssh -L 20226:remotebox:20226 admin-slave@remotebox

OpenSSH's -L option sets up a local port-forwarder. In this example, connections to mylaptop's TCP port 20226 will be forwarded to the same port on remotebox. The syntax for this option is “-L [localport]:[remote IP or hostname]:[remoteport]”. You can use any available local TCP port you like (higher than 1024, unless you're running SSH as root), but the remote port must correspond to the alternative port you set vino to listen on (20226 in our example), or if you didn't set an alternative port, it should be VNC's default of 5900.

That's it for the SSH session. You'll be prompted for a password and then given a bash prompt on remotebox. But, you won't need it except to enter exit when your VNC session is finished. It's time to fire up your VNC client.

vino's companion client, vinagre (also known as the GNOME Remote Desktop Viewer) is good enough for our purposes here. On Ubuntu systems, it's located in the Applications menu in the Internet section. In Figure 4, I've opened the Remote Desktop Viewer and clicked the Connect button. As you can see, rather than remotebox, I've entered localhost as the hostname. I've also entered port number 20226.

Figure 4. Using vinagre to Connect to an SSH-Forwarded Local Port

When I click the Connect button, vinagre connects to mylaptop's local TCP port 20226, which actually is being listened on by my local SSH process. SSH forwards this connection attempt through its encrypted connection to TCP 20226 on remotebox, which is being listened on by remotebox's vino process.

At this point, I'm prompted for remotebox's vino password (shown in Figure 2). On successful authentication, I'll have full access to my active desktop session on remotebox.

To end the session, I close the Remote Desktop Viewer's session, and then enter exit in my SSH session to remotebox—that's all there is to it.

This technique is easy to adapt to other versions of VNC servers and clients, and probably also to other versions of SSH—there are commercial alternatives to OpenSSH, including Windows versions. I mentioned that VNC client applications are available for a wide variety of platforms; on any such platform, you can use this technique, so long as you also have an SSH client that supports port forwarding.

Conclusion

Thus ends my crash course on how to control graphical applications over networks. I hope my examples of both techniques, SSH with X forwarding and VNC over SSH, help you get started with whatever particular distribution and software packages you prefer. Be safe!

Resources

The Cygwin/X (information about Cygwin's free X server for Microsoft Windows): x.cygwin.com.

Tichondrius' HOWTO for setting up VNC with resumable sessions—Ubuntu-centric, but mostly applicable to other distributions: ubuntuforums.org/showthread.php?t=122402.

Wikipedia's VNC article, which may be helpful in making sense of the different flavors of VNC: en.wikipedia.org/wiki/Vnc.

Mick Bauer (darth.elmo@wiremonkeys.org) is Network Security Architect for one of the US's largest banks. He is the author of the O'Reilly book Linux Server Security, 2nd edition (formerly called Building Secure Servers With Linux), an occasional presenter at information security conferences and composer of the “Network Engineering Polka”.

Taken From: Linux Journal Contents #173, September 2008

Scp - Secure File Transfer (using ssh) Between UNIX Machines

Scp - Secure File Transfer (using ssh) between UNIX machines

Introduction and setup

Scp is a utility which allows files to be copied between machines. Scp is an updated version of an older utility named Rcp. It works the same, except that information (including the password used to log in) is encrypted. Also, if you have set up your .shosts file to allow you to ssh between machines without using a password as described in help on setting up your .shosts file, you will be able to scp files between machines without entering your password.
Usage of the Scp Command



The general form of the command is:

$ scp source-specification destination-specification

where source-specification indicates which file or directory is to be copied, and destination-specification indicates where the copied material is to be placed.

Either the source or the destination may be on the remote machine; i.e., you may copy files or directories into the account on the remote system OR copy them from the account on the remote system into the account you are logged into.



Example:

$ scp myfile xyz@sdcc7:myfile


To copy a directory, use the -r (recursive) option. Example:

$ scp -r mydir xyz@sdcc7:mydir



File Specification Formats

The format for the remote specification (source or destination) is:

user@machine:filename

where filename is the name (path) of the file or directory relative to the home (login) directory on the remote system.



The format for file specification on the local system is just:

filename


where fname is the name (path) relative to the current working directory on that system.
How scp is similar to cp

Just like the cp command, scp will overwrite an existing destination file. In addition, if the destination is an existing directory, the copied material will be placed beneath the directory.
Examples of remote file copies

1. While logged into xyz on sdcc7, copy file "letter" into file "application" in remote account abc on sdcc3:

$ scp letter abc@sdcc3:application


2. While logged into abc on sdcc3, copy file "foo" from remote account xyz on sdcc7 into filename "bar" in abc:

$ scp xyz@sdcc7:foo bar


3. While logged into account xyz on sdcc7, copy file "garfield" from subdirectory "comix" into filename "fatcat" in subdirectory "stuff" in remote account abc on sdcc3:

$ scp comix/garfield abc@sdcc3:stuff/fatcat


4. While logged into account abc on sdcc3, copy file "garfield" from subdirectory "comix" of account xyz on sdcc7 into subdirectory "stuff" with the same name "garfield":

$ scp xyz@sdcc7:comix/garfield stuff


5. While logged into account abc on sdcc3 , copy subdirectory "Section" into a new subdirectory called "Section" in existing subdirectory "Chapter" in account xyz on sdcc7:

$ scp -r Section xyz@sdcc7:Chapter


6. From account abc on sdcc3, copy entire account to ir123 on iacs5. This needs to be done from the parent directory of the account to be moved.

$ cd
$ cd ..
$ scp -r abc ir123@iacs5:abc



For more information about the scp (secure copy) command, check the on-line manual page for scp:

$ man scp