Passwordless SSH between Oracle Cloud Infrastructure (OCI) VM hosts is achieved by generating an Ed25519 key pair on the source instance, copying the public key to the destination’s authorized_keys file, and verifying connectivity. This method eliminates manual authentication for scripts, automation tools, and secure administrative access across your cloud environment.
Generate the SSH Key Pair
The foundation of passwordless authentication lies in asymmetric cryptography. You must generate a private key on the machine that will initiate connections (the client) and place the corresponding public key on the target machine (the server). While RSA keys are common, Ed25519 offers superior security and performance for modern Linux distributions, including Ubuntu, which is frequently used in OCI deployments. Log into your source OCI VM via SSH using your standard password or existing key. Open a terminal and execute the following command to generate a new key pair:ssh-keygen -t ed25519 -C "oci-admin-key"
When prompted for the file location, press Enter to accept the default path (~/.ssh/id_ed25519). For enhanced security, you can enter a passphrase. However, if this key is intended for automated scripts or CI/CD pipelines running without user interaction, leave the passphrase empty. An empty passphrase allows the key to be used immediately without further input, which is the core requirement for "passwordless" access.
Verify that the key was created successfully by listing the contents of the .ssh directory:
ls -l ~/.ssh/id_ed25519*
You should see two files: id_ed25519 (private key) and id_ed25519.pub (public key). Never share the private key with anyone or upload it to any external service. The public key is safe to distribute to all target hosts.
Copy the Public Key to the Destination Host
The most efficient way to install the public key on the remote OCI VM is using thessh-copy-id utility. This tool automatically appends your public key to the ~/.ssh/authorized_keys file on the target server, creating necessary directories and setting correct permissions if they do not already exist.
Run the following command, replacing username and target_ip with the actual credentials of your destination OCI instance:
ssh-copy-id username@target_ip
You will be prompted to enter the password for the username account on the target host. Once authenticated, ssh-copy-id will transfer the public key. If the utility is not available on your source system (some minimal containers lack it), you can manually copy the key using cat and ssh:
cat ~/.ssh/id_ed25519.pub | ssh username@target_ip "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
After executing this step, ensure that the permissions on the destination host are secure. The .ssh directory should be 700, and the authorized_keys file should be 600. You can verify this on the target host by running:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
Incorrect permissions are a common reason why passwordless SSH fails silently. OpenSSH refuses to use the key if the files are writable by other users, treating them as insecure.
Test and Verify Connectivity
With the key installed, test the connection by attempting to SSH into the target host without providing a password:ssh username@target_ip
If configured correctly, you will be logged in immediately. To confirm that no password prompt is appearing, you can check the exit status or simply observe the shell prompt. Once verified, type exit to disconnect from the target host.
For advanced configurations, you may wish to edit the SSH configuration file on the source host (~/.ssh/config) to define aliases. This simplifies future connections:
Host oci-target
HostName target_ip
User username
IdentityFile ~/.ssh/id_ed25519
After adding this block, you can connect using just ssh oci-target. This approach scales well when managing multiple OCI instances. It reduces the cognitive load of remembering IP addresses and ensures consistent authentication behavior across your infrastructure.
Troubleshooting Common Issues
If passwordless login fails, several factors could be at play. First, check the SSH daemon logs on the target OCI VM. Runsudo tail -f /var/log/auth.log while attempting to connect from the source. Look for errors related to "Permission denied" or "Authentication refused."
Second, verify that the SSH service is running and listening on the target. Ensure that the security list associated with the target subnet in OCI allows inbound traffic on port 22. Even if the OS firewall is open, OCI network security lists must permit the connection.
Third, confirm that the user account on the target host has a valid shell defined in /etc/passwd. Some restricted accounts may prevent interactive sessions even with valid keys. Additionally, ensure that PubkeyAuthentication yes is set in the /etc/ssh/sshd_config file on the target. Restart the SSH service after any configuration changes using sudo systemctl restart sshd.
For Windows users managing these Linux hosts, tools like PuTTY require converting the OpenSSH key format. See our guide on Converting Putty registry entry for PPK to connect to MySQL server using MySQL Workbench on Windows for context on key management, though note that specific steps for SSH-only keys involve using PuTTYgen to import the OpenSSH key and save it as a .ppk file.
Understanding how to manage these keys securely is vital. If you need to access these hosts from a Windows workstation directly, refer to How to Access IP/Hostname on Windows using SSH Server to understand the broader ecosystem of SSH clients and servers.
Frequently Asked Questions
Can I use the same key for multiple destination hosts?
Yes, you can copy the same public key to the authorized_keys file of multiple OCI VMs. This allows a single source host to connect to many targets without password prompts. However, if one key is compromised, you must revoke it from all affected hosts immediately.
What happens if I forget the passphrase on my private key?
If you set a passphrase during generation and forget it, there is no recovery mechanism. You must generate a new key pair and update the authorized_keys files on all target hosts with the new public key. Always store passphrases securely in a password manager.
Why does SSH still ask for a password despite having the key?
This usually occurs due to incorrect file permissions on the target host. Ensure ~/.ssh is 700 and ~/.ssh/authorized_keys is 600. Also, verify that the user has a valid shell and that PubkeyAuthentication is enabled in sshd_config.
Is Ed25519 supported on older versions of Ubuntu?
Ed25519 support was added in OpenSSH 6.5. Most modern Ubuntu releases included in OCI images fully support this algorithm. If you encounter compatibility issues with very old systems, fall back to RSA keys using ssh-keygen -t rsa -b 4096.
How do I disable password authentication entirely for security?
To enforce key-only login, edit /etc/ssh/sshd_config on the target host and set PasswordAuthentication no. Restart the SSH service afterward. This prevents brute-force attacks against user passwords, relying solely on cryptographic keys for access.