On Thu, Oct 05, 2006 at 09:36:31PM -0600, Layne Fink wrote:
I stand corrected on all points but had a question about this method.
Say I am on Laptop A and ssh into my desktop at home which has all the
keya and such on it. Using the .xinitrc isn't going to do me much good
(less we get into X forwarding)..but if i have the ssh-agent/add in my
.bashrc then as soon as I login via my SSH to my desktop it would
automatically start my sessions. Should also work for all terminals I
open inside X as well, right?
The answer is... it depends. Actually I'm not really clear on what
you're trying to say. But as far as having some scripting magic to
load stuff in .bashrc, it depends on how bash is started, which means
it depends on how your terminals are configured. Whether or not bash
bothers to read .bashrc depends on whether or not it is invoked as a
login shell. If it IS, then if you want bash to read .bashrc you'll
need to tell it to do so explicitly in .bash_profile, .bash_login, or
.profile (whichever of those you use -- only the first one bash finds
will be read). Most terminal programs are configurable to launch the
shell as a login shell or not... So if you do this wrong, it won't
work.
But if you're running X on the laptop, and have agent forwarding
configured properly on both the laptop and the desktop, then this is
largely irrelevant. The desktop should have your keys loaded already
via ssh-agent which was started on the laptop. The advantage to doing
it this way is it doesn't really require any shell hackery -- it
requires just one simple command added to .xinitrc or .xsession,
depending on which is relevant to you (probably .xsession). For
example, for Linux users who want to run GNOME and log in from gdm,
their .xsession file can be as simple as:
#!/bin/bash
ssh-agent gnome-session
Normally I would advocate NOT invoking shell scripts as /bin/bash
(invoke as /bin/sh instead), except that in this case, you probably
want it to. Invoking as /bin/bash (instead of /bin/sh) causes bash to
read your .bashrc, so your X clients will all know about environment
variables you would normally set there. [See below, in brackets.]
By contrast, in order to get all your shells to know about your
ssh-agent without using the .xsession method, you'd need to do
something like redirect the output of ssh-agent to a file, and put
some junk in your .bashrc and/or .profile to make all your shells
source that file. It works, but IMO it's rather inelegant, and could
potentially allow other people to use your agent info should you
mistakenly fail to carefully protect the socket file, and the file
containing the environment files.
So yeah, I'm not a fan of that method. But so long as you're careful,
there's nothing wrong with it either. And if you don't use X at all,
then obviously you need to go the other route. ;-)
[As an aside... Invoking bash scripts (non-interactive shells) as
/bin/sh will cause bash to NOT read any start-up files, which is
normally what you'd want when writing shell scripts, because if the
user's start-up files are read, the user's environment could
unexpectedly interfere with the operation of your shell script (like
if they change LANG or other locale variables, for instance). Only
invoke shell scripts as /bin/bash when your script is intended to be
run only by you, for purposes of setting up stuff in your environment
(or setting up stuff that needs your environment to function
properly). Otherwise, invoke as /bin/sh.]
--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
pgpTGvoe3aPXl.pgp
Description: PGP signature
