yo prompts for OCI API Key Passphrase for each operation

[nova2moon]

Using free OCI account, managed to install yo on Cloud Shell, went though all configuration API keys, pasted PEM/public to Console, and things APPEAR to work, however, for each yo operation, it prompts for "Passphrase":

tt@cloudshell:.oci (us-ashburn-1)$ yo list OCI API Key Passphrase: Incorrect passphrase OCI API Key Passphrase: Incorrect passphrase OCI API Key Passphrase: ┏━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━┳━━━━━┳━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━┓ ┃ Name ┃ Shape ┃ Mem ┃ CPU ┃ State ┃ Created ┃ ┡━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━╇━━━━━╇━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━┩ │ instance-test1 │ VM.Standard.E2.1.Micro │ 1 │ 1 │ RUNNING │ 2025-12-03 13:58:50 │ └───────────────────┴────────────────────────┴─────┴─────┴─────────┴─────────────────────┘

in above example, mistyping the original chosen passphrase (which was required, and not optional), causes yo to (correctly) reject it, when right passphrase is typed it continues to run as expected, however, running any yo command asks for it again.

Tried yo cache, and other tricks like trying to "feed" it but didn't work: echo "passp" | yo list :)

[brenns10]

Hi @nova2moon, thanks for reaching out!

This is the intended behavior for API keys with passphrases. Keeping an API key "unlocked" across command executions would require either saving the key/password plaintext to disk, or implementing some sort of daemon (like an SSH agent) to manage the key. The second one sounds promising, but determining what process is authorized to use the key is difficult to do securely, making it not much better than just saving your key/password to disk. Rather than give the illusion that we have a secure way of managing this, I'd rather just require the passphrase for each command.

That said, if Yo prompts for a passphrase more than once per command execution -- that is a bug!

Tried yo cache, and other tricks like trying to "feed" it but didn't work: echo "passp" | yo list :)

Hm, password on stdin feels like it should have worked. Strange! I'll take a look at whether we can make it work.

original chosen passphrase (which was required, and not optional),

Do you mean you have an external requirement that requires using a passphrase? In my experience, the OCI CLI & SDK does not require a passphrase when generating your API key. How did you generate yours? When I've used the oci setup keys command, the passphrase prompt indicates that you can enter "N/A" for no passphrase:

$ HOME=. oci setup keys
Enter a passphrase for your private key ("N/A" for no passphrase): 
Repeat for confirmation: 
Public key written to: ./.oci/oci_api_key_public.pem
Private key written to: ./.oci/oci_api_key.pem

If you don't have an external requirement, then I personally would not recommend the passphrase. API keys can be revoked in the console at any time, and the passphrase adds a lot of overhead, as you're seeing. You can either regenerate the keys without the passphrase, or use steps like the following to remove the passphrase from your existing key (useful reference):

mv ~/.oci/oci_api_key.pem ~/.oci/oci_api_key_backup.pem
openssl rsa -in ~/.oci/oci_api_key_backup.pem -out ~/.oci/oci_api_key.pem
# this should prompt you for the old passphrase, and then write it out without a passphrase
rm ~/.oci/oci_api_key_backup.pem

If you do have an external requirement to use a passphrase, then your options are limited:

• The ~/.oci/config file can contain a pass_phrase configuration in a profile. See the docs. This is deprecated, and putting the passphrase here does defeat the purpose!
• The OCI CLI has an environment variable, OCI_CLI_PASSPHRASE, which allows you to pass it in the environment. See the docs. I think it would be reasonable to add support for that in Yo, so that you could (securely) put the passphrase into your environment, should you wish for it to persist.

[brenns10]

I went ahead and tested on my machine - the prompt is indeed only once per command execution, which is good. (Yo may make multiple requests, but the SDK should at least cache the key for the duration of the one command execution).

I can reproduce that stdin does not work. I believe that's because the password prompt is implemented with getpass(), which is communicating with the controlling terminal using control sequences to ensure that your password is not echo'd. So it's not reading from stdin at all. It's not uncommon for CLI utilities to implement a --password-on-stdin flag, which I could do (e.g. yo --password-on-stdin list or maybe yo -P list for short). But I don't want to add that unless it'll actually get used -- let me know.

Finally, I did add support for OCI_CLI_PASSPHRASE and verified it works. It's currently in the main branch, so there's not yet a PyPI release. I'll likely make a release soon, but since there is a small breaking change queued, I need to do some communication before I can just release the code as-is. Thus, if you'd like to try it now, the best approach would be to clone it from git. You could even do something like pip install git+https://github.com/oracle/yo#main to directly install it so you don't need to clone manually.

[nova2moon]

@brenns10 Not in a bad way, but please lets CLONE you!! If only more folks were like you, what a World we would live in...

Anyways, as can imagine, you scored on ALL counts.

1. My bad, not noticing the "N/A", kept typing "enter" and it prompted, not bothered to READ, so eventually gave it a password and got into this "trap" - GLAD it did since "met" you.. learned about getpass and more.
2. Did the passphrase removal steps, and worked like a charm!!
3. Maybe next time will try the git/cloning or once release is out will test the OCI_CLI_PASSPHRASE (kept the orig .PEM)

