Skip to content

Conversation

@sudo-rgorai
Copy link

This project implements a private Certificate Authority (CA) for generating SSH and SSL certificates. It enables you to generate SSH host and user certificates, as well as client SSL certificates for secure communication.

@sudo-rgorai
Copy link
Author

sudo-rgorai commented Jul 6, 2023

Documenting other changes suggested so far:

  1. Use dynamic region input for all AWS services (84a9e1d, 571e245)
  2. Remove action for generating root X.509 certificate (should be generated manually and added as env variable) (1e8aa25)
  3. Use current timestamp for generating AWS auth header (123b832)
  4. Accept lambda event values as parameters instead of manually editing the script (ce72f23)
  5. Simplify lambda event json (ce72f23)
  6. Use exact filenames for deleting temporary files (do not use *) (abcbce9, 8039e58, ba4deb7)
  7. Keep uniform certificate validity in days (ce72f23, e27dff0)
  8. Invoke lambda function using lambda url instead of aws cli (99a8b9b)

Good to have:

  • Signing using other keys apart from RSA


CMD [" ${CA_ACTION}" , "${CA_LAMBDA_URL}", "${USER_SSH_DIR}", "${SYSTEM_SSH_DIR}", "${SYSTEM_SSL_DIR}", "${AWS_STS_REGION}", "${AWS_PROFILE}"]

RUN sleep infinity No newline at end of file
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sleep infinity here will cause the container to build forever, ideally it should be executed inside a script

python3-venv \
openssl \
openssh-client \
jq
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ubuntu has jq already.

@@ -0,0 +1,32 @@
FROM ubuntu:latest
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of using ubuntu, can we use any other base image, may be alpine?

@Srinivasan-tm
Copy link
Contributor

some findings in implementing this on dev server:

  • Main reason for it failing previously were 2 things:
  1. Ssh version mismatch. The sshd daemon that was running was of version 7.4 and the [email protected] cert verification algorithm is supported from versions 7.8 and above.

  2. The second reason for failure was the default setting of UsePAM clause in /etc/ssh/sshd_config file to no. Changing it from UsePAM no to UsePAM yes enabled the use of ssh certificates by the ssh daemon.

  • Some practices to follow are:
  1. The client cert's principal should always match the corresponding username of the host
  2. The host cert's principal must always match the IP address or domain name of the host
  3. Do not include an authorized_principals file in /etc/ssh/
  4. PasswordAuthentication clause must be set to no so that the client does not get password authentication prompt when cert verification fails
  5. Check the path where HostKey path is mentioned in /etc/ssh/sshd_config and make sure it points to the right private key

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants