[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]
Zonker consoleteam@gmail.com
Mon, 21 Apr 2014 23:15:04 GMT
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.thanksBrandon--On Mon, Apr 21, 2014 at 3:37 PM, Zonker <consoleteam@gmail.com> wrote:
Try thinking of authentication in the following model...
1) A secure connection from the Conserver host to the console server(s).(Management net, maybe static routes instead of defaults, SSH if needed)
- Conserver opens a conenction for every configured port, and starts logging.2) User access to the console sessions.- Maybe the SSH to the conserver, or they have a console client on their host
- Users "connect" to a given console session... conserver "tees" them in.( User types, data goes to the console... device sends data back, conserver logs it and forwards the data to the user.)In this model, only Conserver would need to know how to log into the console server. (I make sure my console servers only allow one connection per serial port in the reverse-TCP mode. This way, if anyone else know how to access that port and has the credentials, they would be unable to connect of Conserver got their first.
Also in this model, users would authenticate on Conserver... either by SSH to the Conserver host, or with their own conserver client. In the latter case, the client users need to validate with conserver when they make the connection, and this would be checked in the conserver.passwd file.
It's been a great model for many types of administration. But, if it's not for you, perhaps you can share what make your scenario different/difficult?
Best regards,You may find a couple of my older LISA tutorials useful, and you can find them at
http://www.conserver.com/consoles/Training/published.htmlOn Mon, Apr 21, 2014 at 2:13 PM, Brandon Stout <bstout@squareup.com> wrote:
Hey Z,This all makes sense, thanks for the info. From an conserver.passwd perspective, is the location and usage of the file need to be called out in the conserver.cf file or should it automatically use it for authentication? Right now I have it working being authenticated by the Opengear but want to test to see if I can get it working using this file. Is there something I needed to do to get conserver to use the file?thanksBrandon--On Mon, Apr 21, 2014 at 1:35 PM, Zonker <consoleteam@gmail.com> wrote:
Chris Ross is correct... The model of conserver connecting (and then trying to maintain connection) is built around the model that a sysadmin wants to capture any messages that a console may cough up (memory error at 0x23484325, root volume at 98%, core dumped, etc.), so that when a system fails to respond on the network, and you try to use the console only to find it unresponsive... THEN is when we are glad that we can tail the log file for that device, and see what was happening! :-)
Once we see the problem, we can then grep the logs for similar machines, and see if we see any of the early signs of pending failure on similar devices in our collection. :-)
Using ssh is a way to encrypt the data between the console server and the conserver host. But, as you scale up (think many dozens of console servers, and thousands of ports), consider that SSH on each of those connections is a lot more overhead. Many shops use a dedicated management subnet and use the telnet option instead.
The conserver.passwd is a good option when you want to give someone console access, but not give them shell access on your NIS network. By giving them an account local to your conserver host, and using the local password file, they can access consoles, and no more.
In one case, where I needed to give contractors access to *some* consoles, I installed conserver where the contractors had access (rather than letting them have access to my primary logs), and had this conserver.passwd;
cat /usr/local/etc/conserver.passwd
# Users can either have a pre-defined account name here,
# or they can refer to an existing shell account...
# for Shell accounts, "*passwd*" means to use their shell passwd
# Or, you can enforce a pre-assigned password, by adding a crypted string
# (this bypasses the shell passwd, forcing them to use the console passwd)
# perl -e 'print crypt("password","Ah")."\n";'
# The "Ah" picks the first two characters of the password, and is the "salt"
# used for the crypt...
root:
temp_FE:ceOfgr9fefOqNw
# Contractor users must come to their consoles from a CLUSTER_HOST
v-prtent:*passwd*
v-boulder:*passwd*
*any*:*passwd*Also, "temp_FE" was an account when they needed someone more random to come in and work on the devices, and we could change that password at will.
Best regards,-Z-
On Mon, Apr 21, 2014 at 12:25 PM, Brandon Stout <bstout@squareup.com> wrote:
Thanks for the reply Chris. You are correct, it is not using the local/conserver password but just the console server (opengear) password. I actually don't really care which password to use, as long as it asks for a password anytime someone wants to connect to a console port. It works correctly if you just ssh to the console via port 30xx. But when using conserver, it just asks once and that is it. Looking at the logs, it looks like it conserver tries to login to every port preemptively and keep it open as opposed to just opening a session when someone asks for it. Is there a way to change this behavior?--On Mon, Apr 21, 2014 at 12:13 PM, Chris Ross <cross+conserver@distal.com> wrote:
“Your milage may vary”, but for myself, I’m consoling UNIX servers, so I want their console output to be logged even when noone is connected. To accomplish this, I have a script that will log into the session for me upon initialization of the console, and then stay attached. As you’ve determined, conserver leaves the TCP connection active, so you don’t need to authenticate against the ssh connection again after the initial connection.
I suspect you’re not getting it to use the local/conserver password at all, or else when you first start up, you’d have to enter both, in the correct sequence. One to connect to the established ssh command, then another to ssh to authenticate the network connection.
So, I guess you need to decide whether you want to have the connection drop and reestablish, which is what you seemed to be asking for, or rather want just to get the conserver password prompting working, which I’m not doing, so can’t help with directly.
Thoughts and information that I hope is helpful.
- Chris
On Apr 21, 2014, at 14:38, Brandon Stout <bstout@squareup.com> wrote:
> Also, how does the conserver.passwd work? When does it use that rather than the authentication on the Opengear itself? To test, I have the same user on the Opengear as well as in the conserver.passwd with different passwords to see where it gets its passwords from. So far it just looks like it is using the password from the Opengear. I configured conserver with all the defaults so I am assuming conserver.passwd just needs to exist within the same directory as conserver.cf. Did I configure something incorrectly or does there need to be a line in the conserver.cf file to point to where conserver.passwd exists?
>
>
> On Mon, Apr 21, 2014 at 11:32 AM, Brandon Stout <bstout@squareup.com> wrote:
> So I actually figured out the problem so now it connects, I get the password prompt and when I enter it correctly it works. The problem is that when I disconnect and reconnect, it no longer asks me for a password and just puts me through to the console. is there some sort of disconnect I need to do manually to get it to reset and ask for a password? Seems like it just stays connected once the pw is entered, regardless of someone exiting.
>
>
> On Mon, Apr 21, 2014 at 11:26 AM, Brandon Stout <bstout@squareup.com> wrote:
> thanks Nathan, I actually was trying that right after I sent this email and added this
>
> default opengear-ssh { type exec; portbase 2000; portinc 1;
> exec /usr/bin/ssh -p P -l tsuser H;
> execsubst H=hs,P=Pd; }
>
> still not working though with just about nothing useful in the logs. Doesn't hang but it still doesn't work. Just empty space and no output.
>
>
> On Mon, Apr 21, 2014 at 10:39 AM, Nathan Straz <nstraz@redhat.com> wrote:
> On Apr 21 10:29, Brandon Stout wrote:
> > hello, I am trying to use conserver to connect to serial ports over ssh and
> > it is hanging. When I go direct it works fine (i am using Opengear IMX4248):
> >
> > [bstout@lab etc]$ ssh root@172.24.19.40 -p 3002
> ...
> > default full { rw *; }
> > default opengear { type host; portbase 3000; portinc 1; }
> > default * {
> > logfile /var/log/conserver;
> > timestamp 1hab;
> > include full;
> > master localhost;
> > }
> > default console01 { include opengear; host console01; }
> > console dr01.arista { include console01; port 1; }
> > console dr02.arista { include console01; port 2; }
> ...
> > Has anyone gotten this to work using ssh?
>
> I think you need to use the exec host type and setup the right execsubst
> to get ssh to use the right port number. The "host" type is just a raw
> TCP socket connection.
>
> Nate
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users
>
>
>
> --
>
> brandon
>
>
>
> --
>
> brandon
>
>
>
> --
>
> brandon
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users
brandon
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
--Sent from my new iPhone 6 Watch (prototype), see my reviews here!
www.conserver.com/consoles/ -- consoleteam.blogspot.com
- - - - - - - -
www.ncry.org
www.d4tm.org
www.hackerdojo.combrandon
--Sent from my new iPhone 6 Watch (prototype), see my reviews here!
www.conserver.com/consoles/ -- consoleteam.blogspot.com
- - - - - - - -
www.ncry.org
www.d4tm.org
www.hackerdojo.combrandon