- 최신
- 최다 투표
- 가장 많은 댓글
Hello.
According to the documentation, "SSM-SessionManagerRunShell" is automatically set up when using a session manager.
https://docs.aws.amazon.com/systems-manager/latest/userguide/getting-started-sessiondocumentaccesscheck.html
When you configure Session Manager for your account, the system creates a Session type document SSM-SessionManagerRunShell. This document stores your session preferences, such as whether session data is saved in an Amazon Simple Storage Service (Amazon S3) bucket or Amazon CloudWatch Logs log group, whether session data is encrypted using AWS Key Management Service (AWS KMS), and whether Run As support is allowed for your sessions. The following is an example.
Also, looking at the questions below, it seems like this is a temporary issue and will be resolved over time.
https://serverfault.com/questions/1143873/aws-ssm-invaliddocument-document-with-name-ssm-sessionmanagerrunshell-does-not
I had the same issue today.. Before you can set a password for your new user, AWS KMS encryption must be enabled in your session preferences.
I had to enabled KMS in Session Manager Session Preferences. You will require a Customer Manged KMS key that SSM and Users can use
관련 콘텐츠
AWS 공식업데이트됨 2달 전- AWS 공식업데이트됨 일 년 전
- AWS 공식업데이트됨 2년 전
I found the same thread on serverfault.com, but that doesn't seem relevant here, as I haven't "switched from basic/standard to advanced tiers".
Is there a sane way to deal with the fact AWS doesn't provide a default SSM-SessionManagerRunShell which breaks Fleet Manager et al?
In a multi-account organization this is a PITA as each Account AND REGION?? must be configured individually to get this document created before anything will work.
StackSets would be my goto kludge to deal with this, but they FAIL if/when anyone has touched the Session Manager prefs and thus created this document. Documents are versioned so CF should just create a new version as default, but no that's not default behavior. Ok, so we set the UpdatePolicy to NewVersion per the documentation. That works great for updates...IF CF CREATED THE DOC...but still blows up if/when the doc already exists because someone has ClickOps it into existence.
Frankly it boggles my mind why in the world the Session Manager team thought an SSM doc was a good place to store configuration for anything. SSM has both Parameter Store and AppConfig in the SSM product line itself and yet...it creates this ridiculous kludge for storing configs that just makes a mess.
Same experience as Nathan in the previous comment. I haven't switched tiers or anything. I just set up SSM today and this document doesn't exist.