Can AVPN use identities stored in ssh-agent?

[Chris Cleeland]

What is the status of AVPN use of ssh-agent? Why doesn't it seem to
be using the identities from the agent rather than fetching them
itself?

I just downloaded 1.6pre on leopard and am trying to demo it.
However, if I have to trust my passphrases to yet another app that's
not keychain, I will go back to manual tunneling regardless of how
convenient AVPN might be.

[Leaping Bytes, LLC]

Sorry to disappoint you, but as of now, AVPN does not know how to talk
to ssh-agent.

I have done some googling and found source code for ssh-agent. It
does not look too horrible, but it will take time (which is lately
rather scarce commodity :( ) to add this functionality to AVPN (if I
will ever decide to do so).

What is your real concern? "... have to trust my passphrases to yet
another app that's not keychain, ... " -- does it mean that you will
be satisfied if AVPN did store your passphrase in keychain?
Presently, AVPN using 2-level schema to store sensitive information.
All passwords/passphrses stores in encrypted file (PBEWithMD5AndDES)
and master password (used to build encryption key) stored in keychain
( item almostVPN@almostVPN ). In retrospect, I regret to do it this
way, but this is how it is now. Next version (2.x) most likely will
get rid of this 2-level schema and store all info in keychain.

Andrei Tchijov
Leaping Bytes, LLC

[Chris Cleeland]

On Mar 7, 5:31 pm, "Leaping Bytes, LLC" <andrei.tchi...@gmail.com>
wrote:

> Sorry to disappoint you, but as of now, AVPN does not know how to talk
> to ssh-agent.
>
> I have done some googling and found source code for ssh-agent.  It
> does not look too horrible, but it will take time (which is lately
> rather scarce commodity :( ) to add this functionality to AVPN (if I
> will ever decide to do so).

There there shouldn't be much you have to do in order to utilize ssh-
agent functionality as long as you're using the standard ssh
executables. If ssh sees the environment variable SSH_AUTH_SOCK
defined, it will first go to that socket to ask for credentials.

> What is your real concern?  "... have to trust my passphrases to yet
> another app that's  not keychain, ... " -- does it mean that you will
> be satisfied if AVPN did store your passphrase in keychain?

Well, my concerns are

(a) AVPN, an app whose source is not open for inspection and whose
security attributes are not known, requires direct access to my
passphrase, which makes for a security issue

(b) I have to sign on multiple times, whereas that is not required
with ssh-agent b/c it has already authenticated and obtained
credentials.

[Leaping Bytes, LLC]

Unfortunately (for this particular case) AVPN is not "... using
standard SSH executable.". AlmostVPN server is actually written in
Java and is using http://www.ganymed.ethz.ch/ssh2/ to "talk" ssh.

As of now, there is no plans to make AVPN open source. Though it may
change in the future.

To the best of my understanding, SSH-AGENT is using the very same keys
(identities) AVPN can be configured to use. So I am not quite follow
you comment about "sign on multiple times". Once you "tell" AVPN to
use particular key with particular server you done (unless of cause
you are using pass-phrases on your identity files -- which as far as I
can remember from your original post think you actually do).

May I ask you, how SSH-AGENT dealing with pass-phrase protected keys?
Are you typing pass-phrase every time your start SSH-AGENT or does it
store pass-phrase somewhere?

[Chris Cleeland]

On Mar 12, 12:05 am, "Leaping Bytes, LLC" <andrei.tchi...@gmail.com>
wrote:

> Unfortunately (for this particular case) AVPN is not "... using
> standard SSH executable.".  AlmostVPN server is actually written in
> Java and is usinghttp://www.ganymed.ethz.ch/ssh2/to "talk" ssh.

Bummer.

> As of now, there is no plans to make AVPN open source.  Though it may
> change in the future.

I wasn't suggesting that you should open source it; I was simply
pointing out that the choice for it to be closed limits trust because
there is no audit capability.

> To the best of my understanding, SSH-AGENT is using the very same keys
> (identities) AVPN can be configured to use.

Yes.

> So I am not quite follow
> you comment about "sign on multiple times".  Once you "tell" AVPN to
> use particular key with particular server you done (unless of cause
> you are using pass-phrases on your identity files -- which as far as I
> can remember from your original post think you actually do).

Yes, I do use passphrases on my identity files.

AVPN asks for the passphrase every time it tries to use the identity.

> May I ask you, how SSH-AGENT dealing with pass-phrase protected keys?
> Are you typing pass-phrase every time your start SSH-AGENT or does it
> store pass-phrase somewhere?

Any identity protected by a passphrase requires typing in that
passphrase when the identity is added to ssh-agent's cache. It is not
required any other time. From the man page for ssh-agent:

DESCRIPTION
ssh-agent is a program to hold private keys used for public key
authenti-
cation (RSA, DSA). The idea is that ssh-agent is started in the
begin-
ning of an X-session or a login session, and all other windows or
pro-
grams are started as clients to the ssh-agent program. Through
use of
environment variables the agent can be located and automatically
used for
authentication when logging in to other machines using ssh(1).

The agent initially does not have any private keys. Keys are
added using
ssh-add(1). When executed without arguments, ssh-add(1) adds the
files
~/.ssh/id_rsa, ~/.ssh/id_dsa and ~/.ssh/identity. If the
identity has a
passphrase, ssh-add(1) asks for the passphrase (using a small X11
appli-
cation if running under X11, or from the terminal if running
without X).
It then sends the identity to the agent. Several identities can
be
stored in the agent; the agent can automatically use any of these
identi-
ties. ssh-add -l displays the identities currently held by the
agent.

The idea is that the agent is run in the user's local PC, laptop,
or ter-
minal. Authentication data need not be stored on any other
machine, and
authentication passphrases never go over the network. However,
the con-
nection to the agent is forwarded over SSH remote logins, and the
user
can thus use the privileges given by the identities anywhere in
the net-
work in a secure way.

There are two main ways to get an agent set up: The first is that
the
agent starts a new subcommand into which some environment
variables are
exported, eg ssh-agent xterm &. The second is that the agent
prints the
needed shell commands (either sh(1) or csh(1) syntax can be
generated)
which can be evalled in the calling shell, eg eval `ssh-agent -s`
for
Bourne-type shells such as sh(1) or ksh(1) and eval `ssh-agent -
c` for
csh(1) and derivatives.

Later ssh(1) looks at these variables and uses them to establish
a con-
nection to the agent.

The agent will never send a private key over its request channel.
Instead, operations that require a private key will be performed
by the
agent, and the result will be returned to the requester. This
way, pri-
vate keys are not exposed to clients using the agent.

A unix-domain socket is created and the name of this socket is
stored in
the SSH_AUTH_SOCK environment variable. The socket is made
accessible
only to the current user. This method is easily abused by root
or
another instance of the same user.

The SSH_AGENT_PID environment variable holds the agent's process
ID.