You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
first i was rejected by some fingerprints and was on the trip, yeah thats correct then lets give a new created server a known host key. therefor i know the fingerprint.
next i looked at your provider and saw that id does not have the fingerprint property, but your library easyssh-proxy has it.
so i was expecting that it gets validated, and started to fork and prepare a pull request.
upon testing i realized that by default i do not see any rejection if i use the current release.
So either my dev environment is a bit stuck, or i would count this as something i would like to see documented and maybe implemented.
if its expected than i would propose to document and implement it as extra layer.
My usecase here is that many things that be created are not in my ssh-config/known hosts.
For my deployments its encrypted next to the project. as im working on this in a bigger company, more people than me need to have access to this or need to try out new configurations in an new and different environment. it would make thinks more complicated if we have to track this with our own agents or concat ssh-config files instead of a passing things bundled.
something is wierd about github currently so i could only push the changes to a fork i created, but cannot adapt the changes for the docs. have a look if you like
The text was updated successfully, but these errors were encountered:
first i was rejected by some fingerprints and was on the trip, yeah thats correct then lets give a new created server a known host key. therefor i know the fingerprint.
next i looked at your provider and saw that id does not have the fingerprint property, but your library easyssh-proxy has it.
so i was expecting that it gets validated, and started to fork and prepare a pull request.
upon testing i realized that by default i do not see any rejection if i use the current release.
So either my dev environment is a bit stuck, or i would count this as something i would like to see documented and maybe implemented.
if its expected than i would propose to document and implement it as extra layer.
My usecase here is that many things that be created are not in my ssh-config/known hosts.
For my deployments its encrypted next to the project. as im working on this in a bigger company, more people than me need to have access to this or need to try out new configurations in an new and different environment. it would make thinks more complicated if we have to track this with our own agents or concat ssh-config files instead of a passing things bundled.
something is wierd about github currently so i could only push the changes to a fork i created, but cannot adapt the changes for the docs. have a look if you like
The text was updated successfully, but these errors were encountered: