前提を覆すようで恐縮ですが、そのアプローチはあまり推奨できないです...
lambda の中に EC2 の接続情報を持つ必要がある点があまりセキュアではないですし、通常 lambda はVPC の外にいて自身のIPを固定できないので、パブリックからの ssh を許可することになってしまいます。さすがにそれは運用として許容できる範疇ではないでしょう。。
(VPC lambda であれば public IP の問題は解消しますが、それでもあまり良いアプローチではないように思います)
どうしても lambda から EC2 内の何かしらをキックしたいのでしたら、Systems Manager Run Command を介してコマンドを実行させる感じにするのが良いと思います。変更の手数が少なめで比較的安全な方法となるとこれが良さそうかなと。
Run Command の詳しい使い方の解説はさすがに書ききれないので説明は省きます。ご自身で調査してください。...とはいえ、その投げ方では些か不親切と思いますので、概要を以下で述べます
主な変更点としては、ssh してコマンド実行する部分を Systems Manager の Run Command (AWS-RunShellScript) に代わりにやらせる、というものになります。
lambda から見ると ssh の代わりに Run Command の実行 API をキックする形になります。
EC2 の中にジョブを実行するシェルスクリプトなりを設置して、それを Run Command に叩いてもらうことで EC2 内のジョブを実行できるようになります。実行結果の通知は lambda に戻すことを考えるのではなく、 EC2 内のシェルから外に通知させるのが良いです。
この「外に通知」ですが、具体的には該当ジョブの実行結果を投げる用の SNS トピックを作り、そこに投げる...などの方法が考えられます。EC2 内のシェルがジョブの仕事を終えたら、その結果を SNS publish でもって投げ込みます。SNS にジョブの実行結果をハンドリングする別の lambda をサブスクライブさせておけば、検知ではなくとも近しいことはできると思います。
※なお、EC2 にできるだけ手を入れたくない場合でも、おそらく Run Command の利用自体は避けられないと思います。lambda から ssh するよりは幾分が良いだろうと考えます。この場合は EC2 の外からジョブの結果を知る必要があるので、Step Functions を用いて「Run Command の実行結果」をポーリングする実装が一番綺麗かと思います。とはいえこっちの方法は慣れてないと割と工数がかかると思うので、前者(EC2 内で SNS を叩かせる)の方法のが楽です。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。