Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FAQ: Audit SSH usage #386

Merged
merged 4 commits into from
Jan 12, 2020
Merged

FAQ: Audit SSH usage #386

merged 4 commits into from
Jan 12, 2020

Conversation

drnickiw
Copy link
Contributor

what

  • How to audit SSH usage FAQ

why

  • Imported from Google Doc

Links to #353

@drnickiw drnickiw self-assigned this Feb 17, 2019
@drnickiw drnickiw changed the title Audit SSH usage FAQ-Audit SSH usage Feb 17, 2019
@drnickiw drnickiw changed the title FAQ-Audit SSH usage FAQ: Audit SSH usage Feb 17, 2019
## Answer

The best way is with Teleport. We’ve implemented this with other clients. However, those Helm Charts are not yet open-sourced. We are working with them to make that happen; see [here](https://github.com/gravitational/teleport
).
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
).


## Answer

The best way is with Teleport. We’ve implemented this with other clients. However, those Helm Charts are not yet open-sourced. We are working with them to make that happen; see [here](https://github.com/gravitational/teleport
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
The best way is with Teleport. We’ve implemented this with other clients. However, those Helm Charts are not yet open-sourced. We are working with them to make that happen; see [here](https://github.com/gravitational/teleport
The best way is with Teleport. We’ve implemented this with other clients. However, those Helm Charts are not yet open-sourced. We are working with them to make that happen; see [here](https://github.com/gravitational/teleport).

The best way is with Teleport. We’ve implemented this with other clients. However, those Helm Charts are not yet open-sourced. We are working with them to make that happen; see [here](https://github.com/gravitational/teleport
).

Gravitational makes a Helm Chart available for Teleport. However, last we checked, it didn't work the way we'd want it to, whereby Teleport is deployed on all nodes as a `DaemonSet`.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
Gravitational makes a Helm Chart available for Teleport. However, last we checked, it didn't work the way we'd want it to, whereby Teleport is deployed on all nodes as a `DaemonSet`.
Gravitational makes a [Helm Chart available for Teleport](https://github.com/gravitational/teleport/tree/master/examples/chart/teleport). However, last we checked, it didn't work the way we'd want it to, whereby Teleport is deployed on all nodes as a `DaemonSet`.


Gravitational makes a Helm Chart available for Teleport. However, last we checked, it didn't work the way we'd want it to, whereby Teleport is deployed on all nodes as a `DaemonSet`.

Technically, we have our own solution called `sudosh`, but that's subpar by comparison. It's an extremely simple wrapper for `sudo` that enables it to be used as a system login shell. `sudo` natively supports session logs and replay. The downside with this solution is we still must store the `sudo` binary logs somewhere, so it's not as tamper-resistant as Teleport. In addition, the logs are binary, so shipping them to a log store like Sumologic or Splunk is not recommended.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
Technically, we have our own solution called `sudosh`, but that's subpar by comparison. It's an extremely simple wrapper for `sudo` that enables it to be used as a system login shell. `sudo` natively supports session logs and replay. The downside with this solution is we still must store the `sudo` binary logs somewhere, so it's not as tamper-resistant as Teleport. In addition, the logs are binary, so shipping them to a log store like Sumologic or Splunk is not recommended.
Technically, we have our own solution called [`sudosh`](https://github.com/cloudposse/sudosh), but that's subpar by comparison. It's an extremely simple wrapper for `sudo` that enables it to be used as a system login shell. `sudo` natively supports session logs and replay. The downside with this solution is we still must store the `sudo` binary logs somewhere, so it's not as tamper-resistant as Teleport. In addition, the logs are binary, so shipping them to a log store like Sumologic or Splunk is not recommended.

@osterman
Copy link
Member

This PR includes changes from #385

This usually means one of two things:

  1. Your master branch is not pristine (as in contains changes), so if you fork from it, you're including changes. See https://stackoverflow.com/a/1628334/1237191
  2. You are not changing back to master before starting a new fork

@drnickiw
Copy link
Contributor Author

drnickiw commented Feb 19, 2019 via email

@drnickiw
Copy link
Contributor Author

I created new forks from master each time. This first one stated there was a difference in the commits that was awaiting review from a reviewer at the origin though, so I assumed it was something that was pending on your end and continued on. I'll check this issue though.

________________________________ From: Erik Osterman [email protected] Sent: Monday, February 18, 2019 9:48 PM To: cloudposse/docs Cc: drnickiw; Assign Subject: Re: [cloudposse/docs] FAQ: Audit SSH usage (#386) This PR includes changes from #385<#385> This usually means one of two things: 1. Your master branch is not pristine (as in contains changes), so if you fork from it, you're including changes. See https://stackoverflow.com/a/1628334/1237191 2. You are not changing back to master before starting a new fork — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub<#386 (comment)>, or mute the threadhttps://github.com/notifications/unsubscribe-auth/Artg4ad9tDlO1kUiKc3wWv_Rzv26VvG_ks5vO2XsgaJpZM4a_2Tx.

@drnickiw drnickiw closed this Feb 19, 2019
@drnickiw
Copy link
Contributor Author

This PR includes changes from #385

This usually means one of two things:

  1. Your master branch is not pristine (as in contains changes), so if you fork from it, you're including changes. See https://stackoverflow.com/a/1628334/1237191
  2. You are not changing back to master before starting a new fork

@drnickiw drnickiw reopened this Feb 19, 2019
@drnickiw
Copy link
Contributor Author

The second unnecessary file should be properly removed.

@osterman osterman merged commit f3ecdac into master Jan 12, 2020
@osterman osterman deleted the audit-ssh branch January 12, 2020 23:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants