#security (2018-08)

https://krebsonsecurity.com/2018/08/reddit-breach-highlights-limits-of-sms-based-authentication/

This is something that is huge, and is hard to understand

It is as specific and specialist as anything we do

So I hope this channel helps us pull together the resources that help keep us all on tract for secure environments

Yea, it’s a never ending endeavor

100

https://gsuiteupdates.googleblog.com/2018/08/control-government-backed-attack-alerts.html?m=1

Not a feature I was exactly asking for, but hey, why not!

That’s an alert that would freak me out.

if they already have a good signal detector, it’s pretty nice that they share

ahahah, so you get an alert saying a government is attacking you (does it includes the us gov? ;)) - then what ? you go to the police ?

Then you pack your bags and prepare for rendition

https://latacora.singles/2018/08/03/the-default-openssh.html

https://apple.stackexchange.com/questions/48502/how-can-i-permanently-add-my-ssh-private-key-to-keychain-so-it-is-automatically

• this OSX feature lets users pick a high entropy passphrase and have ssh-add -K store the phrases in Keychain.
• this also means we can’t easily type the passphrase (when requested) when geodesic shell starts

all this makes me think that my ssh-agent should live on a secure device that prompts me on each use

yea, would be neat if the yubikeys could act as an SSH agent

Also, if adding UseKeychain yes, recommend also adding IgnoreUnknown UseKeychain because the UseKeychain extension is not supported by alpine linux.

just found this: https://github.com/cyberark/summon-aws-secrets

it’s like chamber but for aws secrets manager.

So, I had kind of written off secrets manager because of the ease of use of chamber.

but the automatic key rotation feature using lambdas seems pretty sweet from a compliance POV

yea, would be neat if the yubikeys could act as an SSH agent they can act as an SSH agent by acting as a GPG agent:

https://github.com/drduh/YubiKey-Guide

this too reads as very far from “turnkey” && has the same “how can I plumb my agent into docker” problems as the current ssh-agent

@jylee has joined the channel

@pericdaniel has joined the channel

@Dylan has joined the channel

@tarrall has joined the channel

@melynda.hunter has joined the channel

@adamstrawson says:
That did the trick, thanks. Next question i’m afraid, I’m struggling to see how you get the github-authorized-keys container and the bastion container to work together. They’re both running and working independently, but the bastion container doesn’t seem to want to do anything with the keys (eg. if I ssh to -p 1234, I get permission denied.) github-authorized-keys has synced the users and keys to the host machine (I can ssh fine to the host machine with a synced user), but via the bastion container it doesn’t detect any keys. Can’t see in the docs how the two work together

@adamstrawson has joined the channel

so in the bastion container, are you bind-mounting /etc/passwd from the host machine?

the other thing to check is that the github-authorized-keys command in the bastion container can talk to the host API

https://github.com/cloudposse/bastion/blob/master/rootfs/usr/bin/github-authorized-keys#L20

you might need to change API_URL

since localhost in the container is not equal to localhost of the node

(when we deployed this, we deployed the github-authorized-keys container and bastion container in the same Pod in kubernetes - which allows them to talk over localhost)

@Andriy Knysh (Cloud Posse) has joined the channel

@loren has joined the channel

@tolstikov has joined the channel

@loweryr has joined the channel

@justin.dynamicd has joined the channel

@Arkadiy has joined the channel