[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]
Brandon Stout bstout@squareup.com
Mon, 21 Apr 2014 21:13:41 GMT
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.com