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

SSH Fingerprints #27

Open
iakat opened this issue Jan 1, 2015 · 8 comments
Open

SSH Fingerprints #27

iakat opened this issue Jan 1, 2015 · 8 comments

Comments

@iakat
Copy link
Contributor

iakat commented Jan 1, 2015

As far as I see, KeyBox does not save and check SSH fingerprints.
This would be a really nice addition.

@nox-do
Copy link

nox-do commented Jan 1, 2015

I agree to Simone. A check and warning if the fingerprint (or so far the
server) was requested by some users here also.

Am 01.01.2015 06:29 schrieb "Simone" notifications@github.com:

As far as I see, KeyBox does not save and check SSH fingerprints.
This would be a really nice addition.


Reply to this email directly or view it on GitHub.

@skavanagh
Copy link
Collaborator

Kind of fuzzy on how this could work since this is SSL/TLS stacked on top of SSH. Users authenticate to KeyBox, then KeyBox authenticates to the servers with its SSH key. In the case of SSL/TLS, certificates are the mechanism used to validate authenticity (which it is a good idea to purchase or generate your own cert). StrictHostChecking couldn't be turned on between users and the host itself. Maybe it could work between KeyBox and the host, but there would have to be a way to resolve if the fingerprint doesn't match.

@nox-do
Copy link

nox-do commented Jan 4, 2015

I just thought about the integrity check between keybox and the configured
hosts. That is the connection that needs to be validated. so far keybox
then ensures the host connection and SSL/TLS ensures integrity of the
client session.
Am 04.01.2015 18:20 schrieb "Sean Kavanagh" notifications@github.com:

Kind of fuzzy on how this could work since this is SSL/TLS stacked on top
of SSH. Users authenticate to KeyBox, then KeyBox authenticates to the
servers with its SSH key. In the case of SSL/TLS, certificates are the
mechanism used to validate authenticity (which it is a good idea to
purchase or generate your own cert). StrictHostChecking couldn't be turned
on between users and the host itself. Maybe it could work between KeyBox
and the host, but there would have to be a way to resolve if the
fingerprint doesn't match.


Reply to this email directly or view it on GitHub
#27 (comment).

@iakat
Copy link
Contributor Author

iakat commented Jan 7, 2015

I just thought about the integrity check between keybox and the configured
hosts.

That is what I was referring to, as well.
It's obvious a CA signed SSL/TLS certificate is needed to guarantee legitimacy on the HTTP side.

@skavanagh
Copy link
Collaborator

Right, but if the fingerprint doesn't match how is that resolved? and what happens in the meantime? are users locked out from accessing the host with the fingerprint mismatch?

@iakat
Copy link
Contributor Author

iakat commented Jan 7, 2015

If the fingerprint doesn't match, the way to resolve it could be either inputting the new fingerprint, or deleting the current one for the host.
This could be either possible for every user, or admins only.

@skavanagh
Copy link
Collaborator

Yeah, I was kind of thinking it should only be something an admin could do. b/c you wouldn't want just a regular user verify the host is authentic for all the other users.

@nox-do
Copy link

nox-do commented Jan 7, 2015

I agree to Simone. Only an admin should be able to accept a changed host.
There are might be users that have hosts changed quite often (eg. during
development for provisioning test and re-install) but keeping the domain
name. I suggest to make the "CheckHostFingeprint" configurable as an
option, default == true. So far, yes, users should be locked out until the
problem is solved. But it would be nice to let the users know WHY they
can't connect :-)

2015-01-07 12:26 GMT+01:00 Sean Kavanagh notifications@github.com:

Yeah, I was kind of thinking it should only be something an admin could
do. b/c you wouldn't want just a regular user verify the host is authentic
for all the other users.


Reply to this email directly or view it on GitHub
#27 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants