Note: This article is an original work by Liu Feng from Anyatech. Please respect intellectual property rights. When sharing, please indicate the source. No plagiarism, adaptation, or unauthorized reproduction is accepted.
Introduction
In daily Linux system management and Oracle RAC cluster deployment, SSH serves as both a “secure remote gateway” and an efficient “bridge” for collaboration between nodes.
Especially in an Oracle RAC environment, the mutual trust configuration for Oracle users is the cornerstone for ensuring smooth communication, resource scheduling, and high availability of the cluster.
Many DBAs and operations colleagues often get stuck at the passwordless configuration and permission verification stages when setting up RAC.
Today, we will start from the principles of SSH and guide you through the complete process of Oracle RAC mutual trust configuration using the path of principles + configuration + experimental verification.
01
SSH Technical Principles and Linux Remote Access Configuration
1
Core Principles of SSH Technology
SSH (Secure Shell) is an application-layer security network protocol designed to replace traditional plaintext transmission protocols such as Telnet and rsh. It achieves secure access and operation of remote hosts through data encryption, identity authentication, and data integrity verification.
Its core advantages include:
-
Encrypted Transmission
All data (including usernames, passwords, command line instructions) is transmitted using a combination of asymmetric encryption (RSA/ECC) and symmetric encryption (AES/ChaCha20), preventing man-in-the-middle eavesdropping;
-
Identity Authentication
Supports both “password authentication” and “key pair authentication” methods, with key pair authentication being more secure and preferred in cluster environments;
-
Port Forwarding
Allows for internal network service penetration through “local port forwarding”, “remote port forwarding”, and “dynamic port forwarding” (e.g., remote database access).
The SSH protocol is divided into SSH1 (deprecated due to security vulnerabilities) and SSH2 (the current mainstream version). The OpenSSH (open-source implementation) installed by default on Linux systems only supports SSH2 and mainly includes components such as ssh (client), sshd (server), ssh-keygen (key generation tool), and ssh-copy-id (key distribution tool).
2
Basic SSH Configuration on Linux (Using Kylin Server V10 as an Example)
1. Install and Start SSH Service
Most Linux distributions, such as Kylin Server V10, come pre-installed with OpenSSH. If not installed, deploy it using the following commands:
# Install OpenSSH server and client
yum install -y openssh-server openssh-clients
# Start sshd service and set it to start on boot
systemctl start sshd
systemctl enable sshd
# Verify service status ("active (running)" indicates normal operation)
systemctl status sshd2. Basic SSH Remote Access (Password Authentication)
Use the ssh command to remotely log in to the target Linux host from the local host, formatted as follows:
Basic syntax: ssh [username]@[target host IP/hostname] -p [port number]
# Example: Log in as root user to the host with IP 192.168.2.46 (default port 22)
ssh [email protected]
# The first login will verify the host fingerprint (to prevent man-in-the-middle attacks). Enter "yes" to confirm, then input the password to log in.
The authenticity of host '192.168.2.46 (192.168.2.46)' can't be established.
ECDSA key fingerprint is SHA256:Ya72mAO+HFGF54qme1uDj0sI8EEt2aUshf+lkUkeJbo.
Are you sure you want to continue connecting (yes/no/[fingerprint])?3. SSH Server Configuration Optimization (sshd_config)
The core configuration file for the SSH service is /etc/ssh/sshd_config. Modifying this file can enhance security. Common optimization items include:
# 1. Disable direct login for root user (ensure there is a regular user available to use sudo for privilege escalation)
PermitRootLogin no
# 2. Change the default port (to avoid port scanning attacks, it is recommended to use a non-standard port between 1024-65535)
Port 2222 # Note: Restart the sshd service for changes to take effect
# 3. Disable password authentication (only allow key authentication, which will be used in subsequent RAC mutual trust)
PasswordAuthentication no
ChallengeResponseAuthentication no
# 4. Restrict allowed login users (e.g., only allow oracle and admin users)
AllowUsers oracle admin
# 5. Disable SSH1 protocol (only keep SSH2)
Protocol 2After modification, restart the sshd service to apply the configuration:
systemctl restart sshd02
Oracle RAC Cluster Oracle Mutual Trust Configuration Experiment
1
Experiment Background and Environment Description
The Oracle RAC cluster consists of multiple nodes (Node), which need to achieve passwordless communication through Oracle users to support operations such as installing cluster software (Grid Infrastructure), starting/stopping database instances, and synchronizing data files.
This experiment is based on the following environment:
-
Operating System: Kylin Server V10 (64-bit)
-
RAC Nodes: 2 nodes (Node 1: rac01, IP: 192.168.1.100; Node 2: rac02, IP: 192.168.1.101)
-
Oracle User: An oracle user has been created (UID/GID must be consistent across both nodes, recommended to be 1000)
-
Prerequisites:
1) Both nodes have hostname resolution configured (add each other’s IP and hostname in the /etc/hosts file);
2) Firewalls on both nodes are disabled (systemctl stop firewalld && systemctl disable firewalld);
3) SELinux is disabled on both nodes (setenforce 0 and modify /etc/selinux/config to SELINUX=disabled).
2
Experiment Objective
Achieve two-way passwordless communication between the two Oracle RAC nodes:
-
Passwordless login from the oracle user on rac01 to the oracle user on rac02;
-
Passwordless login from the oracle user on rac02 to the oracle user on rac01.
3
Detailed Experiment Steps
Step 1: Configure Hostname Resolution (Execute on Both Nodes)
Edit the /etc/hosts file to add the IP and hostname of both nodes (ensure the hostname matches the output of the hostname command):
# Execute as root user
vi /etc/hosts
# Add the following content (IP and hostname must be replaced with actual environment)
192.168.1.100 rac01
192.168.1.101 rac02Verify if the resolution is working properly:
ping rac01 -c 2 # Node 2 executes, should be able to ping Node 1
ping rac02 -c 2 # Node 1 executes, should be able to ping Node 2Step 2: Generate Oracle User Key Pair on Node 1 (rac01)
Switch to the oracle user and generate an RSA key pair (do not set a key password):
# Switch to oracle user
su - oracle
# Generate key pair (default stored in ~/.ssh/ directory)
ssh-keygen -t rsa
# Press Enter three times (output as follows indicates success):
Generating public/private rsa key pair.
Enter file in which to save the key (/home/oracle/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/oracle/.ssh/id_rsa.
Your public key has been saved in /home/oracle/.ssh/id_rsa.pub.Step 3: Copy Node 1’s Public Key to Node 2 (rac02)
Use the ssh-copy-id tool to upload Node 1’s public key to Node 2 and automatically append it to the ~/.ssh/authorized_keys file:
# Execute under the oracle user on Node 1
ssh-copy-id -i ~/.ssh/id_rsa.pub oracle@rac02
# The first execution requires verifying the host fingerprint, enter "yes", then input the oracle user password for Node 2 (only required for the first time)
The authenticity of host 'rac02 (192.168.1.101)' can't be established.
ECDSA key fingerprint is SHA256:xxxxxxx.
Are you sure you want to continue connecting (yes/no)? yes
oracle@rac02's password: # Enter the oracle password for Node 2
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'oracle@rac02'"
and check to make sure that only the key(s) you wanted were added.Step 4: Generate Oracle User Key Pair on Node 2 (rac02)
Switch to the oracle user on Node 2 and generate an RSA key pair (do not set a password):
# Log in to Node 2, switch to oracle user
ssh root@rac02 # If already on Node 2, directly execute su - oracle
su - oracle
# Generate key pair
ssh-keygen -t rsa
# Press Enter three times, after completion, id_rsa (private key) and id_rsa.pub (public key) will be generated in ~/.ssh/ directoryStep 5: Copy Node 2’s Public Key to Node 1 (rac01)
Similarly, use the ssh-copy-id tool to upload Node 2’s public key to Node 1:
# Execute under the oracle user on Node 2
ssh-copy-id -i ~/.ssh/id_rsa.pub oracle@rac01
# The first execution requires entering "yes", then input the oracle user password for Node 1
The authenticity of host 'rac01 (192.168.1.100)' can't be established.
ECDSA key fingerprint is SHA256:xxxxxxx.
Are you sure you want to continue connecting (yes/no)? yes
oracle@rac01's password: # Enter the oracle password for Node 1
Number of key(s) added: 1Step 6: Fix Key File Permissions on Both Nodes (Critical!)
SSH has strict permission requirements for the .ssh directory and the authorized_keys file. If permissions are too broad (e.g., readable/writable by other users), passwordless login will fail.
Execute the following commands under the oracle user on both nodes:
# Execute on both Node 1 and Node 2 (oracle user)
chmod 700 ~/.ssh # .ssh directory permissions: only owner can read/write/execute
chmod 600 ~/.ssh/id_rsa # private key permissions: only owner can read/write
chmod 600 ~/.ssh/authorized_keys # public key list permissions: only owner can read/writeStep 7: Verify if Oracle Mutual Trust is Effective
Perform passwordless login tests on both nodes. If you can log in without entering a password, the mutual trust configuration is successful:
1) Node 1 verifies login to Node 2:
# Execute under the oracle user on Node 1
ssh oracle@rac02
# After successful login, the command line prompt of Node 2 will be displayed (e.g., [oracle@rac02 ~]$)
# Exit Node 2 and return to Node 1
exit2) Node 2 verifies login to Node 1:
# Execute under the oracle user on Node 2
ssh oracle@rac01
# After successful login, the command line prompt of Node 1 will be displayed (e.g., [oracle@rac01 ~]$)
# Exit Node 1 and return to Node 2
exit3) Additional Verification: Execute Remote Commands Without Password
In addition to logging in, you can also directly execute commands on the remote node from the local machine to verify if mutual trust is fully effective:
# Node 1 executes: view the home directory of the oracle user on Node 2
ssh oracle@rac02 "ls -l ~"
# Node 2 executes: view the Oracle environment variable on Node 1
ssh oracle@rac01 "echo $ORACLE_HOME"If the commands can output results normally without password prompts, the mutual trust configuration is completely successful.
Conclusion
SSH is not just a tool for remote login; it is also the secure foundation for communication in Oracle RAC clusters.
Through this article, you should have mastered:
-
How to correctly configure SSH and enhance security;
-
How to establish mutual trust between Oracle users across RAC cluster nodes;
-
And how to avoid common pitfalls of mutual trust failure in production environments.
In large-scale database clusters and high-availability architectures, details often determine success or failure.
Properly configuring SSH lays the most solid foundation for Oracle RAC.
Next, we will continue to share practical experiences on Grid Infrastructure and Oracle database installation based on this mutual trust experiment.
Stay tuned!
Author Introduction
Hello everyone, I am Liu Feng, founder of Anyatech & Senior Database Technology Instructor, focusing on PostgreSQL, domestic database operation and migration, database performance optimization, and other areas.
As an officially authorized instructor of the PG China branch and a PostgreSQL ACE certified expert, I am actively involved in frontline project practices, with over 10 years of experience in large database management and optimization, having deeply participated in database performance tuning and migration projects across various industries such as telecommunications, finance, and government.
Feel free to follow me as we explore the infinite possibilities of databases together, and technical exchanges are limitless!
📌 If you find this helpful, remember to like, bookmark, and share your support, and don’t forget to follow me for more database insights~
END
Keyword Response (See corresponding articles):
oracle, mysql, pg, postgresql, sql, performance optimization, fault handling, data migration, backup recovery, version upgrade, patch management, deep inspection, solutions, architecture design……
Assistant
If you have any questions or doubts, feel free to add me on WeChat to discuss~
\ | /
★
Move your fingers
Give [Anyatech Data Workshop] a star~
So you won’t lose track of me~
Remember to star it!
