1 |
On 18/10/2013 04:30, Walter Dnes wrote: |
2 |
> On Thu, Oct 17, 2013 at 08:59:15AM +0200, Alan McKinnon wrote |
3 |
> |
4 |
>> Accessing the actual backend network is a two stage process: ssh key to |
5 |
>> the jump host, then password to get onto the actual destination. |
6 |
>> |
7 |
>> So it's "two factor" as a generic English language phrase, not "two |
8 |
>> factor" as a technical description of an exact thing. Keep in mind that |
9 |
>> English is a highly overloaded language :-) |
10 |
> |
11 |
> I apologize. That is arguably a two factor system. When you said |
12 |
> "ssh key and password", I "jumped to delusions", assuming that it was a |
13 |
> standard ssh connection with the option of either key or password. Does |
14 |
> the jump host restrict you to logging on to the account corresponding to |
15 |
> the key? I.e. would John Smith got to the jump host with his key, could |
16 |
> he log in to the Jane Doe account, or only John Smith. |
17 |
|
18 |
|
19 |
I built it myself, so I done did it rite :-) |
20 |
|
21 |
It's very much one key to one user and the only jump host the general |
22 |
user (i.e. customer support) can use is the main advertised one. |
23 |
Infrastructure people and my friends in NetOps have other ways of |
24 |
getting into the network but those are very restricted access. |
25 |
|
26 |
When building this, we found something interesting - dudes were sharing |
27 |
keys. The mind boggles as to why anyone thought this a good idea but |
28 |
that's what they were doing. I suspect some people found ssh-keygen |
29 |
and/or PuTTY too difficult to wrap their wits around. |
30 |
|
31 |
But the fix was simple - with 700+ users and 250+ hosts to manage, we do |
32 |
user deployment centrally with no way to bypass it. The database field |
33 |
containing the public key string was given a unique index. No more |
34 |
duplicate keys :-) |
35 |
|
36 |
|
37 |
-- |
38 |
Alan McKinnon |
39 |
alan.mckinnon@×××××.com |