Re: Defering passphrase entry with ssh-add

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

Relevant Pages

  • Re: Defering passphrase entry with ssh-add
    ... reason why ssh-add couldn't defer requesting a password until its ... until it determined it needed your passphrase. ... Also, how would ssh know if you didn't have a key for this connection, ... you can delay typing your passphrase, which you're going to need to ...
    (SSH)
  • RE: Controlling ssh from an external program
    ... passphrase could be discovered and the private key would fall into dangerous ... NB the SSH environment strings need to be included in this mixture! ... character as the final character could signify accept from a file. ... Controlling ssh from an external program ...
    (SSH)
  • Re: More on learning "Public Key Authentication"
    ... > computers in my local network are configured that way. ... > A long passphrase is a good idea but for other reasons. ... I _think_ a passphrase is used merely to verify that a public SSH ... _public_ keys between computers, so I do not even use a public SSH ...
    (comp.sys.mac.system)
  • different SSH/keychain behavior on Fedora Core 4?
    ... I'm wondering if anyone's seen different SSH and keychain behavior on ... But since upgrading the home machine to FC4 this trick no longer works ... for the passphrase for the local RSA private key... ... I realize that this may be more of an SSH question than an actual Fedora ...
    (Fedora)
  • Re: ssh-keygen between SuSE and FreeBSD
    ... You need to start an ssh-agent on the machine you're connecting from and ... see if it has ssh session support. ... If the ssh-agent and ssh-add utilities load the keys into memory, ... rebooting will take the keys out of memory and you would need to ...
    (freebsd-stable)