ssh to solaris 10 error: “no matching key exchange method found”

I first ran into this error after installing Solaris 10 on a Sun Ultra 60 that I had a while back, but I’ve recently ran into it again installing Solaris 10 on Proxmox:

Unable to negotiate with 192.168.1.95 port 22: no matching key exchange method found. Their offer: gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

The solution to configure my Mac to be able to use older key algorithms was a combination from here and answers on this post.

I edited my ~/.ssh/config and added a Host entry for the ip of my Solaris 10 instance, adding:

Host 192.168.1.95
HostKeyAlgorithms=+ssh-rsa
KexAlgorithms +diffie-hellman-group1-sha1

And now I can just ssh in as normal (no need for any additional params as shown in the first post, as the required options are configured in my .ssh/config.

Creating new Oracle user, new instance

Running Oracle 19c in Docker, I connected with sqlplus and attempted to create a new user:

create user example identified by password;

and got this cryptic error:

ORA-65096: invalid common user or role name

Per answers on this post, this is usually because you connected to the root container database (CDB) instead of a pluggable container database (PDB).

You can cofirm what you are connected to with:

show con_name

and sure enough, I’m connected to CDB$ROOT:

CON_NAME 
------------------------------
CDB$ROOT

List available PDBs with:

show pdbs

shows:

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 ORCLPDB1 READ WRITE NO

Updating my connection properties to connect to SERVICE=ORCLPDB1 and now I’m good.

To grant all privs to a new user:

grant all privileges to username

Perception is everything (when defects are not defects)

I worked on a project in the early 2000s where the client didn’t like to be told that we had x hundred defects in our backlog. To address the negative connotation of the tickets being called “defects” we renamed them System Investigation Requests or as we called them day to day “SIRs” (a quick Google will tell you that this is not not a unique name for defect tickets, but in 25+ years something I’ve only come across a couple of times, and only for projects with this same client).

The truth was was the majority of tickets were actually genuine defects but there were also some requests for refactoring, TODO follow-ups, potential issues that should be investigated that could lead to identifying a defect, or just areas for improvement.

it’s interesting how we perceive things either positively or negatively just based on name, The client was more comfortable knowing these issues were vaguely called SIRs, but if I was the client I would have thought “I know these are defects, you’ve just renamed them” but in this case they were happy calling them something else.