Next "block", trying to launch images that are not directly on the "OS", should probably open a new "issue" :) ?
Ubuntu, centos is there, but not finding Alma , Rocky linux, or more importantly, anything on the Marketplace side, which is where partners can maintain their own images..

yo images | grep ...
is what used.. are there more flags to expand image scope?

[brenns10]

Hey @nova2moon, glad I could help!

Next "block", trying to launch images that are not directly on the "OS", should probably open a new "issue" :) ?
Ubuntu, centos is there, but not finding Alma , Rocky linux, or more importantly, anything on the Marketplace side, which is where partners can maintain their own images..

No need to open a new issue, I'm happy to leave this open until we've got your questions sorted. You've encountered a to-do item that has been slowly climbing the priority list. As you can tell from the README this tool mainly came about to make it easier for me to launch Oracle Linux instances, since OL is what my job is actually about. But it's nice to be able to launch other image types too.

The images you see in Yo are Platform Images. For some reason, Ubuntu & CentOS got that privilege and no other distros. Those, alongside with Custom Images, are visible in Yo. The Marketplace images you mentioned are available through a totally different API, which I haven't yet implemented. Those images require accepting legal terms & payment, so it seems like a somewhat dangerous feature, which is why I hadn't yet implemented it. But I've received some other requests for it, so I guess it's time.

Last I checked, the marketplace has some other Linux distributions, but most of it is applications.

In general, when I need to launch a distro other than OL, CentOS, or Ubuntu, I typically import it as a custom image. The process goes something like this:

1. Find the distro's "cloud image". Download the one which is QEMU/qcow2. One good example is Fedora.
2. Using the OCI Console (web ui), upload to an object storage bucket in OCI. (You can delete the object/bucket after the process is done).
3. Using the OCI Console, import the custom image into the same compartment you create instances within.

Once that's done, Yo will see your newly created image and you can launch instances with it. I actually have a script that automates the import process, which I've pondered adding to Yo. This seems like a decent reason to do so.

Unfortunately, I cannot promise any timeline on either marketplace support, or automated importing. I'll be traveling soon for a conference and then the holidays hit.

[nova2moon]

Sure, Thanks TRUE HUMAN for the amazing help!!

1. Regarding marketplace/agreement, maybe the API allows to query if the given user already agreed to terms (on the website) even on webpage it only asks ONCE, later sessions already have it checked, for the given image, maybe that can be queried and u can proceed.
2. Not all images allow snapshot/export/custom image generation, some allow only launch.
3. A bit confused on specification of OS/Image, say:

[instances.ol8] inherit = DEFAULT os = Oracle Linux:8 image = imported-image-ol8arm name = ol8-1

returns:
error: Instance profile ol8 specifies both: image, os

ok, so remark the "#os" line, and still same error... looking higher found another line above with:

os = Oracle Linux:9

ok, so, comment that one as well.. Now get:

error: Instance profile DEFAULT must specify one of: image, os

hmm.. so it wants the TOP section to have OS or IMAGE... ok, so lets MOVE that image to TOP default section:

#os = Oracle Linux:9 image = imported-image-ol8arm

oh oh... now it complains that ol6 has BOTH:

error: Instance profile ol6 specifies both: image, os

after commenting that, it goes to ol7, ol9... finally got it to work, just wondering if there should/is a simpler one liner to use an image without having to edit all sections :)

4. Got it to work, noticed that in OS case it prints:
   Using image Oracle-Linux-9.6-aarch64-2025.10.23-0

However, in the image case it does not print Using Image... so hard to tell if it picked the right one.

Same thing for AD, used the AD=0, supposed to pick randomly, but does not say which it picked.

Hoping this exchange will help others. Thanks for your time, and sharing this wonderful tool, well worth the set up effort over OCI CLI.

[brenns10]

Hi @nova2moon I think you stumbled upon something which I documented but did not highlight very well:
https://oracle.github.io/yo/guide/configuration.html#os

Since instance profiles are inherited, Yo will see the "inherited" os config as well as the image config and it won't know which one to apply. To work around this, I used an obscure feature of the .ini config syntax which allows you to "clear" a configuration value. So the idea would be that your profile where you wanted to specify an image rather than an os would look like this:

image = my-custom-image
# leave blank without "=" to clear the value
os

Then you can leave all the other profiles alone.

This may have been lazy, I'll see if there's a way to clear inherited image/os values automatically when you specify the alternative one. Or at the very least an improved error message is warranted.

[nova2moon]

wow, yes, the clear does work!! thanks. although got mixed up a bit if removing all os/image from top (default) it does not work either, basically wants ALL sections to be correct, even though only ONE section is ACTUALLY used, i.e. --profile xyz (maybe the other sections can be "invalid" since they are not really used..)
Thanks, i think this custom image should work for most images that allow snapshots.. those that don't will need to be launched natively/directly...
Thanks dear!