Add ssh keys capability to furyagent

lzecca78 commented 4 years ago

Hi 👋 ! the purpose of this pr is to move the management of the ssh keys to furyagent. I have currently introduced the following behaviour:

furyagent init ssh-keys => will copy to bucket folder the local ssh/ssh-users file structured as follow:

githubuser1
githubuser2
....
githubuserN

furyagent configure ssh-keys => basically will download from the bucket the previous file and setup the github.keys for every user listed in the authorized_keys of ubuntu user

Missing task to be added that i need to handle:

add the default key as external parameter to be pass from ClusterComponent SSHkey struct

and probably more, i look forward for your thoughts and suggestions 🙏

angelbarrera92 commented 4 years ago

I love the Idea. I want to see it in action before merge it ;)

lzecca78 commented 4 years ago

@angelbarrera92 you're right. i tested it locally but still missing the e2e test. As soon as i can i will add it!. Anyway i changed in the last commit the input file to a yaml one with an extendible struct eventually. Give it a look if you want :)!

lzecca78 commented 4 years ago

basically the configuration file will be the folllowing :

users:
  - name: luca
    github_id: lzecca78
    ssh_public_key_file: secrets/lzecca.pub
  - name: philippe
    github_id: phisco
    ssh_public_key_file: secrets/lzecca.pub
  - name: samuele
    github_id: nutellinoit
    ssh_public_key_file: secrets/lzecca.pub
  - name: lucanovara
    github_id: lnovara
    ssh_public_key_file: secrets/lzecca.pub
  - name: nonexisting
    github_id: nonexistinguser
    ssh_public_key_file: secrets/lzecca.pub

the furyagent will parse it and apply :

2020/01/16 15:07:26 found github_id lzecca78
2020/01/16 15:07:27 writing ssh keys for user luca
2020/01/16 15:07:27 found ssh_public_key_file secrets/lzecca.pub
2020/01/16 15:07:27 found github_id phisco
2020/01/16 15:07:27 writing ssh keys for user philippe
2020/01/16 15:07:27 found ssh_public_key_file secrets/lzecca.pub
2020/01/16 15:07:27 found github_id nutellinoit
2020/01/16 15:07:28 writing ssh keys for user samuele
2020/01/16 15:07:28 found ssh_public_key_file secrets/lzecca.pub
2020/01/16 15:07:28 found github_id lnovara
2020/01/16 15:07:28 writing ssh keys for user lucanovara
2020/01/16 15:07:28 found ssh_public_key_file secrets/lzecca.pub
2020/01/16 15:07:28 found github_id nonexistinguser
2020/01/16 15:07:28 user nonexistinguser not found!
2020/01/16 15:07:28 error while parsing github
2020/01/16 15:07:28 found ssh_public_key_file secrets/lzecca.pub
2020/01/16 15:07:28 found static ssh_public_key_file ssh_key
2020/01/16 15:07:28 conservative behaviour: error found, skipping the authorized_keys update
exit status 1

As you can see, if an error is found, it won't update the authorized_keys. and the result, if there are no error is:

