Derek Martin wrote:
On Tue, Nov 20, 2007 at 07:01:21PM +0000, Christopher Key wrote:
I've done created a Bash solution for now,
alias ssh="ssh-add -l >/dev/null; if [ \$? = 1 ]; then ssh-add; fi; ssh"
hardly elegant, but it does the job. I'm not aware of any technical
reason why ssh-add couldn't defer requesting a password until its
required.
This is technically infeasible, if not impossible.
Err, the above is perfectly feasible.
ssh-add needs to ask you for your passphrase. A process can't run in the background if
it needs to ask the user for input...
Yes which is why you only check/run it when ssh is used. but the agent
is started before.
It needs to run in the foreground until it does this, and it needs to stay connected to your
terminal so it can ask you for it -- it would tie up your terminal
until it determined it needed your passphrase.
Certainly not. My ssh-agent follows me around in whichever pts or tty I
use.
You are talking about ssh-add which is not the same thing and as
mentioned above.
If you put this in
your .profile or whatever other login file, you would never get a
shell prompt until you typed your passphrase. I suppose if you were
in X it could conceivably spawn an X client to pop up a dialog to ask
you for the passphrase, but that could only work in X.
Again, ssh-agent works for me across all terminals as well as just in X,
it's ssh-add you are talking about here which is
the whole point of the OP's idea, you do not arbitrarily run ssh-add
without the need to use it's functionality.
Also, how would ssh know if you didn't have a key for this connection,
or if you just hadn't yet typed your passphrase?
err, you check for the presence of your ssh key(s). This is very basic
programmatic control. Come on.
If the user had a long passphrase, and made several mistakes typing it, the ssh
connection could time out before you got it right.
Not likely unless you are a one finger typist in which case I insist you
stop using any unix immediately. If you're not using unix or some
derivative, but instead using Windows, bad luck but at least it's well
suited to your skill level. :-)
Also, the ssh connection is not started until the key is loaded,
therefore it will never time out on you. I left this up for 5 mins on
time(r) and it didn't time out.
Even if it's technically possible, it's really gross. And for what benefit? So
you can delay typing your passphrase, which you're going to need to
type eventually anyway?
It's actually a good point though, your shot is way off. If you have for
example, a laptop, you power it up, open a terminal, ah, this stupid
secondary prompt is in the way.
Which leaves you with 2 options - you can either dismiss it and have an
ssh connections fail or ask you pw if this is even allowed, or you can
type it and never need it (and if you have a massive 20 character
complex passphrase this is not efficient)
Better: If you use ssh, then you put it in once at that time and every
future session is automatically using your cached key. If not, then no
bother, you never have to put it in. You can check that thing you
wanted, power off again, no prompt for big passphrase that you'll never use.
It seems to me trying to hack this in is
totally not worth it.
Depends on how easy it is for you to do, took me literally one minute,
but yields years of future convenience. Especially for a laptop which
you are always switching on and off but not always using ssh.
If you want to delay, just don't run ssh-add
until you need to ssh...
Every time you boot your laptop? Why give yourself the extra work. Not
very smart.
The requirements of this feature are
ridiculously complex,
Only if you don't know anything. This is a 1 minute fix in bash.
all to avoid having to type 7 characters (i.e.
by putting ssh-add in your .profile instead of just typing it when you
know you're going to need it).
If you do a lot of stuff, streamlining is good. Repetition is stupid. I
am significantly faster than any colleague in my company because of all
the customization I have. It's one of the differences between newbies
and veterans.
I think the OP's idea is perfectly valid. In fact, it so much more valid
than your attempt to shoot it down that after a little thinking and your
email, I've now implemented a similar solution myself, although I made
the bash a bit nicer and in a func instead of alias, but the basic
principal is actually ok.
-h
--
Hari Sekhon
