SSH Equivalency Setup in Oracle Exadata – Step-by-Step Guide

Introduction

SSH equivalency is a mandatory requirement in Oracle Exadata environments. It enables passwordless SSH communication between database servers, storage servers (cells), and other Exadata components.

SSH equivalency is used during:

• Exadata deployment

• OneCommand setup

• Patching activities

• Exachk execution

• Automation scripts

• Cluster operations

This guide demonstrates how to configure SSH equivalency securely in an Oracle Exadata environment.

---

Environment Details

Example Exadata Environment:

Hostname	Type
db01	Database Server
db02	Database Server
cell01	Storage Server
cell02	Storage Server
cell03	Storage Server

User:

oracle

---

Step 1: Verify Connectivity

From db01, verify connectivity to all nodes.

ping db02
ping cell01
ping cell02
ping cell03

Expected Result:

64 bytes from db02
64 bytes from cell01

---

Step 2: Generate SSH Key

Login as oracle user.

su - oracle

Generate SSH key.

ssh-keygen -t rsa

Press Enter for all prompts.

Verify key files:

ls -ltr ~/.ssh

Expected:

id_rsa
id_rsa.pub

---

Step 3: Copy Public Key to Remote Servers

Copy public key to all target nodes.

ssh-copy-id oracle@db02

ssh-copy-id oracle@cell01

ssh-copy-id oracle@cell02

ssh-copy-id oracle@cell03

Enter password when prompted.

---

Step 4: Verify Passwordless Login

Test SSH connectivity.

ssh db02 hostname

ssh cell01 hostname

ssh cell02 hostname

ssh cell03 hostname

Expected Output:

db02
cell01
cell02
cell03

No password should be requested.

---

Step 5: Configure Reverse Connectivity

Perform the same steps from db02 to db01.

Generate keys:

ssh-keygen -t rsa

Copy keys:

ssh-copy-id oracle@db01

Validate:

ssh db01 hostname

---

Step 6: Validate SSH Equivalency

Execute the following command from each database node.

ssh db01 date

ssh db02 date

ssh cell01 date

ssh cell02 date

ssh cell03 date

All commands should execute without password prompts.

---

Step 7: Verify Authorized Keys

Check authorized_keys file.

cat ~/.ssh/authorized_keys

Ensure public keys from all participating nodes are present.

Permissions:

chmod 700 ~/.ssh

chmod 600 ~/.ssh/authorized_keys

chmod 600 ~/.ssh/id_rsa

---

Common Issues and Troubleshooting

Permission Denied

Error:

Permission denied (publickey)

Solution:

chmod 700 ~/.ssh

chmod 600 ~/.ssh/authorized_keys

---

Host Key Verification Failed

Error:

Host key verification failed

Solution:

ssh-keygen -R hostname

Reconnect:

ssh hostname

---

SSH Timeout

Verify:

ping hostname

nslookup hostname

Check firewall configuration.

---

Validation Checklist

Check	Status
SSH keys generated	✓
Public keys copied	✓
Passwordless login working	✓
Authorized keys validated	✓
Permissions verified	✓

---

Conclusion

SSH equivalency is a critical prerequisite for Oracle Exadata administration, patching, and automation activities. Properly configured passwordless SSH improves operational efficiency and reduces manual intervention during maintenance and deployment tasks.

Always validate connectivity and file permissions after configuration to avoid failures during patching and cluster operations.

##Viewing Alert Logs in Oracle Cloud Infrastructure (OCI) for Oracle Autonomous Databases

### Limited OS Access

For Oracle Autonomous Databases, direct access to the underlying operating system is restricted. Therefore, alert log monitoring must be done through SQL views and the OCI Console.

### SQL-Based Alert Log Access

#### Deprecated View

- **`V$DIAG_ALERT_EXT`**: Previously used to query alert logs directly via SQL.

- **Status**: **Removed** in recent Oracle ADB updates.

#### Replacement View

- **`V$CLIENT_ERRORS`**: Introduced as the new method to access alert log-related error data.

- **Purpose**: Displays XML-based error logs, including client connection issues and user errors like `ORA-4021`.

### Current Limitations of `V$CLIENT_ERRORS`

- **Session Dependency**: The view only shows error data **while the session is active**.

- **Post-Session Visibility**: If a session is terminated (e.g., killed due to resource limits), its error data **is no longer visible** in the view.

- **User Experience**: This behavior is understandably frustrating, as it limits post-mortem diagnostics.

### Enhancement in Progress

Oracle is actively working on enhancing `V$CLIENT_ERRORS` to improve its usability and persistence of error data beyond session lifetime. No official release date has been announced yet, but updates are expected soon.

we will keep posted about any recent update