RMAN Duplicate Fails ORA-38862: Flashback Database Logs Are In Use

 RMAN backup restore is failing with the following error when the flashback is turned on in the source database.

Error:
Errors in memory script
RMAN-03015: error occurred in stored script Memory Script
RMAN-06136: ORACLE error from auxiliary database: ORA-01507: database not mounted
ORA-06512: at "SYS.X$DBMS_RCVMAN", line 14894
ORA-06512: at line 1
RMAN-03015: error occurred in stored script Memory Script
RMAN-03009: failure of sql command on clone_default channel at 04/04/2021 23:37:08
RMAN-20000: abnormal termination of job step
RMAN-11003: failure during parse/execution of SQL statement: alter database flashback off
RMAN-11001: Oracle Error:
ORA-38862: Flashback database logs are in use.
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 04/04/2021 23:37:21
RMAN-05501: aborting duplication of target database
Recovery Manager complete.

Fix:

Update the below values on the target database and retry the clone.

SQL> alter system set db_flashback_retention_target=0 scope=both;
SQL> alter system set db_recovery_file_dest='' scope=both;

Reference  -  (Doc ID 2418803.1)

Disconnected: No supported authentication methods available (server sent: publickey, gssapi-with-mic)

When we trying to connect to an Oracle Cloud Linux/UNIX-Like Instance through Open SSH, the SSH client returns one of the following errors:

Issue:

"Disconnected: No supported authentication methods available (server sent: publickey)"
"Disconnected: No supported authentication methods available (server sent: publickey, gssapi-with-mic)"

Fix:

There are multiple issues that could cause such an error, please read below what the troubleshoot steps are for the most common causes.

1. Check that the IP address against which you try to connect is the address of the correct instance. This can be performed either through the Compute Console or the REST API:
Listing Instances in the Compute Console
Retrieving Details of an Instance using the REST API
Note that, unless reserved, the IP addresses of instances could change after reboots: Reserving a Public IP Address

2. Check that a SSH private key is configured in the SSH client you use or it is specified to the SSH/SCP/SFTP command.

3. Check that the SSH client/SSH agent (e.g. WinSCP, PuTTY, Pageant, etc) you use points to the correct directory containing the private SSH keys.

4. Check that the .pem private SSH key file has been converted successfuly to the .ppk format.

5. If you installed a new version of openssh-client or openssh-server, try to erase/purge the already installed version before installing the new one, for example:

sudo yum remove openssh-server
sudo yum -y install openssh-server openssh-clients
or, on some other Linux distros:

sudo apt-get purge openssh-server
sudo apt-get install openssh-server openssh-client
6. If you have another active SSH session/terminal open, check that the SSH daemon is running, by calling "sudo service sshd status" or, on some other distros, "sudo service ssh status". If it's stopped, try to start it.

7. If no other terminal is opened, generally an instance restart should restart the SSH daemon as well. You can also check in the web console whether or not the SSH daemon started during the boot: Viewing the Boot Log of an Instance