CentOS 6.5 SSH Access configuration between Linux systems __linux

Source: Internet
Author: User
Tags ssh access dns spoofing


SSH is an abbreviation for secure Shell, developed by the IETF Network Working Group (networkworking Group), and SSH is a security protocol based on the application layer and the transport layer.

Traditional network service programs, such as FTP, pop, and telnet, are inherently unsafe because they transmit data, user accounts, and user passwords in clear text on the network, and are vulnerable to man-in-the-middle (man-in-the-middle) attacks. Is that there is another person or a machine posing as a real server to receive data from a user to the server, and then passing the data to the real server as a user.

SSH is now a more reliable protocol for providing security for Telnet sessions and other network services. The SSH protocol can effectively prevent the information leakage problem in the process of remote management. Through SSH, all transmitted data can be encrypted, as well as to prevent DNS spoofing and IP spoofing.

first step, install SSH

System and Version: CentOS release 5.3 (Final)

Install SSH:

Yum Install SSH

To start SSH:

Service sshd Start

To set the startup operation:

Chkconfig sshd on

Step Two, configure SSH

After SSH installation, the software is located in the/etc/ssh/directory, the configuration file is:/etc/ssh/sshd_config

Common modifications to the SSH configuration file are:

#Protocol 2,1← Find this line to remove the wardrobe "#" and then delete the end of ", 1", only allow the SSH2 way of the connection
Protocol 2← changed to this state, using only SSH2
#ServerKeyBits 768← Find this line, remove the "#" from the beginning and change 768 to 1024.
Serverkeybits 1024← changed to this state, the Serverkey strength changed to 1024 bits
#PermitRootLogin yes← Find this line, remove the "#" from the beginning and change Yes to No
Permitrootlogin no← changed to this state, not allowed to log on with root
#PasswordAuthentication yes← Find this line, change Yes to No
Passwordauthentication no← changed to this state, do not allow password way login #permitemptypasswordsno← find this line will be the wardrobe "#" Delete, do not allow a blank password login
Permitemptypasswords no← changed to this state, no null password to log on

The following settings can be modified for an SSH configuration that wants to connect to a Linux operating system with a public key:

# Vi/etc/ssh/sshd_config//Open the following content

Hostkey/etc/ssh/ssh_host_rsa_key

Rsaauthentication Yes

Pubkeyauthentication Yes

Authorizedkeysfile. Ssh/authorized_keys

Gssapiauthentication Yes

After the configuration file is modified, restart the SSHD service to make the modification effective:

#/etc/init.d/sshd Restart

With the above modifications, all servers can be connected to the Linux system by default;

If you need to qualify a host that connects to the server, you can qualify it by following these steps;

In the configuration modification/etc/hosts.deny,/etc/hosts.allow file, make the following modifications:

# Vi/etc/hosts.deny ← Modify the Mask rule, add the corresponding line at the end of the text

#
# Hosts.deny This file describes the names of the hosts which are
# *not* allowed to with the local INET services, as decided
# by the '/USR/SBIN/TCPD ' server.
#
# The Portmap line is redundant, but it are left to remind
# The new secure Portmap uses Hosts.deny and Hosts.allow. In particular
# You should know that NFS uses portmap!

sshd:all ← Add this line, shielding from all SSH connection requests

# Vi/etc/hosts.allow ← Modify the Allow rule to add the corresponding line at the end of the text

#
# Hosts.allow This file describes the names of the hosts which are
# allowed to with the local INET services, as decided
# by the '/USR/SBIN/TCPD ' server.
#

sshd:192.168.0. ← Add this line, only allow SSH connection requests from intranet

After the configuration file is modified, restart the SSHD service to make the modification effective:

#/etc/init.d/sshd Restart

step three, create the SSH user and public key file

For example, there are two CentOS 6.5 systems, A and B machines, and now a requires SSH access to B, you need to make the above configuration changes on B, and then follow these steps:

On the A machine:

#Useradd test01

# su–test01

$ ssh-keygen-t RSA ← Establish public and private key

Generating public/private RSA key pair.

Enter file in which to save the key (/HOME/KAZ/.SSH/ID_RSA): ← Key file name, here keep the default direct return

Created directory '/home/kaz/.ssh '

Enter passphrase (empty for nopassphrase): ← Enter password

Enter same passphrase again:← enter password again

Your identification has been saved In/home/kaz/.ssh/id_rsa.

Your public key has been saved in/home/kaz/.ssh/id_rsa.pub.

The key fingerprint is:

Tf:rs:e3:7s:28:59:5s:93:fe:33:84:01:cj:65:3b:8ecentospub@sample.centospub.com

Note: In the above operation, a test01 user is created on a, in which the process of generating the key can be fully carriage through, similar to the process of creating public key private key using tools such as SECURECRT on Windows.

Then confirm the establishment of the public key and key, and some processing corresponding to the client.

$ls-l← List Files

Total 16

-RW ——-1 centospub centospub 951 SEP 4 19:22 id_rsa← confirm private key has been established

-rw-r–r–1 centospub centospub 241 SEP 4 19:22id_rsa.pub← confirm public key has been established

$ cat~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys← Public key content output to appropriate file

$ chmod400 ~/.ssh/authorized_keys← Set the newly established public key file property to 400

After the key file is generated on host A, the next step is to add on B

#Useradd test01

# passwd test01--The user password on the Host B machine must be set up, and the SSH connection requires input

# su–test01

$ scp A:/home/test01/.ssh/authorized_keys ~/.ssh/authorized_keys

$ chmod400 ~/.ssh/authorized_keys

Copy the public key on a to the Authorized_keys file in the. SSH directory under the test01 user of B, as the server-side validation file;

If the remote copy does not work, you can create the ~/.ssh/authorized_keys file directly on the B-Machine , and then write the public key information.

step fourth, SSH login test:

After the steps above are complete, you can perform the following tests:

On the A machine:

# Sshtest01@b

Then enter the test01 user's password on the B machine to connect to the B machine normally.

Note At this point if you want to modify the permissions of the logged-in user, on the B machine on the test01 of the relevant permissions to modify it.



Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.