#### lzecca78
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDCQktiDB7z69O8bOopadiIeEsUav+H902GBb40918nAyV0FXpkS+y817xpTChtGbxzEjmwXr+43Z1pjwnBlYBZzPb3L6Pkwhu5MajOV4gt1Pd3hmvWLPCHL+mQxmwVELHtuPHun747Z48c3gp33Y/40UbowQsU0DTZrAspmygOfb6olhhNWSecFm6Q8OIXZwVAKp0Zy6ykgLeuv+ieGqVfhDO7EiFgSl4jbnQA67DgZMse7162rqUCde9g2HJ1nG3zf8lEQipHsWEzBUwrCb6DOtERQL66cCdk/C54W8UaWX6kQ024AqrEt028CoHHjm9P7GWbfTomZZ94ZhJVK7Af
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCjhX9n5R2uEBCfH4bu6ZQv1W2tYiBNFk28DSCFU7jtP0wXlt2wJsV03ByhbaLrGd4YK9Cw+/czgPiPx7r2SBnyDb5t76IbGDcvELASWh5c7G0UHVx3SLVnvgvRIblnCocY2rEji8H2FvOnvRDIl5s8zzxUpbGckMh6TG452FnodhjSWsz35VGgqBuKC/XbxXcTfahOZUOOqaKWUx3SOthQ0wFDiHivxtOozCqDsQjyuV270FXCvgy5wGHi1S6PjUhCKLJOKV4UU7/RxkodvUUlNqlimk3NJTJwfOZv874URN1Uk4y04XOD7RIaO08KVLdMlSqRXJDfigPiTey9puut
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINgwAWqZBZ9SAOYJP6qCp/7nWGF+trXQ5AgriNf9b5NI
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA0F93p5G8ymf/O1dWznhz5kAdJ0JvWARPMAInqU3OlEk+2vhgP4gNNCvfJL3Ts5LizgkNco939Z3fLivbRSG2RLLinn+G3rBuFJm+iD5YDYF4dG69T6iIznynsc8FDjCtLuf/IN7pBWZuazMxkXsfUPil/3UyoavvjQt5YCRqT69uO5RdvlAVj+Umr+YKDw8+xyMSZeJleUoq0eMnjPn2TpDHDqZBTtgRi4FACNPcs80D8ixzL4v6df5nd9Fqb+AFfIhPMsmKwM6yQR+um9YzLtjftPlU+g10GtGbTUQJb6RrbfhQe8MsLLZN7+8iy6V6RSw12aETsZ/EkXVyNw+YKw== andone@Metepec
#### phisco
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC+T7+hC3CWWuZCwZcbkryTwu18EQnGA/z0IVDlcVr/wR5RD7WoyYip7sFoxIKWecBTxgZABBNkLKu2NH6VGeQ0VO3kF/eD32Cw8Og9sf9LXHmkHVrIevZinYvVVqN9PjFzhJ24YeKNIDmR/9xrscNdOLsF4f9AsvErAu+KCXBpIfhizXWOxvRzdYE7pv30nqisAwwxa5LzzyA5yS8LxLNeuzdN7iNSdzeN7SCYyNK5OMLoFN5x/WPYCor+zm07O88BpZm3hGpqv3N15/Yx8LIZ70QNFvMFYSZ62g9Hqgt2U6wDRgITRipozoi0Gwl7IEOyc/gh7SCwNVdupxImPhjpzApVr7zhXPL5sTcEwhFE4JRZhJgiO610pFqUrH+neeEY9ei6WmY8NPLscvttSMDE4048vEUTDxgzRPCKq8cf/b2gAjEgitWpNIQetjSeN6oFILPQ1PrqJrm/Fxa/Rk5JxO18YL9bFjYDAqNXncnAazV3YqAgg5PycTYwgs6piL3vRObBJsQ0nvv9e6USlvxfS9M4d1YAoiej1HqkQrV6MkEMT19SoU1GfNSz/+tIvpQDURDi684e+xWSacCoh/LY0LtlzwUBrnGTfjvXyM3udo48vFQaDZPVo2RZsiGlbx9VMJxR1rC9w0hYtfATBZLRwI7Wj7cdS7Pie0zMRkvHjw==
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA0F93p5G8ymf/O1dWznhz5kAdJ0JvWARPMAInqU3OlEk+2vhgP4gNNCvfJL3Ts5LizgkNco939Z3fLivbRSG2RLLinn+G3rBuFJm+iD5YDYF4dG69T6iIznynsc8FDjCtLuf/IN7pBWZuazMxkXsfUPil/3UyoavvjQt5YCRqT69uO5RdvlAVj+Umr+YKDw8+xyMSZeJleUoq0eMnjPn2TpDHDqZBTtgRi4FACNPcs80D8ixzL4v6df5nd9Fqb+AFfIhPMsmKwM6yQR+um9YzLtjftPlU+g10GtGbTUQJb6RrbfhQe8MsLLZN7+8iy6V6RSw12aETsZ/EkXVyNw+YKw== andone@Metepec
#### nutellinoit
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC+RuRSTU75s7FhVbUNZxf2UUtMloN17CCWc63u0Z0cjnRecJVpwY/rbNNRieqBBXMIADiKFobDkZAwSGhEtRy2KxCJz6N/77Hv+ar9G8m4U2C8aGIIdfsIF0K1A6Sd1I7blu+/HVsaNTWbQ4fPi5VLAv452mB5dSQaUYz6P9tMlefqbmwTjyZ2crG6ML2hMEOD6MNSX/TsgjiBFrxjo0jWvdlpOohrh4X2Z3Zd4zKIrl4wCE3i+IAqW0j/qT05FCKrQOe+bP/ejAP7bvg2oVq1avp1u/LTpo+VK3avMwnkroDi86Mpgh6HUyZq0g7B7QUojkpXW52LPPdVzo9Rj4WhsJgEfVz4e0ZqtPuDYRDQ6M0xyo7HSO6aQCXl8l69rHwq3hPRASfR2qtmGQ5SxjwqX4PsAnCtDLq15dB3Pc+YmdXbGjHPRdl/N8XL2UW9gHo5grMbtWkHItH3kufLajyfcHmm/UHEPlHrfRPibKe3kaeW3H5SAXgbpXsB9SSK18abXVMRaRf2ITvils/BnWZ9j2yAvMHnmLY0Nb2ahLzLZFHwREjegzwoiVMWDbosV/ucBXPdait325yKypvf6HmWUDSFBAxqG2S29PLN3wUOPWvL9z30DPoqZt/T9gG9oQPZaLhQU7ryjKDG5fNeGtlU1gJq13tFd9wcWLIDpUrNGw==
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEkBTAqGX0JJA78Kto3T9CWSHvJei9whImpdVGQN0sfn
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA0F93p5G8ymf/O1dWznhz5kAdJ0JvWARPMAInqU3OlEk+2vhgP4gNNCvfJL3Ts5LizgkNco939Z3fLivbRSG2RLLinn+G3rBuFJm+iD5YDYF4dG69T6iIznynsc8FDjCtLuf/IN7pBWZuazMxkXsfUPil/3UyoavvjQt5YCRqT69uO5RdvlAVj+Umr+YKDw8+xyMSZeJleUoq0eMnjPn2TpDHDqZBTtgRi4FACNPcs80D8ixzL4v6df5nd9Fqb+AFfIhPMsmKwM6yQR+um9YzLtjftPlU+g10GtGbTUQJb6RrbfhQe8MsLLZN7+8iy6V6RSw12aETsZ/EkXVyNw+YKw== andone@Metepec
#### lnovara
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC0sczrB2dWdE4GLJhcWUEEnL3JLMCorn4QcJaLHC7luLiuNdx8uqUqR5Dy3VVd7DP4aLlRIaUXbnVEiUcgOxdZ2CJZO7rnj9xGaq+ocpyH6+l+f9Q81NYXNJs/k5Xr4i21TeXqT6T7XgOTBJQKN6a1whe48gPuTBT4F46MPAqLUZDtzyvEZCNg43FuQSHUkey9bN1ayNkMT2IDEs5Xpc9SF3XdOwDatQf86jBx3tIeQtybRfgLYUycyEK3qxu1a73DPRmyp14MhDkZiGCNhURPAjs+WDkl+3ICgKcl742/fYimoKipxVkBdG91/pnrSilKB5BDpGMY7CURV4nlUr1qdIHVCOMXzd/jTVxxYA0EuBZGfq39O8Ox/O0CUf/emo/lyB5ysjCYafcnRevPlNDCaPyxNcDGYebowkpuLZvbJSO3aQzUStT4fDLSvd2E+Z1YYh0Fu1sP6JR5/Vrw5PyEeo2iNxONbm6bQFdKe9sWPTslwdMOUMUoV6vmLhSwUdxi+SNo+Z5f7hL5B8gCxyl9O5X+KVB8P9f3AfPjO6nYs2s8tFlzYTq54XGcRYvdCH1JQu5ZyMhr385IHFL3DrYWx7lnEpOTbOgATELxjNYyHUMfj2/kgVvSuuZNr8p9yTDVtnvcndaGaYPz8YK6E+5B2Yhxh+Ts2VdMUG2EDB4nLQ==
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA0F93p5G8ymf/O1dWznhz5kAdJ0JvWARPMAInqU3OlEk+2vhgP4gNNCvfJL3Ts5LizgkNco939Z3fLivbRSG2RLLinn+G3rBuFJm+iD5YDYF4dG69T6iIznynsc8FDjCtLuf/IN7pBWZuazMxkXsfUPil/3UyoavvjQt5YCRqT69uO5RdvlAVj+Umr+YKDw8+xyMSZeJleUoq0eMnjPn2TpDHDqZBTtgRi4FACNPcs80D8ixzL4v6df5nd9Fqb+AFfIhPMsmKwM6yQR+um9YzLtjftPlU+g10GtGbTUQJb6RrbfhQe8MsLLZN7+8iy6V6RSw12aETsZ/EkXVyNw+YKw== andone@Metepec
#### default_ssh pub_key
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC70qVpqX3ZMMv5lLOe5Rxdkkh6Hhw46RtVuexeNSzHdcQpR0AS0020ydmjK1QbfX6D2ABl4l6wyC0XHOOJOIOolEbW9gltJlInqJE7avaCTVNfKUkxZaZNOzAZyogQh4HjPZ7vpByzM1arNFbdWWp2VTCZHm5OlU2BoVXaQeaHt+UfSJ6VGLV0ZKEbU9YiTMA1R4gbwVK7mjYPeg5buBmAGgrCBd9FJCdG/tKl4vLx8QxuKI6CuT2WXV+4l8gQpbq9Hd75UZrygDTH3RCPZZOygxuymP6wrWfdnZ2WBu3ATAKiH1oVf7XRk/budrUfe842ZIWtKtXYLxtgJRcjt6rf

