search

bastillion-io / Bastillion

Bastillion is a web-based SSH console that centrally manages administrative access to systems. Web-based administration is combined with management and distribution of user's public SSH keys.
https://www.bastillion.io
Other
3.17k stars 379 forks source link

SSH Fingerprints #27

Open iakat opened 9 years ago

iakat commented 9 years ago

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

nox-do commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 https://github.com/skavanagh/KeyBox/issues/27#issuecomment-68640600.

iakat commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 https://github.com/skavanagh/KeyBox/issues/27#issuecomment-69009825.