[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]
Arnold de Leon a-conserver@deleons.com
Wed, 26 Jul 2006 09:07:26 -0700 (PDT)
On Tue, 25 Jul 2006, Bryan Stansell wrote:[script deleted]
> 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:
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:
Maintaining the links would probably need another script. Console name completion is broken but power conserver user can always type:
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:
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.