angelbarrera92 commented 4 years ago

@angelbarrera92 you're right. i tested it locally but still missing the e2e test. As soon as i can i will add it!. Anyway i changed in the last commit the input file to a yaml one with an extendible struct eventually. Give it a look if you want :)!

My intention was to you to give us a live demo ;) This way we can see it in action understanding what's the new flow to provision ssh keys. I know E2E test, currently, is near to impossible.

Thanks for you awesome work @lzecca78!

angelbarrera92 commented 4 years ago

Correct me if i wrong. All the pub keys are added to the default instance user, in this example ubuntu. Am i right?

This is an open question. What if we create local users instead of provision ssh keys to the ubuntu user? As I said, this is an open question/discussion. Not to implement in this PR (which is an awesome feature).

lzecca78 commented 4 years ago

@angelbarrera92 i was thinking the same, could be done, although imho this is more a configuration management job: the implemented logic override every X minute the authorized_keys of the user ubuntu. Image now what happen if you need everytime to drop every user and recreate it (because you don't have a previous state so far). Is something that can be handle, but for the usage we do, i guess that address all user to a system one (ubuntu in this case) is something acceptable for now.

lzecca78 commented 4 years ago

Hi guys, i guess i arrived to a working release for this functionality. I removed for now useless overhead. This is the configuration that must be added to furyagent.yml in order to make it work:

clusterComponent:
  sshKeys:
    user: 'ubuntu'
    tempDir: '/tmp'
    localDirConfigs: 'secrets/ssh'

create a ssh-users.yml file in :

---
users:
  - name: luca
    github_id: lzecca78
  - name: philippe
    github_id: phisco
  - name: samuele
    github_id: nutellinoit
  - name: lucanovara
    github_id: lnovara

The yaml seems overengineered but it will allow any further ideas that usually come with: hunger comes from eating

The file ssh-users.yml will be stored into the bucket s3 under a subdir ssh

this configuration means basically:

user : the user that will be used to copy to the authorized_keys file with the right path and permission
tempDir : the temp dir that will be used for saving files when downloaded
localDirConfigs : where the init command will look for file once it will be executed

Enhancement:

there is code duplication in storage.go because for this capability is a constraint that the upload function and its inheritances can override remote file. as i wrote here : https://github.com/sighupio/furyagent/commit/d9881550d3de0dd7b705af8b998fa0effb95eb56 this could be avoid with a refactoring but is something to do further imho
- i removed the sshpubkeyfile injection for the reasons i wrote here: https://github.com/sighupio/furyagent/commit/a89f2b5bb9f249533fd532e164f8dffb06c6f359

Any ideas are welcome. I am pretty ready for a demo, nothing special eh, but just to show you the flow as asked @angelbarrera92 .

angelbarrera92 commented 4 years ago

@angelbarrera92 i was thinking the same, could be done, although imho this is more a configuration management job: the implemented logic override every X minute the authorized_keys of the user ubuntu. Image now what happen if you need everytime to drop every user and recreate it (because you don't have a previous state so far). Is something that can be handle, but for the usage we do, i guess that address all user to a system one (ubuntu in this case) is something acceptable for now.

s are welcome. I am pretty ready for a dem

Mostly understood.

An idea is flying over my mind. Should we create a 'SIGHUP' system user instead of using 'ubuntu' or any other like 'centos' or 'root'? This way we ensure we operate clusters in the same way and it does not matter if our images are based on Centos, Redhat Linux or Ubuntu.

Love the work you are doing ;)

lzecca78 commented 4 years ago

Hi everyone 👋 , as @angelbarrera92 proposed, i added the functionality to a distro-agnostic user (sighup for example, but can be customized with the relative struct in furyagent.yml).

lzecca78 commented 4 years ago

added the sudoer file for system user in order to become root without password

jnardiello commented 4 years ago

For this to be merged into fury agent, it should have no external/inter web strict dependency. I can’t see how this could work with large, on-premises, customers.

lzecca78 commented 4 years ago

@jnardiello can you explicit your doubt please? I don't understand ...

jnardiello commented 4 years ago

What happens if you have no connectivity to GitHub/s3?

lzecca78 commented 4 years ago

@jnardiello you forgot that all furyagent processes (not only ssh) rely on s3. For this specific implementation, if there is a network problem (network partitioning or whatever), the authorized_keys won't be updated for that run.

jnardiello commented 4 years ago

IMHO fury agent should evolve to avoid external dependencies (github and s3) and not the other way round. Anyway, I think we def need to have a more structured conversation regarding what fury-agent should become (if we need it, at all).

I'm not sure why this PR was started in the first place given that not discussion whatsover was started around it. Before starting to develop something, we need to understand what we want to develop, how it is relevant for our customers/workflows and how/what specs it should have (and who is going to maintain it). I'm temporarily closing it down waiting to address this in a more structured way. cc @lzecca78 @angelbarrera92

lzecca78 commented 4 years ago

Was initially started as i said in several standups, to get rid of the great problem we have on handling ssh keys on cluster. I am totally agree that probably the current implementation (github) is not enough to handle all the several cases we have, but is for sure a point of start from which go ahead. Can be implemented an Adapter interface that implements a set of functions useful for exposing other adapters besides github. Or just another adapter to cover all the needs that can be a standard http adapter with more or less the same convention of github (several files .keys , each for every user ssh), this could match easier the needs of some network constraints that we could need to handle. Besides this, i genuinely suggest to start making a demo of the current work (and merge it) and in the meanwhile proposing for something that could extend the logic. Otherwise the possible risk i feel, is to procrastinate these kind of discussions to a never free tomorrow day that will never exist. These are my 2 cents!

phisco commented 4 years ago

@jnardiello surely this is not a high priority feature, but given that we have moved from a single ssh key per infra repo to using our own keys, that the only way is to inject them is via ansible and given that terraform requires to recreate ec2 instances or rollout a new launch configuration if nodes are handled by an ASG, we definitely need to address this issue. It is needed to have the autojoin fully functioning.

Has to be said that environments in which external network connectivity is an issue usually do not require autoscaling neither, therefore I see no problem at all in merging it.

As I've already said @lzecca78, hardcoding the reference to github is surely not a good idea, I'd rather leave a generic url field from which furyagent could download the public key of a user. I still have to fully understand the adapter field you've introduced. If you could provide an example of the updated structure it would be helpful.

angelbarrera92 commented 4 years ago

@jnardiello surely this is not a high priority feature, but given that we have moved from a single ssh key per infra repo to using our own keys, that the only way is to inject them is via ansible and given that terraform requires to recreate ec2 instances or rollout a new launch configuration if nodes are handled by an ASG, we definitely need to address this issue. It is needed to have the autojoin fully functioning.

Has to be said that environments in which external network connectivity is an issue usually do not require autoscaling neither, therefore I see no problem at all in merging it.

As I've already said @lzecca78, hardcoding the reference to github is surely not a good idea, I'd rather leave a generic url field from which furyagent could download the public key of a user. I still have to fully understand the adapter field you've introduced. If you could provide an example of the updated structure it would be helpful.

I will add it in the product trello dashboard as it has to be addressed with some kind of priority

lzecca78 commented 4 years ago

@phisco right, but in the latest implementation, i moved the hardcoding github in the code, leaving the possibility to customize the url . Giving the following example of furyagent.yml:

---
storage:
  provider: s3
  url: 'http://s3-eu-west-1.amazonaws.com'
  aws_access_key: 'AKIA12345'
  aws_secret_key: '12345678'
  bucketName: 'test'
  region: 'eu-west-1'
clusterComponent:
  sshKeys:
    adapter:
      name: 'github'
    user: 'sighup'
    tempDir: '/tmp'
    localDirConfigs: 'secrets/ssh'

and given the file ssh-users.yml:

users:
  - name: luca
    user_id: lzecca78
  - name: philippe
    user_id: phisco
  - name: samuele
    user_id: nutellinoit
  - name: lucanovara
    user_id: lnovara

the effect of the run is :

/vagrant/bin/linux/furyagent --config /vagrant/ssh/furyagent.yml configure ssh-keys --overwrite=true
2020-01-23 20:34:14.595177 I | storage.go:133: Item ssh/ssh-users.yml found [size: 229]
2020-01-23 20:34:14.596437 I | storage.go:134: Saving item ssh/ssh-users.yml ...
2020-01-23 20:34:14.656481 I | ssh.go:168: loading spec file /tmp/ssh-users.yml
2020-01-23 20:34:14.658600 I | ssh.go:88: loading public keys for user lzecca78
2020-01-23 20:34:15.028086 I | ssh.go:207: writing ssh keys for user luca
2020-01-23 20:34:15.028762 I | ssh.go:88: loading public keys for user phisco
2020-01-23 20:34:15.162703 I | ssh.go:207: writing ssh keys for user philippe
2020-01-23 20:34:15.163130 I | ssh.go:88: loading public keys for user nutellinoit
2020-01-23 20:34:15.424154 I | ssh.go:207: writing ssh keys for user samuele
2020-01-23 20:34:15.424528 I | ssh.go:88: loading public keys for user lnovara
2020-01-23 20:34:15.572920 I | ssh.go:207: writing ssh keys for user lucanovara
2020-01-23 20:34:15.576691 I | ssh.go:269: the user sighup is missing, creating it
2020-01-23 20:34:15.577295 I | ssh.go:246: os identified is ubuntu:
2020-01-23 20:34:15.577904 I | ssh.go:272: executing command:  /usr/sbin/adduser --home /home/sighup --disabled-password sighup
2020-01-23 20:34:15.848191 I | ssh.go:276: Adding user `sighup' ...
Adding new group `sighup' (1002) ...
Adding new user `sighup' (1002) with group `sighup' ...
Creating home directory `/home/sighup' ...
Copying files from `/etc/skel' ...
Changing the user information for sighup
Enter the new value, or press ENTER for the default
    Full Name []:   Room Number []:     Work Phone []:  Home Phone []:  Other []: Is the information correct? [Y/n]
2020-01-23 20:34:15.849513 I | ssh.go:298: the /home/sighup/.ssh is missing, creating it
2020-01-23 20:34:15.849589 I | ssh.go:112: creating temporary authorizedKeys file /home/sighup/.ssh/authorized_keys_tmp
2020-01-23 20:34:15.849647 I | ssh.go:131: everything is fine! Writing temp file /home/sighup/.ssh/authorized_keys_tmp to its final destination /home/sighup/.ssh/authorized_keys

so, the actions are :

fetch the ssh-users.yml from s3 bucket
get the adapter from furyagent.yml (github doesn't require uri, because is well known, http require also a uri field to be put in the adapter struct )
once get the adapter (name, uri) it will fetch from it the same github structure: so 1 file.keys for each user
create the system user checking on which os is launched (redhat bases, debian based) in order to use the correct command flags
create a temporary authorized_keys
if the step 3 goes well, it will override the authorized_keys file of the user, otherwise it won't

of course the steps 4 is be ignored if the user already exists

angelbarrera92 commented 4 years ago

Amazing work. As i said before, i want to see a demo/workshop about it ;) Thanks

lzecca78 commented 4 years ago

@angelbarrera92 i try to setup a calendar this week for the demo 🤞

lzecca78 commented 4 years ago

can we go ahead with this, or is missing anything ?

sighupio / furyagent

Add ssh keys capability to furyagent #7