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
pgpHnXM3Nwp6N.pgp
Description: PGP signature
