Repeat after me: “I will never use Telnet unless I have a direct serial connection to a router.” Got it? Telnet is disastrously unsafe; it transmits your user name and password in clear text.
In Windows, you will need a SSH client program. Consider putty, for instance. In Unix, SSH is built into the operating system and is invoked by a simple command:
ssh <destination_server>
You can specify the destination_server by hostname (as long as it’s resolvable) or IP address.
| Commands | |
| Command | Purpose |
| ssh <hostname> or ssh <IP_address> |
Connect to a remote host. NOTE THAT YOU WILL LOG IN AS YOUR CURRENT LOCAL USER (a very, very bad thing if you are logged in as root). |
| ssh <hostname> -l glenn | Connect to a remote host, using the login name of glenn. |
| exit | Disconnect and end your session |
For the most part, working in a SSH connection involves simply naming the host as an argument to the ssh command. You must, of course, have an account on the remote computer.
ssh socrates.philosophers.com
The one general function you should be aware of, beyond simply opening a remote session, is using SSH to tunnel to a remote connection.
Consider a case in which you want to connect to a remote MySQL server (hostname my_server), but it lies behind a corporate firewall, and furthermore it only accepts connections from the web server (web_server). Though this may seem like an extremely advanced connection, it is a very common situation in enterprise web-application server configurations.
Network World’s Steve Blass (“Ask Dr. Internet”) gives an excellent solution to this situation at http://www.networkworld.com/columnists/2005/060605internet.html. Essentially you’ll set up a SSH tunnel, by entering from a command line:
ssh -l loginID -L 3306:mysqlhost:3306 shellhost
for instance:
ssh -l fred -L 3306:mysql_server_hostname:3306 webserver_hostname
Notice in particular the localport:hostname:hostport syntax. If you use a graphical SSH client, set up this connection in that client, and open it before making your MySQL Connector/ODBC connection. (Thanks Steve!)
This is only one of many kinds of tunnelling connections you can make.
See SSH Tunneling by Roderick Smith at http://www.linux-mag.com/id/1705/ for a good discussion.
Closely related to Secure Shell are the “r” tools, rlogin, rcp and rsh.
You can’t do a thing with these tools until you’ve set up access. There are several methods.
This file holds a list (on the server) of hosts that can connect with the “r” tools, with contents similar to this:
www.somedomain.com
GenesisThis allows logged-in users on the hosts www.somedomain.com and Genesis to log into the server. For your host to connect, it must be listed here. You will not be asked for a password.
You must exist as the same user on both server and local host: if you’re logged in as glenn on your host, you will be logged in as glenn on the server.
Additionally, root cannot be trusted for remote access using a hosts.equiv file.
Each user can have a personal configuration file: /home/<username>/.rhosts. Like a hosts.equiv file, it will contain contents similar to this:
www.somedomain.com
Genesiswhich allow users from either of these hosts to connect to the local computer. They must exist as the same user on both server and local host: if they’re logged in as glenn on the remote host, they will be logged in as glenn on the local computer.
If there is a /root/.rhosts file, remote root users can connect as root to the local computer(!).
There must be either a /etc/krb.equiv file (on the server) or a /home/<username>/.k5login file (on the local machine) for Kerberos authentication. This file will list the users and Kerboros realms that are allowed. This has the (enormous) benefit of preventing other users from viewing your traffic by encrypting it.
Provided that the remote computer has trusted access set up, you can command:
rlogin <remote_server_name>
and get a remote shell connection on that machine. Your shell prompt will still be your local computer’s prompt (which can be a bit confusing).
This is a great command. As you may suspect, it copies a remote file to the local computer, or vice versa.
rcp <remote_server_name>:/home/glenn/file.txt /home/glenn/
Be clear – be really clear – about the paths at both ends!
This is a really great command. It can sync files between a local and remote computer, so that both have the newest versions. It is also extremely complex (see man rsync). But it can be used very simply:
rsync -avz /home/glenn <remote_server_name>:/backup/glenn
This would sync the contents of my home directory to a backup directory on the remote host.
You should note that rsync requires an rsync daemon on the remote host, or preconfigured remote access including a secure protocol such as ssh.
Finally, you should know that rsync is NOT of the same family as the previous “r” commands, and is not necessarily inherently unsafe. It just can be.