[Sussex] SCP - setup problem

Steve Dobson steve at dobson.org
Tue May 10 11:37:08 UTC 2005


Brendan

On Tue, May 10, 2005 at 08:35:24AM +0100, Brendan Whelan wrote:
> Following the help which I was given it was requested that I provide a
> summary of the solution. The following technique worked for me but there may
> be neater ways and there could be variants between different versions of
> Linux:

It is good to see that others are beginning to produce pages for the SLUG
website.  So thank you Brendan.

The idea of posting it to the list is so that we can all review it and add
our own comments and suggestions so the help can be as compressive as possible.
 
> Setting up an SCP link between Linux servers
> 
> Introduction
<snip>

I think a section on the software that needs to be installed should
be here.  If it is a standard part of the install please state that
for FC3.

For Debian please say that the following package needs to be installed:
   ssh

Using the command:
  # apt-get install ssh

And user should, when prompted:
  1). install with SUID to use Protocol 2 host-based authentication, and
  2). start the sshd server.

Can a gentoo user please add the commands need to e-merge ssh and get
the server running.

I think you also need to talk about phsyically linking the two systems
together.  Crossover cables vs. A swtch/hub.

> Setting up a link
> 
> Before starting check that the /etc/hosts file has BOTH the machine defined
> 
> nnn.nnn.nnn.nnn                        localhost.name  name
> name
> 
> mmm.mmm.mmm.mmm            localhost.other_name      other_name
> other_name

I think this needs to be re-written.  I can see how it would be
confusing to some (if they didn't know the format of the hosts file).

You example is also wrong.  "localhost" is a generic name (without a
domain), and should _always_ be assocated with 127.0.0.1.

I also think that you should refer the reader to the man page for
hosts where you will find (at least on the Debian system) a very
good example:
        127.0.0.1       localhost
        192.168.1.10    foo.mydomain.org  foo
        192.168.1.13    bar.mydomain.org  bar
        146.82.138.7    master.debian.org      master
        209.237.226.90  www.opensource.org

> The above may not be necessary on a live network as the DNS service may
> resolve the information.
> 
> The following assumes that the account is user is xx and has a home of
> /home/xx and that the transfer is to be bidirectional:

I think more concreate examples would be used.  Call the user "fred"
or "steve" or "user".  Personally I find "xx" confusuing.
 
>   1.. Log in as the xx user on system nnn. Check that the default home
> directory for the user i.e. /home/xx, is owned by the xx user.

How do they check this?
 
>   2.. In a terminal window su to user xx then cd /home/xx
 
If they have just logged in as the user why do they need to "su" to
them too?  I don't understand the need for this step at all.
 
>   3.. If the .ssh directory is not already present, then in a terminal
> window type:
> 
> mkdir .ssh           Note the dot at the start of the filename.
> 
> chmod 700 .ssh
> 
>   4.. Note: The .ssh directories are normally hidden the view option in
> konqueror browser windows may need temporarily setting to view the results
> of any file creation.

This is not a step, but a note on step 3.
 
>   5.. Create the public and private key which give facilitate remote access
> without the need for passwords. (The private key resides on the server where
> the keys are created and the public key is copied to any other server
> from/to which files are to be transferred.)  Type
> 
> ssh-keygen -t dsa
> 
>   6.. If not already created, a message may appear stating that the .ssh
> subdirectory is being created.

Again this is not a step, but a comment on the previous one.
 
>   7.. Accept the default options as to where the files are to be created and
> the "passphrase" options -  pressing return indicates that no "passphrase"
> is required.
> 
>   8.. The files created can be viewed in the /home/xx/.ssh directory.
> 
> 
>   9.. Repeat steps 1 to 8 on the other system.
> 
> 
>   10.. Copy the id_dsa.pub file to /home/xx/ on the other system. (Use a
> floppy, FTP, etc.) This file can be deleted when the setup process is
> completed.
> 
> 
>   11.. On the other system type:

Shouldn't then just log in?

I'll stop commentting here.  But please provide a refereces section
so readers know where to go to find out more information.


Hope this hasn't put you off.
Steve




More information about the Sussex mailing list