I. Introduction SSH
SSH is Secure Shell.
Traditional web services, such as: FTP, POP and Telnet are inherently unsafe because they use clear text to transfer passwords and data on the network, and those who have careless people can intercept these passwords and data. Moreover, the security verification method of these servles has its weakness, which is very susceptible to attacks of "man-in-middle). By using SSH, you can encrypt all transferred data, which is impossible to achieve this kind of attack mode, and also prevent DNS and IP spoofing. There is also an additional advantage that the data transmitted is compressed, so the speed of the transmission can be accelerated. SSH has a lot of features that can be used in place of Telnet, but also providing a secure "channel" for FTP, POP, and even PPP. The initial SSH was developed by a company in Finland. But because of the restrictions of copyright and encryption algorithms, many people now turn to use OpenSSH. OpenSSH is an alternative software for SSH, free, which is expected to have more and more people in the future instead of SSH. SSH is composed of software from the client and the server, two incompatible versions are: 1.x and 2.x. Use SSH 2.x clients that cannot be connected to a service program that is SSH 1.x. OpenSSH 2.x supports SSH 1.x and 2.x.x.
How is SSH's security verification?
From the client, SSH provides two levels of security verification. The first level (skewer-based security verification) As long as you know your account and password, you can log in to the remote host. All transferred data will be encrypted, but you cannot guarantee that the server you are connecting is the server you want to connect. There may be other servers in pretending to be real servers, which are attacked by the "middleman". The second level (key-based security verification) requires relying on the key, that is, you must create a pair of keys for yourself and put the utility key on the server that needs to be accessed. If you want to connect to the SSH server, the client software will send a request to the server, requiring safety verification with your key. After the server receives the request, first look for your public key in your home directory, then compare it with the public key you sent. If the two keys are consistent, the server encrypts "challenge" with a common key and sends it to the client software. After the client software receives "challenge", you can use your private key to decrypt and send it to the server. In this way, you must know the password of your own key. However, compared to the first level, the second level does not need to transmit passwords on the network. The second level not only encrypts all transmitted data, but the "intermediary" is impossible (because he doesn't have your private key). But the entire login process may take 10 seconds.
Second. Installation
OpenSSH-3.7.1P2-1.i386.rpmopenssh-askPASS-3.7.1P2-1.I386.rpmopenssh-askPASS-GNOME-3.7.1P2-1.I386.RPMOPENSSH-Clients-3.7.1p2-1.i386.rpmopenssh- Server-3.7.1p2-1.i386.rpm
http://www.chinaitlab.com/www/news/Article_show.asp?id=4238
Three. Key
After installing OpenSS, test it with the following command: ssh -l [Your Accountname on the remote host] [address of the remote host] If OpenSSH is working properly, you will see the following prompt information: The Authenticity of Host [Hostname] CAN't Be Established. Key FingerPrint IS 1024 5F: A0: 0B: 65: D3: 82: DF: AB: 44: 62: 6D: 98: 9C: Fe: E9: 52. Are you have you want to continue connecting (YES / NO)? OpenSSH tells you that it doesn't know this host, but you don't have to worry about this problem, because you are the first time you log in. Type "Yes". This will add this "identification tag" to the "~ / .ssh / know_hosts" file. This prompt information will not be displayed when I have access to this host. Then, SSH prompts you to enter your account on your account. After entering the port, the SSH connection is created. After this, you can use SSH like Telnet. SSH's key
Generate your own key
Generate and distribute your own key have two benefits: 1) Activity can prevent "Intermediary" attack mode 2) You can use one password to log in to all the letters you want to log in with the following command to generate a key: SSH-KEYGEN If the remote host uses SSH 2.x to use this command: SSH-KEYGEN -D has no problem with SSH1 and SSH2 on the same host, because the key is different Document. The following information will be displayed after the SSH-Keygen command runs: Generating RSA Keys: ............................ ooooooo ..... . oooooo key generation completion. Enter File in Which to save the key (/Home/[user]/.ssh/identity): [Press ENTER] CREATED DIRECTORY '/HOME/[user]/.ssh'. Enter Passphrase: [Enter the password is not displayed on the screen] Enter Same Passphrase Again: [Re-enter a password, if you forget the password, you can only regenerate the key] Your Identification Has Been Saved in /Home/[user]/.ssh/identity. [This is your private key] Your public key has been saved in /Home/[user]/.ssh/identity.pub. The key fingerprint IS: 2A: DC : 71: 2F: 27: 84: A2: E4: A1: 1E: A9: 63: E2: FA: A5: 89 [user] @ [local machine] "ssh-keygen -d" is almost the same However, putting a pair of keys (default) "/ home / [user] /. Ssh / id_dsa" and "/ home / [user] /. Ssh / id_dsa.pub" (public Key). Now you have a pair of keys: public key to distribute to all the remote hosts you want to log in with SSH; private privacy should keep others from knowing your private key. The access rights of the files displayed by "ls -l ~ / .ssh / identity" or "ls -l ~ / .ssh / id_dsa" must be "-rw -------". If you suspect that your key has been known by others, don't hesitate to generate a new key immediately. Of course, you have to re-distribute a public key. Distribute utility mosks
On each remote server you need to connect with SSH, you have to create a ".sssh" subdirectory in your own directory, copy your utility "Identity.pub" to this directory and put it Rename "Authorized_Keys". Then perform: chmod 644 .ssh / authorized_keys is essential. If someone else has written permissions from the "Authorized_Keys" file, SSH will not work. If you want to log in from different computers to the remote host, "Authorized_Keys" file can also have multiple common keys. In this case, a pair of keys must be regenerated on a new computer, then copy the generated "Identify.pub" file and paste into the "Authorized_Keys" file of the remote host. Of course, on the new computer you must have an account, and the key is protected by password. One thing is very important, that is, when you cancel this account, don't forget to delete this pair of keys. Four. Configuration
1) Configure the software of the client
OpenSS has three configurations: command line parameters, user profiles, and system-level profiles ("/ etc / ssh / ssh_config"). The command line parameter takes precedence over the configuration file, the user profile takes precedence over the system configuration file. All parameters of all command lines can be set in the configuration file. Because there is no default user profile when installing, you have to copy the "/ etc / ssh / ssh_config" and rename "~ / .ssh / config". The standard profile is probably like this: [LOTS of Explanations and Possible Options listed] # be paraanoid by Default Host * Forwardagent No Forwardx11 No FallbackTorsh no also has a lot of options to view "Configuration Files" with "MAN SSH" chapter. The profile is read in order. First set the option to effect first. Assume that you have an account called "Bilbo" on www.foobar.com. And you have to combine "SSH-Agent" and "SSH-Add" and use data compression to speed up the transmission speed. Because the host name is too long, you are too lazy to enter such a long name, using "FBC" as a "www.foobar.com" abbreviation. Your profile can be like this: Host * fbc hostname www.foobar.com User Bilbo Forwardagent Yes compression yes # Be Paranoid by Default Host * Forwardagent No Forwardx11 No FallBackTorsh No You Enter "SSH FBC", SSH will automatically Find the full name of the host in the configuration file, log in with your username and use the "SSH-Agent" management key to perform security verification. This is convenient! Use SSH to connect to other remote computers or "ParaNOID" default settings. If some options are set in the configuration file or command line, then the default "paraNid" setting is used. In the example we mentioned above, for the SSH connection to www.foobar.com: "ForwardAgent" and "Compression" are set to "YES"; other setting options (if you do not use a command line parameter) "Forwardx11" and "FallbackTorsh" is set to "no". Others have some settings that need to be taken carefully, which is: l checkhostip yes This option is used to check the IP address to prevent DNS spoof. l CompressionLevel Compressed level From "1" (fastest) to "9" (the compression ratio). The default is "6". l Forwardx11 YES To set this option in order to run a remote X program locally. loglevel Debug When SSH has problems, this option is useful. The default is "info". 2) Configure the software of the server
The configuration of the SSH server uses the "/ etc / ssh / sshd_config" configuration file, which sets some instructions in the configuration file and use "Man SSHD". Note that OpenSSH has no different profiles for SSH 1.x and 2.x. Need to note in the default setting option: l PermitRootLogin YES is best to set this option to "PermitRootlogin without-password", so "root" users cannot log in from a computer without a key. Set this option to "no" will prohibit "root" users from logging in, and can only transfer from ordinary users to "root" with the "su" command. l X11Forwarding No Set this option to "YES" to allow the user to run the X program on the remote host. Even if this option does not increase the security of the server because users can install their own forwarders (Forwarder), please see "Man SSHD". l PasswordAuthentication Yes Set this option to "no" only allows the user to log in with a key-based manner. This will of course bring trouble to users who often log in from different hosts, but this can greatly improve the security of the system. There is a big weakness based on the password. L # subs / sftpd removes the front ## and set the path name to "/ usr / bin / sftpserv", users can use "SFTP" (secure FTP) (SFTPSERV in SFTP) Package in the package. Because many users are more familiar with FTP and "SCP" is used up, "SFTP" is still very useful. And the graphical FTP tool "GFTP" after version 2.0.7 also supports "SFTP". V. Copy file
1) Copy file with "SCP"
SSH provides some commands and shells to log in to the remote server. It is not allowed to copy files by default, but it is still a "scp" command. Assume that you want to copy a file named "DUMB" in the current directory of the local computer to your home directory on your home directory at www.foobar.com. And your account name on the remote server is "bilbo". You can use this command: scp dumb bilbo@www.foobar.com :. Copy the file back to use this command: SCP bilbo@www.foobar.com: Dumb. "SCP" calls SSH to log in, then copy the file, finally call SSH Close this connection. If you have made this configuration for www.foobar.com in your "~ / .ssh / config" file: Host * fbc hostname www.foobar.com User Bilbo Forwardagent Yes So you can use "FBC" instead "Bilbo@www.foobar.com", the command is simplified to "SCP DUMB FBC :.". "SCP" assumes that your home directory on the remote host is your work directory. If you use a relative directory, you have to share with your home. Use the "-r" parameter of the "SCP" command to allow recursive copy to the directory. "SCP" can also be copied between two different remote hosts. Sometimes you can try to make such a thing: After logging in to www.foobar.com, enter the command "SCL Machine]: Dumb." Want to use it to copy the local "DUMB" file to your current login Remote server. At this time, you will see the following error message: ssh: secure connection to [local machine] REFUSED This error message is because you run a remote "SCP" command, it tries to log in to your local computer The SSH service program running ... so it is best to run "SCP" locally unless your local computer runs the SSH service. 2) Copy file with "sftp"
If you are used to copying files using FTP, you can try "SFTP". "SFTP" establishes a secure FTP connection channel with SSH encryption, allowing the standard FTP command. There is also a good place to "sftp" allows you to run remote programs through the "Exec" command. After version 2.0.7, the graphical FTP client software "GFTP" supports "SFTP". If the remote server does not have SFTP server software "sftpserv", you can copy "SFTPSERV" to your remote home directory (or set the path set in the $ PATH environment variable of the remote computer). "SFTP" will automatically activate this service software, you don't have to have any special permissions on the remote server.
3) Copy file with "rsync"
"rsync" is a useful tool for copying, updating, and moving remote and local files, which is easy to use "-e SSH" parameters and SSH. One advantage of "RSYNC" is that all files will not be copied, and only different files in the local directory and remote directories are copied. And it also uses a very efficient compression algorithm so that the speed is very fast.
4) Use "encrypted channel" FTP copy file
If you insist on using traditional FTP client software. SSH can provide "secure channels" for almost all protocols. FTP is a little strange agreement (such as two ports) and there are some differences between client programs and client programs between different service programs and servers. The method of implementing "encrypted channel" is to use "port forwarding". You can set an unused local port (usually greater than 1000) to forward to a remote server, then just connect this port on the local computer. Is it a little complex? In fact, a basic idea is to forward a port, let SS have run in the background, with the following command: ssh [user @ remote host] -f -1 1234: [Remote Host]: 21 TAIL -F / ETC / MOTD followed FTP customers, set it to the specified port: LFTP -U [username] -p 1234 localhost, of course, use this method is very troublesome and it is easy to make mistakes. So it is best to use the first three methods. 6. Set "Encrypted Channel" with SSH
1) Basic knowledge of "encryption channel"
The "encrypted channel" of SSH is implemented by "port forwarding". You can establish a "encrypted channel" between a local port (not used) and ports of a service running on the remote server. Then connect to the local port. All requests for local ports are encrypted by SSH and forward to the port of the remote server. Of course, only "Encrypted Channel" can work when running the SSH server software on the remote server. You can use the following command to check if some remote servers run SSH service: telnet [Full Name of Remote Host] 22 If you receive this error message: telnet: unable to connect to remove host: connection refuse, indicating that there is no SSH service on the remote server software. Port Forward use such command syntax: ssh -f [username @ remote host] -l [local port]: [Full Name of Remote Host]: [Remote Port] [some command] You can not only forward multiple ports and can "~ / .ssh / config" file is used in "localforward" to set some forwarded ports.
2) Plus "Encrypted Channel" for POP
You can use the POP protocol to take Email from the server. Plus "Encrypted Channel" for POP can prevent POP from being listened by the Network Listener (Sniffer). Another advantage is that the compression method of SSH can make the email faster. Assume that you have a POP account on pop.foobar.com, your username is "Bilbo" your POP password is "TOPSecret". The command used to establish SSH "encrypted channel" is: ssh -f -c bilbo@pop.foobar.com -l 1234: pop.foobar.com: 110 SLEEP 5 (if you want to test, you can add "Sleep" To 500). After running this command, you will prompt you to enter the POP password: bilbo@pop.foobar.com's password: Enter the password to connect to the local forwarded port with "Telnet". Telnet Localhost 1234 You will receive a "Ready" message from the remote mail server. Of course, this method requires you to manually enter all POP commands, which is very inconvenient. You can use Fetchmail (refer to How To Configure Fetchmail). Secure Pop Via SSH Mini-HOWTO, Man Fetchmail and FAQ in Fetchmail under the "/ usr / doc / fetchmail- [...] directory provide some specific examples. Note that the IMAP protocol is used by different ports: the port number of IMAP V2 is 143 and the port number of IMAP V3 is 220.3) is X plus "encrypted channel".
If you intend to run the X program on the remote SSH server on your local computer, log in to the remote computer, create a file called "~ / .ssh / environment" and add this line: xauthority = / home / [ Remote User Name] /. XAUTHORITY (if there is no ".xauthority" file in your home directory on your home directory, you will be automatically created when you log in with SSH. For example, start an X program (xterm) can be this command: ssh -fx -l [remote user name] [Remote Machine] xterm This will run the XTERM program remotely. Other X procedures are also used in the same way.
4) Plus "Encrypted Channel" for LinuxConf
LinuxConf (http://www.solucorp.qc.ca/linuxConf/) is Linux configuration tool that supports remote management. The FAQ of LinuxConf remends how to use LinuxConf with SSH: remadmin-exec [link_command] Linuxconf --Guiproto If you want to transfer information in encryption between the two computers, then it is best to use SSH. The command is: remadmin --Exec ssh -l [account] Linuxconf --guiProto This is very effective and runs with a graphical interface to manage your computer. This method needs to install Linuxconf on the client. Other methods are also logged in to the server to run Linuxconf with the "X11Forwarding" or character interface.
