Mailing List Archive

hmm...well, that's kinda tricky. the issue is that there are multiple
conserver process that the client talks to (the master, then the actual
one managing the console - in the simplest form). the client actually
caches the password so that it can re-authenticate with the extra
processes without harassing the user. in your case, you should be
getting multiple password requests, right? you'd authenticate with the
first, conserver would try and re-use the password with the second,
fail, and then ask for the current password.

removing the need for multiple passwords *might* be possible. i could
see removing the need for authenticating against the master
process...just have it skip password stuff (which means removing a few
lines of code) and let the user authenticate once against the process
managing the console. this would allow folks to gather data...so not
something i'd do for the general release (well, maybe as an option), but
you may not like that either.

another possibility is to setup a "console" host that does nothing but
allow folks to access conserver (it could even be the same box). when a
user logs in, instead of a shell, you get a console command that
attaches to some pre-determined console. how does this help? well, you
turn off all authentication in conserver and can assume that anyone
attaching has already authenticated with the host, so they should be who
they say they are. and, actually, you could create a "noop" console
that they all fall into by default, and then they just need to use
"^ec;" to switch to another console. kinda different, but doable, in my
opinion. it's not a 100% solution, but it's close (in addition i'd say
they should all be "limited" users (in conserver.cf terms), but then you
wouldn't be able to switch consoles).

aside from that, i'm not sure what else to offer.

Bryan

On Fri, Jul 21, 2006 at 08:28:16AM -0400, Josh Lothian wrote:
> We're using RSA SecurID fobs here for all sorts of authentication. We'd
> like to use them with conserver via PAM. However, looking at the logs,
> it seems like conserver is trying to authenticate twice in quick
> succession. The first one succeeds, but the second one fails - hence
> the "one time" password. Any way to disable this?
>
> -jkl
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

How does SecureID work with conserver? Does the console client ask for
the number on the card?

On Sun, 2006-07-23 at 09:03 -0700, Bryan Stansell wrote:
> hmm...well, that's kinda tricky. the issue is that there are multiple
> conserver process that the client talks to (the master, then the actual
> one managing the console - in the simplest form). the client actually
> caches the password so that it can re-authenticate with the extra
> processes without harassing the user. in your case, you should be
> getting multiple password requests, right? you'd authenticate with the
> first, conserver would try and re-use the password with the second,
> fail, and then ask for the current password.
>
> removing the need for multiple passwords *might* be possible. i could
> see removing the need for authenticating against the master
> process...just have it skip password stuff (which means removing a few
> lines of code) and let the user authenticate once against the process
> managing the console. this would allow folks to gather data...so not
> something i'd do for the general release (well, maybe as an option), but
> you may not like that either.
>
> another possibility is to setup a "console" host that does nothing but
> allow folks to access conserver (it could even be the same box). when a
> user logs in, instead of a shell, you get a console command that
> attaches to some pre-determined console. how does this help? well, you
> turn off all authentication in conserver and can assume that anyone
> attaching has already authenticated with the host, so they should be who
> they say they are. and, actually, you could create a "noop" console
> that they all fall into by default, and then they just need to use
> "^ec;" to switch to another console. kinda different, but doable, in my
> opinion. it's not a 100% solution, but it's close (in addition i'd say
> they should all be "limited" users (in conserver.cf terms), but then you
> wouldn't be able to switch consoles).
>
> aside from that, i'm not sure what else to offer.
>
> Bryan
>
> On Fri, Jul 21, 2006 at 08:28:16AM -0400, Josh Lothian wrote:
> > We're using RSA SecurID fobs here for all sorts of authentication. We'd
> > like to use them with conserver via PAM. However, looking at the logs,
> > it seems like conserver is trying to authenticate twice in quick
> > succession. The first one succeeds, but the second one fails - hence
> > the "one time" password. Any way to disable this?
> >
> > -jkl
> > _______________________________________________
> > users mailing list
> > users@conserver.com
> > https://www.conserver.com/mailman/listinfo/users
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users

_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

On Sun, Jul 23, 2006 at 09:03:34AM -0700, Bryan Stansell wrote:
> hmm...well, that's kinda tricky. the issue is that there are multiple
> conserver process that the client talks to (the master, then the actual
> one managing the console - in the simplest form). the client actually
> caches the password so that it can re-authenticate with the extra
> processes without harassing the user. in your case, you should be
> getting multiple password requests, right? you'd authenticate with the
> first, conserver would try and re-use the password with the second,
> fail, and then ask for the current password.

yep, exactly.

> removing the need for multiple passwords *might* be possible. i could
> see removing the need for authenticating against the master
> process...just have it skip password stuff (which means removing a few
> lines of code) and let the user authenticate once against the process
> managing the console. this would allow folks to gather data...so not
> something i'd do for the general release (well, maybe as an option), but
> you may not like that either.

What sort of data could they gather?

> another possibility is to setup a "console" host that does nothing but
> allow folks to access conserver (it could even be the same box). when a
> user logs in, instead of a shell, you get a console command that
> attaches to some pre-determined console. how does this help? well, you
> turn off all authentication in conserver and can assume that anyone
> attaching has already authenticated with the host, so they should be who
> they say they are. and, actually, you could create a "noop" console
> that they all fall into by default, and then they just need to use
> "^ec;" to switch to another console. kinda different, but doable, in my
> opinion. it's not a 100% solution, but it's close (in addition i'd say
> they should all be "limited" users (in conserver.cf terms), but then you
> wouldn't be able to switch consoles).

This is kinda what we have going currently, but it's not ideal. People
other than our admin staff have access to the conserver host. Some of
the admins would also like to not have to log in to that host and
instead use the conserver client from their desktop.
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

On Tue, Jul 25, 2006 at 09:13:57AM -0400, Josh Lothian wrote:
> > removing the need for multiple passwords *might* be possible. i could
> > see removing the need for authenticating against the master
> > process...just have it skip password stuff (which means removing a few
> > lines of code) and let the user authenticate once against the process
> > managing the console. this would allow folks to gather data...so not
> > something i'd do for the general release (well, maybe as an option), but
> > you may not like that either.
>
> What sort of data could they gather?

well, the port numbers of the sub-processes, the list of conserver
hosts, the pid, and version. you also wouldn't be able to restart,
reload, quit, etc since no authentication had been done (using the
client...you could always send the signals).

> This is kinda what we have going currently, but it's not ideal. People
> other than our admin staff have access to the conserver host. Some of
> the admins would also like to not have to log in to that host and
> instead use the conserver client from their desktop.

well, i'm out of ideas for now. having conserver send the client some
sort of "token" that allows you in without authentication might be
necessary...but then you might as well just tell securid to grant every
number a 2 second, multi-use window. neither are secure. if you're
using ssl to encrypt things, at least you'd be fairly sure no one could
pick the data off the line and then use it to gain access. but that
doesn't make me feel much better.

i'm beginning to believe there isn't really any nice way to handle this
without conserver being rewritten to be a single-process (threaded?)
system...and that too has it's challenges.

anyone out there good at thinking outside the box? ;-)

Bryan
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

On Tue, 25 Jul 2006, Bryan Stansell wrote:

> anyone out there good at thinking outside the box? ;-)

While I don't need one-time passwords, I did want secure access to my
conserver without having to enter passwords. My solution was to restrict
accesst to conserver to only the local machine running conserver (i.e.
only loopback allowed to connected), but trust usernames and not require
passwords. Then to access the machine I use per-user SSH accounts, with
public keys on the conserver machine, and private keys plus ssh-agent on
the end-user machine. The conserver config excerpt is something like this:

-------------------------------------------------------------------------
# Establish access control.
access * {
# Only allow connections from this machine.
trusted localhost,console;
}
-------------------------------------------------------------------------

To avoid the annoyance factor of having to 'ssh' and then 'console', I
wrote the following shell script for the end-user machines, named
/usr/local/bin/console:

--------------------------------------------------------------------------
#!/bin/bash

# Open a psuedo terminal with SSH on the console server and run console
# there.
ssh -t farstar console $*
--------------------------------------------------------------------------

Where 'farstar' is the hostname of the conserver machine. This passes all
parameters to console on that machine, and pretty much makes the SSH
connection transparent. Only if you are trying to do some advanced
piping/scripting/local file access with the console client does it break
down.

As an added bonus, the console session, as it passes over the network, is
encrypted like any SSH shell session. And using PAM, any desired
authentication method could be used in place of SSH's private/public keys.

For multiple system conservers, you can configure the other machines to
only accept console connections from the master server that the end-user
will SSH into. Though be aware that the console session from the master to
the other server is not encrypted (unless conserver SSL is enabled).

Hopefully this will be of use or at least provide ideas. TTYL.

---------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
---------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---------------------------------------------------------------------------

_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

On 7/26/06, Ryan Kirkpatrick <linux@rkirkpat.net> wrote:
> On Tue, 25 Jul 2006, Bryan Stansell wrote:
>
> > anyone out there good at thinking outside the box? ;-)
>
> While I don't need one-time passwords, I did want secure access to my
> conserver without having to enter passwords. My solution was to restrict
> accesst to conserver to only the local machine running conserver (i.e.
> only loopback allowed to connected), but trust usernames and not require
> passwords. Then to access the machine I use per-user SSH accounts, with
> public keys on the conserver machine, and private keys plus ssh-agent on
> the end-user machine. The conserver config excerpt is something like this:
>
> -------------------------------------------------------------------------
> # Establish access control.
> access * {
> # Only allow connections from this machine.
> trusted localhost,console;
> }
> -------------------------------------------------------------------------
>
> To avoid the annoyance factor of having to 'ssh' and then 'console', I
> wrote the following shell script for the end-user machines, named
> /usr/local/bin/console:
>
[script deleted]

