bostjan at a2o
Aug 29, 2011, 8:50 AM
Post #1 of 2
(216 views)
Permalink
|
|
Auth forwarding socket for single auth
|
|
Hi all,
authentication forwarding depends much on the environment it is used
in, but generally on shared hosts it is considered insecure, as this
documentation and common sense tell us:
http://unixwiz.net/techtips/ssh-agent-forwarding.html
Anyway, I have an auth forwarding security enhancement proposal. I
hope I am not duplicating someone else's words/thoughts, please notify
me if this is the case.
How about if we make the auth socket configurable in such way, that it
can be used for just SINGLE authentication, and then it gets closed
automatically?
Let me illustrate host sequence:
MyHost ---> IntermediateHost ---> FinalHost
------------------------------------------------
a) Usual session initialization flow:
------------------------------------------------
a.1 On MyHost, I execute:
- $ ssh IntermediateHost -A
- (this connects me to intermediate host and creates /tmp/ssh-...
socket for authentication forwarding)
a.2 Once on Intermediate host, I execute:
- $ ssh FinalHost
- (this gets me to final host with authentication via auth socket
which leads back to MyHost)
a.3 I do things on the FinalHost, but socket is still open op intermediate host
------------------------------------------------
b) Proposed session initialization flow:
------------------------------------------------
b.1
- $ ssh IntermediateHost -A --auth-single
- (--auth-single is made up)
b.2
- $ ssh FinalHost
- (As soon as 1 auth try is consumed (does not matter whether it fails
or succeeds) socket gets closed.)
b.3 I do things on FinalHost, BUT auth socket does not exist anymore
on Intermediate Host
------------------------------------------------
c) Speedup of proposed flow:
------------------------------------------------
c.1
- $ ssh IntermediateHost -A --auth-single -t "ssh FinalHost"
Annotations to proposed (b and c) flows:
- I understand that in example b) for a limited timeframe there is
still insecure socket available at Intermediate host, which can be
exploited by powerful-enough user on intermediate host
- In example c) this timeframe gets really down to minimum, which
leaves this scheme vulnerable only to a really dedicated and
determined cracker, but it should be admin's decision whether he wants
to use this or not in systems which can't afford such risk.
Please comment on this "proposal".
Best regards,
b.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
|
