It turns out that the ciphers were a problem but in the wrong way - it's
OEM that's out-of-date. The MOS note listed ciphers arcfour, blowfish and
cbc which our sysadmin confirmed are not allowed, security-wise. He also
validated that sshd_config is up-to-date on both ends so the problem seems
to be with OEM (12.1.0.5).
I switched directions and used a "pull" instead of "push" install, grabbing
"AgentPull.sh" using curl on the AWS server and the agent installation
worked fine.
Dave
On Fri, Jul 6, 2018 at 2:46 PM, Jeremiah Cetlin Wilton <
jcwilton93@xxxxxxxxxxx> wrote:
Any sshd messages in the /var/log/auth.log on the DB server at the time of
the attempts?
Jeremiah
------------------------------
*From: *"gdherri" <gdherri@xxxxxxxxx>
*To: *"Ls Cheng" <exriscer@xxxxxxxxx>
*Cc: *"Pete Sharman" <peter.sharman@xxxxxxxxxxxxxx>, "Niall Litchfield" <
niall.litchfield@xxxxxxxxx>, "Oracle Mailing List" <oracle-l@xxxxxxxxxxxxx
*Sent: *Friday, July 6, 2018 12:17:53 PM
*Subject: *Re: AWS EC2 OEM support
Update - the FW team has confirmed our rules were pushed and via splunk
logs they've validated activity over the needed ports. I tried to the push
and install method from OEM but it's initial check comes back with:
2018-07-06_12-21-17:INFO:ssh connect timeout 60000
2018-07-06_12-21-18:INFO:Error Message: PROV-16011: Algorithm negotiation
fail
This matches MOS doc 2373503.1 which says the /etc/ssh/sshd_config files
needed ciphers, both source and dest, yet I've never had to do that before
but then again I've never installed an agent on AWS EC2 before.
Dave
On Fri, Jul 6, 2018 at 4:46 AM, Ls Cheng <exriscer@xxxxxxxxx> wrote:
Hi Pete
Just wondering, why a proxy server
<https://docs.oracle.com/cd/E73210_01/EMADV/GUID-E00C6B3B-D5E2-4E2F-9F94-8A136E3D696E.htm#EMADV636>
is requiered (or it is optional?) when there is FW? Isnt it enoguh just
open the ports?
Thanks
On Fri, Jul 6, 2018 at 12:27 AM, Pete Sharman <
peter.sharman@xxxxxxxxxxxxxx> wrote:
I don’t even remember writing the post that Dave mentioned in his
original email, but it sounds like it got sorted out while I was still
asleep anyway. \uD83D\uDE0A
Firewalls are a PITA for EM. I never had to worry about them with the
stuff I did at Oracle, but I’ve been going backwards and forwards
multiple times with a client recently with the same problem Dave seems to
have. I can see why the doc says set it up without firewall rules then add
the rules afterwards!
BTW Niall, that support note DOES also point direct to the doc where
this stuff is covered - https://docs.oracle.com/cd/
E73210_01/EMADV/GUID-E00C6B3B-D5E2-4E2F-9F94-8A136E3D696E.htm#EMADV632.
\uD83D\uDE0A
Pete
*From:* oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> *On
Behalf Of *Dave Herring
*Sent:* Friday, July 6, 2018 05:21 AM
*To:* Niall Litchfield <niall.litchfield@xxxxxxxxx>
*Cc:* ORACLE-L <oracle-l@xxxxxxxxxxxxx>
*Subject:* Re: AWS EC2 OEM support
Yeah, I made the mistake of trusting the FW team when they said they
properly implemented by FW requests. I just checked from our OEM server
that port 3872 and in some cases 1521 are still blocked. I'm currently
checking 4903 from the AWS back to OEM. Unfortunately FW rules are only
pushed Tues and Thurs, even if they made a mistake on something that
already passed.
In the meantime, is it safe to say that outside of adding my public SSH
key to the OEM server's $HOME/.ssh/authorized_keys file, then using a Named
Credential with a credential type of "SSH Key Credentials" should work? I
followed youtube vid "Oracle Enterprise Manager 12c: Create SSH Key
Named Credentials " which isn't directly for AWS EC2 but ideally should
work.
Dave
On Thu, Jul 5, 2018 at 12:36 PM, <niall.litchfield@xxxxxxxxx> wrote:
I'd imagine that your firewall rules (either virtual or physical or
both) will require connectivity between your on-premises OEM and the
off-premises EC2 instances on the relevant ports. These are documented in
the surprisingly hard to find Note https://support.oracle.
com/epmos/faces/DocumentDisplay?id=2362242.1 2362242.1. If you have
internal firewalls this is probably old hat, but if you don't it's the most
likely reason that ssh succeeds but monitoring doesn't. You'll also need
name resolution to be consistent.
On Thu, Jul 5, 2018 at 5:45 PM Dave Herring <gdherri@xxxxxxxxx> wrote:
Folks,
(I've been given the task of setting up monitoring for a number of
Oracle databases on AWS EC2 and unfortunately given little to no guidance,
so I apologize upfront if my question seems rather basic.)
Has anyone set up management agents on AWS EC2 environments to monitor
from an OEM outside of AWS? We did something similar in the past for RDS
environments but I was hoping we wouldn't have to rely on the OEM AWS
plugin, which only provides a rather limited subset of functionality of OEM
for the envs.
Since we have SSH key pairs set up to reach the AWS servers, my
assumption was I could perform agent installations from OEM (which resides
outside of AWS), using pre-defined Named Credentials that use SSH key
pairs. Unfortunately it seems the connection can't be made that way
through OEM, although I did prove I COULD connect at the OS level using the
same method.
I did find a post by Pete Sharman from 5/2016 saying that under OEM 13c
we'd need to have an Amazon VPC configured and only then could a typical,
OEM to agent monitoring configuration and that the only other option is to
use the AWS plugin. But, that's just over 1yr old and I wasn't sure if
anything has changed since then.
Thx.
--
Dave
--
Niall Litchfield
Oracle DBA
http://www.orawin.info
--
Dave
--
Dave