This is similar to how we are planning on deploying conserver. We
didn't want to have to distribute a client/script and so we are
thinking of a ways around that issue.

One idea we was to make create a script on the "conserver" master and
link each console name to it so one can type:

% ssh conserver some-machine

Maintaining the links would probably need another script. Console
name completion is broken but power conserver user can always type:

# ssh conserver console . . .

The really wild idea is to glue sshd to the conserver program and get
rid of the client all together and simply run conserver as an ssh
server. For the really smooth installation an extra IP address would
be given to the conserver master so it can listen on the default ssh
port. Then if you make the name "console" point to that IP address
you can type:

% ssh console some-machine

Just like in the previous example but it should be possible to have
conserver process the rest of the arguments so all the console client
magic can happen. We only got as far as the idea stage so there are
probably gotcha's that haven't been worked out.

[more good stuff deleted]

Out of the box enough for you Bryan? ;-)

arnold
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

Arnold de Leon <a-conserver@deleons.com> wrote:

> The really wild idea is to glue sshd to the conserver program and get
> rid of the client all together and simply run conserver as an ssh
> server. For the really smooth installation an extra IP address would
> be given to the conserver master so it can listen on the default ssh
> port. Then if you make the name "console" point to that IP address
> you can type:
>
> % ssh console some-machine

I've set up something similar to this using xinetd and telnet.

My goal was to make conserver work the same way that, for example, a
cisco 2511 with an ip aliase for each async port works. Users can
telnet to an address (usually a hostname-con the way we do it here), and
the remote server system with that address configured on it will fire up
'console' with the appropriate arguments to connect to the destination
system. Usernames are either passed through the telnet protocol, or
queried for in a little wrapper.

In my implementation, there's no security at all, and all of the
processes run as a special console user whose login shell has some of
the magic glue to pass info to console. You could probably (ab)use sshd
in a way that's similar to the way I'm using in.telnetd to provide
encryption, authentication, and username exposure.

Anyway, it seems to work well, but there are bugs and annoyances. At
the moment I have about 150 consoles set up this way, maybe 1/4 of them
in use at any given time. If you're interested, I could probably clean
things up a bit and pass it on.

Cheers,
Brian
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users