openssh unix dev - Sep 2003 - Agent Forwarding Anomalies on OpenBSD 3.3/OpenSSH 3.6.1

I have a curious situation with four OpenBSD 3.3 hosts.
Each of these has public/private keys on each other for inter-host
authentication using RSA2 keys. 

For instance, they're called hostA-to-hostBCD, hostB-to-hostACD,
hostC-to-hostABD, and hostD-to-hostABC.

The sshd_config files, on each host, look as follows...

  #;
  #; /etc/ssh/sshd_config
  #;
  Port 22
  Protocol 2
  ListenAddress 0.0.0.0
  HostKey /etc/ssh/ssh_host_key
  HostKey /etc/ssh/ssh_host_rsa_key
  HostKey /etc/ssh/ssh_host_dsa_key
  SyslogFacility AUTH
  LogLevel INFO
  LoginGraceTime 30
  PermitRootLogin no
  StrictModes yes
  RSAAuthentication yes
  PubkeyAuthentication yes
  AuthorizedKeysFile      .ssh/authorized_keys
  IgnoreRhosts yes
  RhostsRSAAuthentication no
  HostbasedAuthentication no
  PasswordAuthentication no
  PermitEmptyPasswords no
  ChallengeResponseAuthentication yes
  X11Forwarding no
  X11DisplayOffset 10
  X11UseLocalhost yes
  PrintMotd yes
  PrintLastLog yes
  KeepAlive yes
  UseLogin no
  UsePrivilegeSeparation yes
  PermitUserEnvironment no
  Compression yes
  MaxStartups 24
  Banner /etc/issue.net
  Subsystem       sftp    /usr/libexec/sftp-server

HostA allows ssh from the world to hosts B, C and D -- which have
SSH filtered. HostA also has ssh-agent running on it; and allows
me to login to B,C,D w/o problems, so long as the agent is
unlocked. This looks like...

Now, the tricky part....if I log into HostB, from HostA (which has
ssh-agent running, unlocked), I can log into HostC and HostD w/o a
password. HostA's public key is on all the other machines...I
would expect to be able to login to the other hosts directly from
HostA, but not using HostB as a stepping stone w/o require
authenticating with HostB's key, when logging into HostC or HostD.

A verbose output shows the following... I've marked the strange
part with "^^^"'s.

debug1: identity file /home/eric/.ssh/keys/hostB-to-hostACD type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.6.1
debug1: match: OpenSSH_3.6.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.6.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: using hostkeyalias: HostC
debug1: Host 'mars' is known and matches the RSA host key.
debug1: Found key in /home/eric/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering agent key: /home/eric/.ssh/keys/prv/HostA-to-HostBCD
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
debug1: Server accepts key: pkalg ssh-rsa blen 277 lastkey 0x4c0a0 hint -1
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: channel 0: request pty-req
debug1: Requesting authentication agent forwarding.
debug1: channel 0: request auth-agent-req at openssh.com
debug1: channel 0: request shell

Why is hostB forwarding hostA's keys to HostC? This also works
logging into HostD too.

Note that with the exact same configuration, going from HostA to
HostC to HostD (instead of using HostB) does not work. Nor does
going from HostA to HostD to HostC, etc..

Someone hit me with a cluestick please! This is making me crazy.

Thanks.

- Eric

On Fri, 12 Sep 2003, Eric wrote:
> I have a curious situation with four OpenBSD 3.3 hosts.
> Each of these has public/private keys on each other for inter-host
> authentication using RSA2 keys.
>
> For instance, they're called hostA-to-hostBCD, hostB-to-hostACD,
> hostC-to-hostABD, and hostD-to-hostABC.
>
> The sshd_config files, on each host, look as follows...
>
[..]

In this case your global ssh_config and personal ssh_config would be
more interesting.
>
> HostA allows ssh from the world to hosts B, C and D -- which have
> SSH filtered. HostA also has ssh-agent running on it; and allows
> me to login to B,C,D w/o problems, so long as the agent is
> unlocked. This looks like...
>
> Now, the tricky part....if I log into HostB, from HostA (which has
> ssh-agent running, unlocked), I can log into HostC and HostD w/o a
> password. HostA's public key is on all the other machines...I
> would expect to be able to login to the other hosts directly from
> HostA, but not using HostB as a stepping stone w/o require
> authenticating with HostB's key, when logging into HostC or HostD.
>
This is called Agent forwarding.

man ssh_config
[..]
     ForwardAgent
             Specifies whether the connection to the authentication agent (if
             any) will be forwarded to the remote machine.  The argument must
             be ``yes'' or ``no''. The default is
``no''.

             Agent forwarding should be enabled with caution.  Users with the
             ability to bypass file permissions on the remote host (for the
             agent's Unix-domain socket) can access the local agent through
             the forwarded connection.  An attacker cannot obtain key material
             from the agent, however they can perform operations on the keys
             that enable them to authenticate using the identities loaded into
             the agent.

[..]
> debug1: channel 0: request pty-req
> debug1: Requesting authentication agent forwarding.
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> debug1: channel 0: request auth-agent-req at openssh.com
[..]

- Ben