Shulou(Shulou.com)06/01 Report--

This article will explain in detail what is the principle and usage of SSH. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

The English full name of SSH is Secure SHell. By using SSH, you can encrypt all transmitted data, making man-in-the-middle attacks impossible and preventing DNS and IP spoofing. An additional benefit is that the transmitted data is compressed, so the speed of transmission can be accelerated. SSH has many functions. It can not only replace telnet, but also provide a secure "channel" for ftp, pop, and even ppp.

Unified network service programs, such as ftp, pop and telnet, are inherently insecure because they transmit passwords and data in clear text on the network, which can be easily intercepted by people with ulterior motives. Moreover, the security verification method of these service programs also has its weakness, that is, it is vulnerable to the attack of "man-in-the-middle". The so-called "man in the middle" attack is that the "man in the middle" pretends to be a real server to receive your data sent to the server, and then pretends to send the data to the real server. After the data transfer between the server and you is tampered with by the "middleman", there will be serious problems.

SSH was originally developed by a Finnish company. However, due to the limitations of copyright and encryption algorithms, many people now switch to OpenSSH. OpenSSH is an alternative to SSH and is free, and it can be expected that more and more people will use it instead of SSH in the future.

SSH consists of client-side and server-side software, and there are two incompatible versions: 1.x and 2.x. Clients using SSH 2.x cannot connect to SSH 1.x services. OpenSSH 2.x supports both SSH 1.x and 2.x.

How does SSH's security verification work

From the client side, SSH provides two levels of security authentication.

The first level (password-based security authentication) allows you to log in to the remote host as long as you know your account number and password. All transmitted data will be encrypted, but there is no guarantee that the server you are connecting to is the server you want to connect to. There may be other servers pretending to be real servers, that is, being attacked by "middlemen".

The second level (key-based security authentication) relies on keys, that is, you must create a pair of keys for yourself and place the public keys on the server you need to access. If you want to connect to the SSH server, the client software will send a request to the server for security authentication with your key. After the server receives the request, first look for your public key in the server's home directory, and then compare it with the public key you sent. If the two keys match, the server encrypts the "challenge" with the public key and sends it to the client software. After receiving the challenge, the client software can decrypt it with your private key and send it to the server.

In this way, you must know the password of your key. However, compared with 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 also the "man in the middle" attack is impossible (because he doesn't have your private key). But the entire login process may take 10 seconds.

Install and test OpenSSH

Due to the restrictions of American law, OpenSSH is not included in many Linux distributions. However, you can download and install OpenSSH from the network (see http://www.linuxaid.com.cn/engineer/brimmer/html/OpenSSH.htm for installation and configuration of OpenSSH).

After installing OpenSSH, 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:

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 sure you want to continue connecting (yes/no)?

OpenSSH tells you that it doesn't know about the host, but you don't have to worry about it, because this is the first time you've logged in to the host. Type "yes". This will add the "identifier" of this host to the "~ / .ssh/know_hosts" file. This prompt will not be displayed the second time you visit this host.

Then SSH prompts you to enter the password for your account on the remote host. After entering the password, a SSH connection is established, after which you can use SSH as you would with telnet.

SSH's key.

Generate your own key pair

Generating and distributing your own keys has two benefits:

1) it can prevent the attack of "man in the middle"

2) you can log in to all the servers you want to log in with just one password

The key can be generated with the following command:

Ssh-keygen

Use this command if the remote host is using SSH 2.x:

Ssh-keygen-d

There is no problem with both SSH1 and SSH2 keys on the same host, because the keys are stored in different files.

After the ssh-keygen command runs, the following information is displayed:

Generating RSA keys:.. ooooooO.ooooooO

Key generation complete.

Enter file in which to save the key (/ home/ [user] / .ssh / identity):

[just press ENTER]

Created directory'/ home/ [user] / .ssh'.

Enter passphrase (empty for no passphrase):

[the password entered will not be displayed on the screen]

Enter same passphrase again:

[re-enter the password, if you forget the password, you can only regenerate the key once]

Your identification has been saved in / home/ [user] / .ssh / identity.

