Good procedure?

[Stef Bon]

Op di 21 aug. 2018 om 15:11 schreef Alexander Wuerstlein <arw at cs.fau.de>:
>

> There are huge differences to what you described. First, Uber uses just
> SSH, you mentioned e.g. internet access or print services which aren't
> easily SSH-tunneled without tons of headaches.

I know kerberos, but I think the use of public and private keys is teh
future, and kerberos is the past.
And pk auth is the basic method for ssh.
By the way forwarding of traffic via a dedicated channel is easy. I've
written my own bfileserver for this purpose, which listens to a locl
socket, and clients can connect using the direct streamlocal method
developed by openssh.

So what's so difficult. Maybe good to know I've written my own ssh
library, cause I needed integration with fuse others cannot provide.

See:

https://github.com/stefbon/fs-workspace
https://github.com/stefbon/bfileserver


>
> Second, the article describes an automatic SSH-CA for longer-lived keys,
> e.g. "If an employee loses access (e.g. they leave the company)". What
> you describe is intended as per-session-keys, which has another ton of
> headaches, because of short expiry periods and frequent key changes.
> It's doable, but not very easily, because sessions start and end all the
> time, and their expiry isn't just given by an expiry date in the
> SSH-Certificate (decentrally checked by each sshd) but by the user
> exiting the session (centrally signalled to the magic session db and
> then read/polled/waited for by all services using the session).
>

key changes are handled by the system, just like kerberos does. I do
not see what's so
difficult about it.

> Also, authentication is just performed using the SSH-key in Uber's case,
> you intend to pass around the password as well which is a really bad
> idea. Passwords should never be cached, remembered or passed around,
> decades of experience show that this will only lead to compromise.
>

Stef