Testing sftp client

[ITSD-ACCS]

I have installed a sftp client in a 11.0 unix machine (T14...). Since the remote host (Third party company) ftp server is not ready for testing. Is there any simple way that I can test my setup, including the public key authorization.

Please noted that I have another unix machine in 10.20 os version

[RAC_1]

You can test it. Do you other server where ssh is installed?? You have 10.20, but it would be difficult to get the ssh/sftp for that OS. In case you get it, you can test as follows.

ssh/sftp can be set to work on three different authentication methods.

1. Host based. - User of .shosts and /etc/shosts.equiv files.
2. PAssword based
3. Use of public/private keys.

For setting up the use of public/private keys is as follows.

Using H/P's Secure Shell & Secure Copy


Purpose:

As we migrate to more secure systems, convenient utilities such as FTP and TELNET will be replaced with more secure systems. Secure Shell (ssh) and Secure Copy (scp) are the standard replacements for these. Over time, the insecure utilities will be completely blocked from use, so all users with HP Unix accounts will need to become familiar with these. Because of the authentication and encryption, making a connection initially is slower than the insecure systems. But once the connection is made, they are equally as fast and convenient.

Authentication & Encryption

Both ssh and scp use public/private key encryption. This document will not cover the theory behind this authentication and encryption algorhythym. This is covered in Practical Unix & Internet Security: 2nd Edition (Garfinkel/Spafford, © 1996, 1991 O'Reilly & Associates, Inc.) in considerable depth. This document will concentrate on the actual use of this technology rather than the theory.


Setting up the keys

1. It is most efficient to take the time to set up all hosts at the same time. If you have an account on 6 machines, set up all 6 at the same time. If you later are granted access to another machine, it is your responsibility to make the modifications to all of them. This is the responsibility of each user rather than a job for the systems administrator.
2. Fastest/easiest way to set up the key files.
a. Open a session on one host using CDE (Citrix Metaframe for Unix is best). Open a standard text terminal session inside the CDE desktop.
b. Also open the text editor from the CDE desktop.
c. On the terminal session, type ssh-keygen -t dsa. Press for the next 3 questions. Do NOT use a passphrase unless instructed to do so by Security, or if standard policies change.
i. The above command will create the .ssh directory under the users' home directory.
ii. It will also create 3 files, you will add a fourth, and a fifth will soon appear.
d. Change into the .ssh directory with cd ~/.ssh.
e. Next, display the public key created with the previous step: cat id_dsa.pub. This will show the lengthy public key.
f. Highlight that public key by holding the left mouse button down, and dragging the cursor down across the displayed characters. There are a LOT of them. The very last will be your user name and the host on which you're working. Make sure that they are all highlighted, but nothing else.
g. At the top of the menu bar, click Edit --->Copy. This loads the character string into the CDE paste buffer
h. Next, move the cursor into the menu bar of the text editor. Click Edit-->Paste. This writes the paste buffer into the text file. At the end of the line, type a single so that the carriage returns to the far left.
i. Return to the text terminal session by clicking on its menu bar. Ensure that your home directory has appropriate permissions. Type cd ../.. which will move up two directories in the hierarchy. List the directory with ll. On the far left, the permissions should read drwxr-xr-x. If they don't, change them with chmod 755 . The secure utilities will not work properly if these permissions are not correct.

j. Next, open a session on the next host on which you will use the secure utilities. Type ssh . You will be challenged with: The authenticity of host ' (ip address)' can't be established. RSA key fingerprint is (long hexadecimal number). Are you sure you want to continue connecting (yes/no)? Answer yes.
k. You will next see Warning: Permanently added '(hostname) (IP address) ' (RSA) to the list of known hosts. You will then be challenged for your password, as normal.
l. Close the session on remote host, return to the standard terminal session on the host. Next, either open a session on another remote host, or continue with step m below if you have completed steps c-k, above on all hosts. You will be creating a text file with the contents of the id_dsa.pub file from each host, separated by a carriage return.
m. When steps c-k have been done on all hosts, save the text file. Click on File-->Save As, and enter /(the path to your home directory/.ssh/authorized_keys. It is essential to save this file in this particular directory with this particular filename. Be sure that this path/filename is in the box near the bottom of the popup window.
n. Next, ensure that the authorized_keys file has the proper permissions. Return to the home session on the first system. Then change into the .ssh directory with cd ~/.ssh.
o. List the .ssh directory with ll. The authorized_keys files should show -rw-r--r-- on the far left. If not, change the permissions with chmod 644 authorized_keys.
p. Next copy the authorized_keys file into the .ssh directory of each remote host on which you ran steps c-k, with scp authorized_keys HOST:/(my home directory)/.ssh/authorized_keys.
q. Lastly, open a session on each host that has the authorized_keys file, with ssh . You will be challenged for a password, but if the previous steps have been done exactly, this will be the last time. You can check this by logging off (with exit or ), then logging on again. You should not be challenged for a password. If so, check permissions as above before opening a help desk ticket.
r. You might want to open a session ON each host, TO each host. Again, you should only be challenged for a password the first time. Afterwards, you may ssh or scp securely without being prompted for a password.
s. If you are later granted access to another host, you must add the contents of its ~/.ssh/id_dsa.pub file to each ~/.ssh/authorized_keys file.

An