document ssh github action about dailybuild-2_0 HOT 7 CLOSED

Working on it.
Might make a separate github action (marketplace) for it that could be re-used, at least to setup the ssh stuff, maybe for SCP and SSH too.

pipeline_docs

Here is the table, completed:

Note that you obviously SHOULDN'T use that exact example key.

inspiration

There was no inspiration: I based myself off the official documentation for GitHub Actions, as well as my knowledge and previous experience with SSH.
Obviously some trial and error was also present, e.g. using -q as an option.

from dailybuild-2_0.

im gonna close this
if you want to change more stuff, that would be cool :)

thanks for your time!!

from dailybuild-2_0.

is that your inspiration ? https://blog.benoitblanchon.fr/github-action-run-ssh-commands/

from dailybuild-2_0.

@socraticDevBlog said:

you can create a new pipeline_docs.md file at root

Wouldn't it be better to make a doc or docs directory that could be used for this and future documentation, instead of putting it directly at root?

from dailybuild-2_0.

@socraticDevBlog said:

you can create a new pipeline_docs.md file at root

Wouldn't it be better to make a doc or docs directory that could be used for this and future documentation, instead of putting it directly at root?

either, but yeah, as soon there will be more than one docs file, we need a /docs directory ;)

from dailybuild-2_0.

SSH_DEPLOY_HOST_KEY

this variable is concatenation of HOSTNAME, encryption protocol and public key

since secret variables are free, we could have those 3 separate secret variables, and concatenate them in the CI. no??

• HOSTNAME
• ENCRYPTION_PROTOCOL
• CLIENT_PUBLIC_KEY or SERVER_PUBLIC_KEY
• USERNAME (instead of SSH_DEPLOY_DESTINATION, we would concatenate USERNAME @ HOSTNAME in ci code)

what do u think?

from dailybuild-2_0.

since secret variables are free, we could have those 3 separate secret variables, and concatenate them in the CI. no??

While I might partially agree with HOSTNAME and USERNAME, I do not entirely agree with separating the key type (ENCRYPTION_PROTOCOL) and base64 key(CLIENT_PUBLIC_KEY or SERVER_PUBLIC_KEY), as those are inherently connected, and it might lead to more problems than it would solve.
You could even argue that the key changes from host to host, from server to server, and copying private host keys from server to server over the network is bad practice.

The actual (accepted) format can also much more complex than the example I gave in the table earlier. See the following section.

known hosts format

Note the format also comes from the output of ssh-keyscan, and is documented in section 8 of the sshd manual.

Shortened Extract:

SSH_KNOWN_HOSTS FILE FORMAT
     The /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts files contain host public keys for all known hosts.

     Each line in these files contains the following fields: marker (optional), hostnames, keytype, base64-encoded key, comment.  The fields are separated by spaces.

     An example ssh_known_hosts file:

        # Comments allowed at start of line
        closenet,...,192.0.2.53 1024 37 159...93 closenet.example.net
        cvs.example.net,192.0.2.10 ssh-rsa AAAA1234.....=
        # A hashed hostname
        |1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa
        AAAA1234.....=
        # A revoked key
        @revoked * ssh-rsa AAAAB5W...
        # A CA key, accepted for any host in *.mydomain.com or *.mydomain.org
        @cert-authority *.mydomain.org,*.mydomain.com ssh-rsa AAAAB5W...

Real life example: output of ssh-keyscan github.com:

# github.com:22 SSH-2.0-babeld-17a926d7
github.com ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==
# github.com:22 SSH-2.0-babeld-17a926d7
github.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEmKSENjQEezOmxkZMy7opKgwFB9nkt5YRrYMjNuG5N87uRgg6CLrbo5wAdT/y6v0mKV0U2w0WZ2YB/++Tpockg=
# github.com:22 SSH-2.0-babeld-17a926d7
github.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl

conclusion

I think it might be better to let the user manage that, and simply act as an "input" interface between OpenSSH and the user.

from dailybuild-2_0.