ssh exercise
Part 1 - establishing an encrypted login session to an ssh
server using key-based authentication
Part 2 - port forwarding beyond the ssh server
The ssh "server" is 66.159.240.70
I WILL START THE SSH SERVER DAEMON ON THE SERVER MACHINE (requires root)
The "target" is 192.168.3.7, at the remote site as ssh server's co-member on
their common LAN.
I WILL START A SERVER PROGRAM TO BE AVAILABLE ON THAT MACHINE'S PORT 9999 (server3.c)
Note that there are 2 different servers here. The target server, which offers the service that the client is really interested in getting. And the ssh server, whose ssh service plays a facilitating role in getting it. Both client programs are concentrated on the one client machine. The word "server" below refers to the ssh server.
Part 1 - establishing an encrypted login session to an ssh server using key-based authentication
ON THE CLIENT, IN CLASS
Login, as any user. Create a key pair, of dsa type
cd
ssh-keygen -t dsa (respond to all the prompts by pressing enter)
Note the resultant new directory (.ssh within your home directory) and the 2 files in it (id_dsa, id_dsa.pub).
ls -ld .ssh
ls -l .ssh
id_dsa.pub is your public key. Move a copy of it to the server using ftp. Login as the user indicated by your instructor
(e.g., student1) with the password indicated (e.g., password).
cd .ssh
ftp <server address>
[supply name and password when prompted]
ftp> put id_dsa.pub
ftp> quit
Now that you have a matched pair of keys, and a copy of the public one on the server,
you'll next go to the server and place the public key into the strategic file used by ssh to
enable key-based authentication for logging in. That file is
/home/<user>/.ssh/authorized_keys2, where <user> is the user as whom you
will want to log in.
ON THE SERVER, REMOTE FROM CLASS
telnet to the server. Login as the user indicated by your instructor (e.g., student1) with the password indicated (e.g.,
password).
In your home directory create a subdirectory named .ssh. (Note it will be "hidden" because its name starts with a period. If
you want to see it using ls, be sure to use ls's -a option.) Then restrict access to it by explicitly setting its permissions
to exclude everybody but you (an ssh requirement).
cd
mkdir .ssh
chmod 700 .ssh
In that directory create a file named authorized_keys2, make its permissions suitably restrictive, then get the public key
you imported from your client in class into this file:
cd .ssh
touch authorized_keys2 (or, echo -n "" > authorized_keys2)
chmod 600 authorized_keys2
cat ../id_dsa.pub >> authorized_keys2
Leave the server by quitting from telnet.
exit
BACK ON THE CLIENT AGAIN, IN CLASS
Logged in as the same user as before, gain a remote prompt from the server as the indicated user (e.g., student1):
ssh student1@<server address>
answer "yes" to any question about host authenticity that may appear. You should get the prompt and be able to operate on the
remote machine as student1 much as if you had used telnet. Exit the remote server by quitting from
ssh.
Note that what you have done here:
What you set up: remote command access via ssh
How you did it: by remote command access via telnet
Logically, it's pointless to bother getting remote access when you already have it. Practically in the real world, you would not already have it. Telnet would not be available to you. Telnet in parallel with ssh makes no sense because it defeats ssh's purpose of confining remote access to secure connections. In the absence of telnet access to the server, that is in the real world, key placement would have to be done by cooperation of ssh server's local owner or administrator.
Part 2 - port forwarding beyond the ssh server
Now, reconnect with the remote server, this time amending your ssh invocation to afford the additional feature of port forwarding. In doing so choose a random port number like, say, 3350.
ssh -L 3350:<target address>:9999 student1@<server address>
It looks no different, you will still just see a prompt from the server. However a port forwarding arrangement beyond the server has been
set up. It extends to the target machine on the server's LAN at the remote site. Specifically, to that machine's port 9999.
You now want to run, on your class machine, the client for the server that is running on the target machine. The server is server3.c, so the client is client3.c.
(You'll need to get into another virtual terminal or terminal window, as the one
you were in till now no longer offers you your local machine's prompt but that
of the remote server.) Obtain a copy of client3.c in your home directory. Edit it to talk to
your machine (at either 127.0.0.1 or your NIC's address). And to talk to
your machine's port 3350. Compile it
gcc -o client3 client3.c
Run it.
./client3
You should see the server's response. But the server isn't running on your machine, to which you directed your
connection. It is however running over on the remote target machine. Who produced the server response that you saw?
How did it get to you?
When finished, please clean up by removing your .ssh directory.
cd
rm -rf .ssh/