[here 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" does almost the same thing, but stores a pair of keys as (by default) "/ home/ [user] / .ssh / id_dsa" (private key) and "/ home/ [user] / .ssh / id_dsa.pub" (public key).

Now you have a pair of keys: the public key should be distributed to all remote hosts you want to log in with ssh, and the private key should be kept well to prevent others from knowing your private key. Access to files displayed with "ls-l ~ / .ssh / identity" or "ls-l ~ / .ssh/id_dsa" must be "- rw-".

If you suspect that your key is already known, don't hesitate to generate a new pair of keys right away. Of course, you also have to redistribute the public key.

Distribute public keys

On every remote server you need to connect to with SSH, you need to create a subdirectory of ".ssh" in your home directory, copy your public key "identity.pub" to this directory and rename it "authorized_keys". Then execute:

Chmod 644 .ssh / authorized_keys

This step is essential. If someone other than you has write access to the "authorized_keys" file, SSH will not work.

If you want to log in to a remote host from a different computer, the "authorized_keys" file can also have multiple public keys. In this case, you must regenerate a pair of keys on the new computer, and then copy and paste the generated "identify.pub" file into the "authorized_keys" file on the remote host. Of course, you must have an account on the new computer, and the key is protected by a password. It is important that when you cancel this account, don't forget to delete this pair of keys.

Configure SSH

Configure the client's software

OpenSSH can be configured in three ways: command-line parameters, user profiles, and system-level configuration files ("/ etc/ssh/ssh_config"). Command line parameters take precedence over configuration files, and user profiles take precedence over system profiles. All command line parameters can be set in the configuration file. Because there is no default user profile at installation, copy and rename "/ etc/ssh/ssh_config" to "~ / .ssh / config".

The standard configuration file looks something like this:

[lots of explanations and possible options listed]

# Be paranoid by default

Host *

ForwardAgent no

ForwardX11 no

FallBackToRsh no

There are also many options that can be set with "man ssh" to view the "CONFIGURATION FILES" chapter.

Configuration files are read sequentially. The option set first takes effect first.

Suppose you have an account called "bilbo" on www.foobar.com. And you need to combine "ssh-agent" with "ssh-add" and use data compression to speed up transmission. Because the host name is too long, you don't bother to type such a long name and use "fbc" as the abbreviation of "www.foobar.com". Your profile can look 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

After you type "ssh fbc", SSH will automatically find the full name of the host from the configuration file, log in with your user name and perform security authentication with the key managed by "ssh-agent". This is very convenient!

The default setting of "paranoid" is used to connect to other remote computers with SSH. If some options are not set in the configuration file or command line, the default "paranoid" setting is still used.

In the example we cited above, for SSH connections to www.foobar.com: "ForwardAgent" and "Compression" are set to "Yes"; other setting options (if no command line arguments are used) "ForwardX11" and "FallBackToRsh" are set to "No".

Other setting options to take a closer look at are:

L CheckHostIP yes

This option is used to check IP addresses to prevent DNS spoofing.

L CompressionLevel

The level of compression ranges from "1" (fastest) to "9" (highest compression ratio). The default value is "6".

L ForwardX11 yes

This option must be set in order to run remote X programs locally.

L LogLevel DEBUG

This option is useful when there is a problem with SSH. The default is "INFO".

Configure the server-side software

The configuration of the SSH server uses the "/ etc/ssh/sshd_config" configuration file, and the settings for these options are already described in the configuration file and you can also view help with "man sshd". Note that OpenSSH does not have different configuration files for SSH 1.x and 2.x.

Among the default settings options are:

L PermitRootLogin yes

It is best to set this option to "PermitRootLogin without-password" so that "root" users cannot log in from computers that do not have a key. Setting this option to "no" will prevent "root" users from logging in and can only use the "su" command to change from a normal user to "root".

L X11Forwarding no

Set this option to "yes" to allow users to run X programs on remote hosts. Even disabling this option will not improve server security because users can install their own transponders (forwarder), see "man sshd".

L PasswordAuthentication yes

Setting this option to "no" only allows users to log in in a key-based manner. This will certainly cause trouble for users who often need to log in from different hosts, but it can greatly improve the security of the system. Password-based login has a big weakness.

L # Subsystem / usr/local/sbin/sftpd

By removing the first # and setting the pathname to "/ usr/bin/sftpserv", users can use "sftp" (secure FTP) (sftpserv is in the sftp package). Because many users are familiar with FTP and there is some trouble with "scp", "sftp" is still very useful. And the graphical ftp tool "gftp" after version 2.0.7 also supports "sftp".

Copy a file

Copy files with "scp"

SSH provides some commands and shell to log in to the remote server. By default, it does not allow you to copy files, but it still provides a "scp" command.

Suppose you want to copy a file named "dumb" from the current directory of your local computer to your home directory on the remote server www.foobar.com. And your account on the remote server is called "bilbo". You can use this command:

Scp dumb bilbo@www.foobar.com:.

Copy the file back with this command:

Scp bilbo@www.foobar.com:dumb.

"scp" calls SSH to log in, then copies the file, and finally calls SSH to close the connection.

If you have already configured www.foobar.com like this in your "~ / .ssh / config" file:

Host * fbc

HostName www.foobar.com

User bilbo

ForwardAgent yes

Then you can replace "bilbo@www.foobar.com" with "fbc" and simplify the command to "scp dumb fbc:.".

"scp" assumes that your home directory on the remote host is your working directory. If you use a relative directory, it is relative to the home directory.

Using the "- r" parameter of the "scp" command allows you to copy directories recursively. "scp" can also copy files between two different remote hosts.

Sometimes you may try to do something like this: after logging in to www.foobar.com with SSH, type the command "scp [local machine]: dumb." Want to use it to copy the local "dumb" file to the remote server where you are currently logged in. At this point, you will see the following error message:

Ssh: secure connection to [local machine] refused

This error message occurs because you are running a remote "scp" command that attempts to log in to a SSH service program running on your local computer. So it's best to run "scp" locally unless your local computer is also running SSH services.

Copy files with "sftp"

If you are used to copying files using ftp, you can try "sftp". "sftp" establishes a secure FTP connection channel encrypted with SSH, allowing the use of standard ftp commands. Another benefit is that "sftp" allows you to run remote programs through the "exec" command. The graphical ftp client software "gftp" has supported "sftp" since version 2.0.7.

If the sftp server software "sftpserv" is not installed on the remote server, you can copy the executable file of "sftpserv" to your remote home directory (or the path set in the $PATH environment variable of the remote computer). "sftp" will automatically activate the service software, you do not need to have any special permissions on the remote server.

Copy files with "rsync"

"rsync" is a useful tool for copying, updating, and moving remote and local files, and it is easy to use the "- e ssh" parameter with SSH. One advantage of "rsync" is that it does not copy all files, only files that are different from those in the local and remote directories. And it also uses a very efficient compression algorithm, so that the copy speed is very fast.

Copy files with the ftp of "encrypted channel"

If you insist on using traditional FTP client software. SSH can provide "secure channel" for almost all protocols. FTP is a slightly strange protocol (for example, it requires two ports) and there are some differences between different services and services, and between clients and clients.

The way to implement "encrypted channel" is to use "port forwarding". You can set an unused local port (usually greater than 1000) to forward to a remote server, and then just connect to this port on the local computer. It's a little complicated, isn't it?

In fact, a basic idea is to forward a port and let SSH run in the background, using the following command:

Ssh [user@remote host]-f-L 1234: [remote host]: 21 tail-f / etc/motd

Then run the FTP client and set it to the specified port:

Lftp-u [username]-p 1234 localhost

Of course, it is troublesome and error-prone to use this method. So it's best to use the first three methods.

Use SSH to set "encrypted Channel"

Basic knowledge of "encrypted Channel"

The "encrypted channel" of SSH is implemented through "port forwarding". You can establish an "encrypted channel" between the local port (not used) and the port of a service running on the remote server. Then just connect to the local port. All requests for the local port are encrypted by SSH and forwarded to the port of the remote server. Of course, the "encrypted channel" works only when the SSH server software is running on the remote server. You can check whether some remote servers are running the SSH service with the following command:

Telnet [full name of remote host] 22

If you receive an error message like this:

Telnet: Unable to connect to remote host: Connection refused

This means that the SSH service software is not running on the remote server.

Port forwarding uses this 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 but also use "LocalForward" to set some of the frequently used forwarding ports in the "~ / .ssh / config" file.

Add "encrypted channel" to POP

You can fetch email from the server using the POP protocol. Adding an "encrypted channel" to the POP prevents the POP's password from being heard by the network listener (sniffer). Another benefit is that SSH's compression allows messages to be transmitted faster.

Suppose you have a POP account on pop.foobar.com, your user name is "bilbo" and your POP password is "topsecret". The command used to establish an 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 increase the value of "sleep" to 500.) After running this command, you will be prompted for the POP password:

