[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]

Conserver and ssh

Bryan Stansell bryan@conserver.com
Tue, 22 Apr 2014 01:12:55 GMT


It sounds like you want a subset of your unix host users to be able to access various consoles. It also sounds like you may not have authentication at the conserver layer (for users) enabled yet. 

Conserver has many options to enable pretty much any (sane) scenario.  The client->conserver communication can be "trusted" (so, restricted via ip only), "allowed" (requires username/password lookup), and "rejected" (again, by ip). You can also list which users have r/w access to which consoles, which have r/o and, which have none. You can group users, include/exclude per console, etc. 

If you want to use user/pass auth, you need to make sure you have "allowed" vs "trusted" in the access section of the config. Once you get password prompts, you can either define new passwords in the conserver.passwd file or have it use the system passwords.  Users can be granted access to consoles via the "rw" and "ro" console options.

There are a set of sample config files in the source distribution which talk about various topologies as well as options. Looking at those may help, as well as the specific keywords I called out above, and the sample files (not sure if repos include them - doubt it). 

If you describe your ideal situation, I can also help form a config template that should do what you want.  Personally, I like having conserver attach to all consoles so you have an audit log at all times and control access via the "allowed" keyword and setting up access lists per console with "rw".  If you grant folks access via the network (console client on other hosts), they don't even need real accounts on your conserver host - just create them in conserver.password.  Not that it fits your use case, but just wanted to call it out. Oh, and if you really want to know who is who, you can use SSL between the client and sever, requiring the user to have been given a signed cert - takes more setup, but possible. 

Anyway, I hope this helps. Bottom line, whatever you'd like to see as far as authentication and access control is probably possible. Don't settle for something you don't really want - I (or someone on the list) can help steer you down the right path. Hopefully I already did, but if not, let me know (by example?) what you'd like to see and I can help. 

Bryan

> On Apr 21, 2014, at 3:57 PM, Brandon Stout <bstout@squareup.com> wrote:
> 
> Hey Z,
> 
> This is starting to make a lot more sense. Thanks for the email. It sounds like I may not be able to use it exactly how I wanted to but I can get by with local user/pw on the console server if this is the case. I am using the conserver as both conserver host and conserver client, by which a user will logon to this host to gain console access only to console servers configured locally (nothing distributed). The server is also used for other functions so other users have access to the box who I don't want to have access to the consoles. I was trying to control access via conserver.passwd but it sounds like that is only used for conserver clients outside of the conserver. It seems as though I will just need to create individual accounts on the console server itself and control access there. 
> 
> thanks
> Brandon
>