Using SSH
SSH or Secure Shell allows you to remotely login to and work on your system. There are several implementations for SSH around, the most commonly used in Linux is OpenSSH, but there are other SSH implementations.
To SSH in Linux from the Bash command prompt you would type:
$ ssh user@remote1
"user" is the login name and "remote" would be the DNS name of the computer you want to login to. If this the first time that you have connected to that computer you will be shown the name and a "fingerprint" number, and asked to confirm it. For all future sessions SSH then uses the fingerprint to ensure that the other computer is the same system as before, and not merely claiming the same name.
SSH and Telnet are almost the same, but in SSH all of the information is encrypted so that even if someone intercepted the packets, they would not be able to read or use them (theoretically).
To SSH from Windows, you need an application like PuTTY or TeraTerm.
Using scp
SSH also provides a utility called scp (Secure CoPy) to encrypt file transfers from one host to another. The basic syntax of scp works like this:
To move a file to a remote host:
$ scp filename user@remote1:/path/to/destination/dir
So if we wanted to copy the file named "foo" to a remote host "remote1" with the user "tux" and a target directory of "/home/tux/files/" you would use:
$ scp foo tux@remote1:/home/tux/files/
To copy a file from the remote host to the current directory:
$ scp user@remote1:/path/to/file filename
So using the same example, to copy the file "/home/tux/files/foo" on the remote host and rename it as "baz" on our current system we'd do:
$ scp tux@remote1:/home/tux/files/foo baz
This method even allows to securely copy files between remote hosts if you have SSH access to this hosts:
$ scp user1@remote1:foo.txt user2@remote2:foo_from_remote1.txt
will copy "foo.txt" from remote1 to "foo_from_remote1.txt" on remote2.
OpenSSH includes the subsystem SFTP. It is (quite predictably) an FTP clone that runs through SSH:
$ sftp tux@remote1 > get foo
WinSCP - A Windows implementation of scp
WinSCP is a graphical SSH (SFTP and SCP) client for Windows. Its main function is secure copying of files between a local and a remote computer, and it works much like the FTP clients in common use. Beyond this function, WinSCP manages some other actions with files. A plugin for FAR manager is available too. You can find more information and download WinSCP here:
http://sourceforge.net/projects/winscp
SSHDos - A DOS implementation of ssh
SSHDos is a pure DOS SSH (SSH, SFTP and SCP) client. It's a convenient way of transferring files from linux to dos or the other way around, requiring a minimum of fuss. It also supports terminal emulation, making it a good choice for thin clients on ancient hardware (telnet included if ssh is too heavy).
Public key authentication
Another cool feature of SSH is that you can setup public/private key authentication. First it is necessary to generate an SSH keypair that will be used for authentication. During the process you have the option to enter a passphrase which be used along with the private key for two-factor authentication. Alternatively, you may supply an empty passphrase, which will allow you to login to remote machines without typing a password at all, provided that you hold the private key that is paired with the public key on the remote machine. Using a key to login is potentially more secure, since the user must have access to a file holding the private key to login (possibly in addition to a passphrase), rather than simply being able to guess a password alone. To create a pair of keys type this:
$ ssh-keygen -t dsa -f ~/.ssh/id_dsa -N
This will create a public/private key pair in your ~/.ssh directory - the keys are the files id_dsa (the private key) and id_dsa.pub (the public key). Now you will need to append id_dsa.pub to the ~user/.ssh/authorized_keys file in your home directory on the remote server. OpenSSH comes with a command 'ssh-copy-id' which can do this for you.
now you can easily:
$ ssh user@remote
and get the shell without typing the password. If the usernames are the same on the local and remote hosts you can even omit the username. There are, of course, some pre-requisites - on your local machine /etc/ssh/ssh_config should contain the line:
IdentityFile ~/.ssh/id_dsa
and the remote /etc/ssh/sshd_config should have the lines:
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
One problem that is tricky to debug is when the permissions of the .ssh directory on the remote host are not set up correctly. SSH will not use the keys unless the write permissions are removed for group and others; this prevents other people from dumping their public keys into your .ssh directory and then accessing your account. Set the .ssh directory permissions to "700".
Another useful trick with SSH - you can suspend your SSH session and resume it. If you work from console and you SSH to remote1 your shell becomes remote1, so if you need to do something on your local machine you would normally have another terminal open, but you can avoid this by placing the SSH session in background by typing suspend or ~ followed by ctrl+z, and the SSH session will go to the background. To bring back your SSH session on remote1 just type fg. (This may vary depending on your SSH client software.)
The following page has a nice tutorial: http://fedoranews.org/dowen/sshkeys/
Forwarding X11
You can have the server you login to forward X to the X server controlling the display on your local machine, so that you can run programs on remote computers and they'll appear on your screen alongside the programs running on your local machine.
This can be done by adding "ForwardX11 yes" to your ~/.ssh/config. SSH will handle setting your display automatically, which includes setting the DISPLAY environment variable (usually to localhost:10, or a higher-numbered display if that is taken), and setting up the xauth file for access to the X Server running on the SSH client computer.
For this to work the remote sshd must also be configured to allow X forwarding. This option is called "X11Forwarding yes" and resides in /etc/ssh/sshd_config.
Once these are set you can access remote programs at will, like so:
$ ssh user@remote1:/usr/bin/gedit &
Alternatively to setting "ForwardX11 yes", use the command ssh -X remote to connect. Also, you can use ssh -x remote to disable it for a single session if "ForwardX11 yes" is in your ~/.ssh/config file.
In recent openSSH, there is also ssh -Y (or the option "ForwardX11Trusted yes") . This enables 'trusted' X11 forwarding. This used to be the default with older versions, but because of a potential security vulnerability (which allowed other X11 clients to 'sniff' or alter data from the remote client) this was changed. Most people won't need to use this '-Y' option (and should not have "ForwardX11Trusted yes" set in their ssh config file).
Launching console applications and resume
Sometimes you just want to connect to a distant server, launch a command and quit. The problem is that with applications like putty, once you connect and launch a command you have to keep your connection opened, your session opened. If you close putty, your session is closed and if your command has not finished it is lost. A solution to this problem is to use 'screen'. What screen does is simply create you a new "virtual" console you can leave running and resume at any time.
Say you want to run bittorrent on a distant machine, here is an example:
- Login by ssh
- Then type screen followed by enter :
[user@fc4box ~]# screen
- The putty window name changes: [screen 0:bash] user@fc4box ~ - and you have a shell again:
[user@fc4box ~]#
- Run your command and download begins:
[user@fc4box ~]# bittorrent-console http://www.torrent-site.com/torrentfile.torrent
- Now all I have to do is detach from this 'screen' you hit ctrl+A followed by D, this brings you back to the normal shell, putty's window name goes back to user@fc4box ~ :
[user@fc4box ~]#
- You can leave or close putty.
- Now at any time you want to check your download, login to your machine and type :
[user@fc4box ~]# screen -r
This will bring you back to the screen you have created. In my case my download has continued while I was logged out. You can use screen in many ways, for more info check screen.