Bilbo@pop.foobar.com's password:

After entering the password, you can use "telnet" to connect to the local forwarding port.

Telnet localhost 1234

You will receive a "READY" message from the remote mail server.

Of course, this method requires you to enter all POP commands manually, which is very inconvenient. You can use Fetchmail (see how to configure Fetchmail). Secure POP via SSH mini-HOWTO, man fetchmail and in "/ usr/doc/fetchmail- […]" The FAQ of Fetchmail in the directory provides some concrete examples.

Note that the IMAP protocol uses a different port: the port number of IMAP v2 is 143 and the port number of IMAP v3 is 220.

Add "encrypted channel" to X

If you plan 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 the file ".Xauthority" does not exist in your home directory on the remote host, it will be created automatically when you log in with SSH.)

For example, you can start an X program (xterm) with this command:

Ssh-f-X-l [remote user name] [remote machine] xterm

This will run the xterm program remotely. Other X programs use the same method.

Add "encrypted channel" to linuxconf

Linuxconf (http://www.solucorp.qc.ca/linuxconf/) is a configuration tool for Linux that supports remote administration. Linuxconf's FAQ re-illustrates how to use linuxconf with SSH:

The command is:

Remadmin-exec [link_command] linuxconf-guiproto

If you want to send information between two computers in an encrypted way, you'd better use ssh. The command is:

Remadmin-- exec ssh-l [account] linuxconf-- guiproto

This is very effective and runs with a graphical interface to manage the computer.

This approach requires linuxconf to be installed on the client side. Other ways are to log in directly to the server and run linuxconf using the "X11Forwarding" or character interface.

Add "encrypted channel" to Webmin

Webmin is a new browser-based configuration tool. It runs on port 1000. You can encrypt it with SSH's Port forwarding:

Ssh-f-l [remote user name] [remote host]-L 1234: [remote host]: 10000 tail-f / etc/motd

About the principle and usage of SSH what is shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.