From alex at alex.org.uk  Sat Oct  1 01:22:04 2011
From: alex at alex.org.uk (Alex Bligh)
Date: Fri, 30 Sep 2011 16:22:04 +0100
Subject: openssh remote port forwarding and permitopen
Message-ID: <4908875DA3BCFB129BF0B632@Ximines.local>

I have an application where a lot of end user CPE devices ssh in
automatically to a central server, and are authenticated
by public key, to do remote (-R) port forwarding, so we can open
a connection back to a particular port on the remote device whether
it's behind some NAT or firewall or whatever. I want to be certain,
however, that if I open port 12345, it is connected to the correct
end user CPE (i.e. the one that presented the correct key).

Therefore I'd like an forceremoteport option in authorized_keys
so whatever remote port is specified by the client (perhaps
the client just specifies 0), it uses a particular allocated port
and no other. I don't particularly want to do the equivalent of
permitopen, as I'd have to have each client keep up with the
port allocations on the server, which is unnecessary and a pain.
In my scheme the client can do
   ssh -N -R 80:127.0.0.1:0 host.example.com
with forceremoteport=12345, which would mean that
   telnet 127.0.0.1 12345
on host.example.com would connect to the CPE"s port 80.

Would you take a patch for this? It would have the advantage
that forceremoteport=0 would effectively disable -R forwarding.

Supplemental question: I'd like to disabled -L port forwarding as
well (whilst leaving -R allowed subject to the above). I can't
immediately see any way to do this except for using permitopen
and a port that has nothing bound to it. Am I missing something?

-- 
Alex Bligh

From william at 25thandClement.com  Sat Oct  1 07:52:55 2011
From: william at 25thandClement.com (William Ahern)
Date: Fri, 30 Sep 2011 14:52:55 -0700
Subject: sizeof(char)
In-Reply-To: <86fwjf84pk.fsf@ds4.des.no>
References: <86mxdo89yt.fsf@ds4.des.no>
 <alpine.BSO.2.00.1109291111540.19071@natsu.mindrot.org>
 <4E84CA45.9050606@roumenpetrov.info> <86fwjf84pk.fsf@ds4.des.no>
Message-ID: <20110930215255.GA29820@wilbur.25thandClement.com>

On Thu, Sep 29, 2011 at 10:37:59PM +0200, Dag-Erling Sm??rgrav wrote:
> Roumen Petrov <openssh at roumenpetrov.info> writes:
> > I don't know what you apply but  patch as is just say good bay on old
> > systems where char is with sizeof integer.
> 
> I suggest you read what I wrote, and the passage I quoted from the C
> standard.
> 
> To summarize: sizeof(char) == 1.  Always.  No exceptions.
> 

Just to clarify this a bit for those confused, if sizeof (char) == sizeof
(int) then sizeof (int) == 1, and CHAR_BIT >= 16.

Not only is this required by the spec, but it's fundamental to the machine
model upon which C and similar languages are based. The relationships are
never going to change.


From g+openssh at cobb.uk.net  Sat Oct  1 07:45:03 2011
From: g+openssh at cobb.uk.net (Graham Cobb)
Date: Fri, 30 Sep 2011 22:45:03 +0100
Subject: Interop problem with old dropbear and new openssh
Message-ID: <201109302245.04560.g+openssh@cobb.uk.net>

Hi,

I have a router running an old version of OpenWRT with an old version of 
dropbear (Dropbear sshd v0.44test3).  It has been working for many years and I 
ssh in from my desktop systems (running Debian Testing) with no problem.

However, recently I upgraded one of my desktops and I can no longer connect to 
the router.  Dropbear on the router is exiting with:

exit before auth: bad buf_getwriteptr

Looking at the output from ssh -vv, the problem occurs right after

debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY

The desktop is running "SSH-2.0-OpenSSH_5.9p1 Debian-1" (it failed with 5.8 as 
well).  However, another desktop still running "SSH-2.0-OpenSSH_5.5p1 
Debian-6" still works fine.  The config files are identical and I can't find 
anything in the changelog between those versions which looks like it would 
affect the content of that message.

Has anyone seen this, or does anyone have any suggestions for possible 
workrounds?

Graham

From djm at mindrot.org  Sat Oct  1 11:53:18 2011
From: djm at mindrot.org (Damien Miller)
Date: Sat, 1 Oct 2011 11:53:18 +1000 (EST)
Subject: Interop problem with old dropbear and new openssh
In-Reply-To: <201109302245.04560.g+openssh@cobb.uk.net>
References: <201109302245.04560.g+openssh@cobb.uk.net>
Message-ID: <alpine.BSO.2.00.1110011152350.3963@natsu.mindrot.org>

please include a full debug trace from the client and, if possible, from
the server.

On Fri, 30 Sep 2011, Graham Cobb wrote:

> Hi,
> 
> I have a router running an old version of OpenWRT with an old version of 
> dropbear (Dropbear sshd v0.44test3).  It has been working for many years and I 
> ssh in from my desktop systems (running Debian Testing) with no problem.
> 
> However, recently I upgraded one of my desktops and I can no longer connect to 
> the router.  Dropbear on the router is exiting with:
> 
> exit before auth: bad buf_getwriteptr
> 
> Looking at the output from ssh -vv, the problem occurs right after
> 
> debug1: sending SSH2_MSG_KEXDH_INIT
> debug1: expecting SSH2_MSG_KEXDH_REPLY
> 
> The desktop is running "SSH-2.0-OpenSSH_5.9p1 Debian-1" (it failed with 5.8 as 
> well).  However, another desktop still running "SSH-2.0-OpenSSH_5.5p1 
> Debian-6" still works fine.  The config files are identical and I can't find 
> anything in the changelog between those versions which looks like it would 
> affect the content of that message.
> 
> Has anyone seen this, or does anyone have any suggestions for possible 
> workrounds?
> 
> Graham
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

From titu_senapati at yahoo.com  Sun Oct  2 23:22:23 2011
From: titu_senapati at yahoo.com (titu senapati)
Date: Sun, 2 Oct 2011 05:22:23 -0700 (PDT)
Subject: Information on command execution in sshd
Message-ID: <1317558143.52331.YahooMailNeo@web39424.mail.mud.yahoo.com>

Hi,

I was going through the code of open ssh server part ( code for sshd ). My query is when user gives any command ( for example unix command "ls")
in the console ( after ssh login is complete ), which function in sshd will execute this command. I traced that the command is coming to sshd code
in message type SSH2_MSG_CHANNEL_DATA. There is a check using function packet_check_eom(). But I am not able to trace the place
where linux command "ls" will be executed. I want to know the function in sshd code which will execute this function.


Hoping for your expertise in this regard. Kindly help.

Best regards,

Titu

From alex at alex.org.uk  Mon Oct  3 04:38:31 2011
From: alex at alex.org.uk (Alex Bligh)
Date: Sun, 02 Oct 2011 18:38:31 +0100
Subject: Information on command execution in sshd
In-Reply-To: <1317558143.52331.YahooMailNeo@web39424.mail.mud.yahoo.com>
References: <1317558143.52331.YahooMailNeo@web39424.mail.mud.yahoo.com>
Message-ID: <C522B9B2B1319DD2D4665887@nimrod.local>



--On 2 October 2011 05:22:23 -0700 titu senapati <titu_senapati at yahoo.com> 
wrote:

> I was going through the code of open ssh server part ( code for sshd ).
> My query is when user gives any command ( for example unix command "ls")
> in the console ( after ssh login is complete ), which function in sshd
> will execute this command.

Assuming by "ssh login" you mean login in the sense of an interactive
shell, ssh runs bash (or whatever shell the user has set up). It then
passes stdin to bash over the ssh channel and prints stdout. Thus ssh
isn't executing the commands, it's just passing them to an existing
shell through an fd.

-- 
Alex Bligh

From dkg at fifthhorseman.net  Mon Oct  3 04:39:16 2011
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 02 Oct 2011 13:39:16 -0400
Subject: Information on command execution in sshd
In-Reply-To: <1317558143.52331.YahooMailNeo@web39424.mail.mud.yahoo.com>
References: <1317558143.52331.YahooMailNeo@web39424.mail.mud.yahoo.com>
Message-ID: <4E88A1C4.9000308@fifthhorseman.net>

On 10/02/2011 08:22 AM, titu senapati wrote:

> I was going through the code of open ssh server part ( code for sshd ). My query is when user gives any command ( for example unix command "ls")
> in the console ( after ssh login is complete ), which function in sshd will execute this command. I traced that the command is coming to sshd code
> in message type SSH2_MSG_CHANNEL_DATA. There is a check using function packet_check_eom(). But I am not able to trace the place
> where linux command "ls" will be executed. I want to know the function in sshd code which will execute this function.

In the common case, sshd invokes a child process of the user's shell
upon session creation.  Then when the user types a command like "ls",
that command gets shuttled across ssh as channel data (as you've seen)
and handed as input to the child process (the shell).

It is the shell which interprets the "ls" as a command and in turn
invokes /bin/ls (or whatever).

So sshd doesn't invoke ls directly at all.  Make sense?

hope this helps,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20111002/9ff6557a/attachment.bin>

From djm at mindrot.org  Tue Oct  4 01:16:24 2011
From: djm at mindrot.org (Damien Miller)
Date: Tue, 4 Oct 2011 01:16:24 +1100 (EST)
Subject: Information on command execution in sshd
In-Reply-To: <1317558143.52331.YahooMailNeo@web39424.mail.mud.yahoo.com>
References: <1317558143.52331.YahooMailNeo@web39424.mail.mud.yahoo.com>
Message-ID: <alpine.BSO.2.00.1110040113140.16372@natsu.mindrot.org>

On Sun, 2 Oct 2011, titu senapati wrote:

> Hi,
>
> I was going through the code of open ssh server part ( code for sshd
> ). My query is when user gives any command ( for example unix command
> "ls") in the console ( after ssh login is complete ), which function
> in sshd will execute this command. I traced that the command is coming
> to sshd code in message type SSH2_MSG_CHANNEL_DATA. There is a check
> using function packet_check_eom(). But I am not able to trace the
> place where linux command "ls" will be executed. I want to know the
> function in sshd code which will execute this function.

What are you trying to do? (this looks a lot like a homework question)

The request is not SSH2_MSG_CHANNEL_DATA but SSH2_MSG_CHANNEL_REQUEST.

-d

From titu_senapati at yahoo.com  Wed Oct  5 05:15:14 2011
From: titu_senapati at yahoo.com (titu senapati)
Date: Tue, 4 Oct 2011 11:15:14 -0700 (PDT)
Subject: Information on command execution in sshd
In-Reply-To: <1317558143.52331.YahooMailNeo@web39424.mail.mud.yahoo.com>
References: <1317558143.52331.YahooMailNeo@web39424.mail.mud.yahoo.com>
Message-ID: <1317752114.33323.YahooMailNeo@web39411.mail.mud.yahoo.com>

Hi,

My query is answered now.? Thanks to Alex, Daniel and Damien for the response.
I searched the openssh code where SHELL process is started and got to know the steps.

Thanks to all.

Best Regards,

Titu



________________________________
From: titu senapati <titu_senapati at yahoo.com>
To: "openssh-unix-dev at mindrot.org" <openssh-unix-dev at mindrot.org>
Sent: Sunday, October 2, 2011 5:52 PM
Subject: Information on command execution in sshd


Hi,

I was going through the code of open ssh server part ( code for sshd ). My query is when user gives any command ( for example unix command "ls")
in the console ( after ssh login is complete ), which function in sshd will execute this command. I traced that the command is coming to sshd code
in message type SSH2_MSG_CHANNEL_DATA. There is a check using function packet_check_eom(). But I am not able to trace the place
where linux command "ls" will be executed. I want to know the function in sshd code which will execute this function.


Hoping for your expertise in this regard. Kindly help.

Best regards,

Titu

From hebarber at au1.ibm.com  Fri Oct  7 09:58:16 2011
From: hebarber at au1.ibm.com (Henry Barber)
Date: Fri, 7 Oct 2011 08:58:16 +1000
Subject: OpenSSH hanging
Message-ID: <OFC859F826.0BA50282-ONCA257921.007DAB6A-4A257921.007DD140@au1.ibm.com>


   Hi there,
   I'm having some strange behaviour from OpenSSH
   It presents itself when using the "ssh -t" / pseudo terminal.
   We are using this feature to update the wtmp and it is working fine on
   SuSE and RH, but our AIX hosts are getting hung. The first attempt is
   usually successful, but eventually, the session is hung and the CRTL-Z
   does not put the process into background.
   The ssh -v output
   OpenSSH_5.4p1, OpenSSL 0.9.8m 25 Feb 2010
   and when I run a truss:
   [snipped]
   kwrite(4, " ?9E ? d ? ? e 9 ? O\b ?".., 576)    = 576
   _select(5, 0x2005DC28, 0x00000000, 0x00000000, 0x00000000) = 1
   kread(4, " ?8E07 y ? ? ? } ? < ? ?".., 8192)    = 32
   kfcntl(0, F_DUPFD, 0x00000000)                  = 5
   kfcntl(1, F_DUPFD, 0x00000000)                  = 6
   kfcntl(2, F_DUPFD, 0x00000000)                  = 7
   kioctl(5, 22528, 0x00000000, 0x00000000)        = 0
   kioctl(6, 22528, 0x00000000, 0x00000000)        = 0
   kioctl(7, 22528, 0x00000000, 0x00000000)        = 0
   kfcntl(5, F_SETFD, 0x00000001)                  = 0
   kfcntl(6, F_SETFD, 0x00000001)                  = 0
   kfcntl(7, F_SETFD, 0x00000001)                  = 0
   kioctl(6, 22528, 0x00000000, 0x00000000)        = 0
   sigprocmask(2, 0xF0277960, 0x2FF21AB0)          = 0
   _sigaction(1, 0x00000000, 0x2FF21B60)           = 0
   thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000, 0x11FA00A9,
   0x00000000, 0x00000013, 0x00000000, 0x00000000) = 0x00000000
   sigprocmask(2, 0xF0277960, 0x2FF21AB0)          = 0
   _sigaction(1, 0x2FF21B50, 0x00000000)           = 0
   thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000, 0x11FA00A9,
   0x00000000, 0x00000014, 0x00000000, 0x00000000) = 0x00000000
   sigprocmask(2, 0xF0277960, 0x2FF21AB0)          = 0
   _sigaction(1, 0x00000000, 0x2FF21B60)           = 0
   thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000, 0x11FA00A9,
   0x00000000, 0x00000016, 0x00000000, 0x00000000) = 0x00000000
   sigprocmask(2, 0xF0277960, 0x2FF21AB0)          = 0
   _sigaction(1, 0x2FF21B50, 0x00000000)           = 0
   thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000, 0x11FA00A9,
   0x00000000, 0x00000018, 0x00000000, 0x00000000) = 0x00000000
   sigprocmask(2, 0xF0277960, 0x2FF21AB0)          = 0
   _sigaction(2, 0x00000000, 0x2FF21B60)           = 0
   thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000, 0x11FA00A9,
   0x00000000, 0x00000013, 0x00000000, 0x00000000) = 0x00000000
   sigprocmask(2, 0xF0277960, 0x2FF21AB0)          = 0
   _sigaction(2, 0x2FF21B50, 0x00000000)           = 0
   thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000, 0x11FA00A9,
   0x00000000, 0x00000016, 0x00000000, 0x00000000) = 0x00000000
   sigprocmask(2, 0xF0277960, 0x2FF21AB0)          = 0
   _sigaction(2, 0x00000000, 0x2FF21B60)           = 0
   thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000, 0x11FA00A9,
   0x00000000, 0x00000016, 0x00000000, 0x00000000) = 0x00000000
   sigprocmask(2, 0xF0277960, 0x2FF21AB0)          = 0
   _sigaction(2, 0x2FF21B50, 0x00000000)           = 0
   thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000, 0x11FA00A9,
   0x00000000, 0x00000016, 0x00000000, 0x00000000) = 0x00000000
   sigprocmask(2, 0xF0277960, 0x2FF21AB0)          = 0
   _sigaction(3, 0x00000000, 0x2FF21B60)           = 0
   thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000, 0x11FA00A9,
   0x00000000, 0x00000014, 0x00000000, 0x00000000) = 0x00000000
   sigprocmask(2, 0xF0277960, 0x2FF21AB0)          = 0
   _sigaction(3, 0x2FF21B50, 0x00000000)           = 0
   thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000, 0x11FA00A9,
   0x00000000, 0x0000001B, 0x00000000, 0x00000000) = 0x00000000
   sigprocmask(2, 0xF0277960, 0x2FF21AB0)          = 0
   _sigaction(3, 0x00000000, 0x2FF21B60)           = 0
   thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000, 0x11FA00A9,
   0x00000000, 0x00000013, 0x00000000, 0x00000000) = 0x00000000
   sigprocmask(2, 0xF0277960, 0x2FF21AB0)          = 0
   _sigaction(3, 0x2FF21B50, 0x00000000)           = 0
   thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000, 0x11FA00A9,
   0x00000000, 0x00000016, 0x00000000, 0x00000000) = 0x00000000
   sigprocmask(2, 0xF0277960, 0x2FF21AB0)          = 0
   _sigaction(15, 0x00000000, 0x2FF21B60)          = 0
   thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000, 0x11FA00A9,
   0x00000000, 0x00000015, 0x00000000, 0x00000000) = 0x00000000
   sigprocmask(2, 0xF0277960, 0x2FF21AB0)          = 0
   _sigaction(15, 0x2FF21B50, 0x00000000)          = 0
   thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000, 0x11FA00A9,
   0x00000000, 0x00000015, 0x00000000, 0x00000000) = 0x00000000
   sigprocmask(2, 0xF0277960, 0x2FF21AB0)          = 0
   _sigaction(15, 0x00000000, 0x2FF21B60)          = 0
   thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000, 0x11FA00A9,
   0x00000000, 0x00000019, 0x00000000, 0x00000000) = 0x00000000
   sigprocmask(2, 0xF0277960, 0x2FF21AB0)          = 0
   _sigaction(15, 0x2FF21B50, 0x00000000)          = 0
   thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000, 0x11FA00A9,
   0x00000000, 0x0000001A, 0x00000000, 0x00000000) = 0x00000000
   sigprocmask(2, 0xF0277960, 0x2FF21AB0)          = 0
   _sigaction(28, 0x00000000, 0x2FF21B60)          = 0
   thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000, 0x11FA00A9,
   0x00000000, 0x0000001E, 0x00000000, 0x00000000) = 0x00000000
   sigprocmask(2, 0xF0277960, 0x2FF21AB0)          = 0
   _sigaction(28, 0x2FF21B50, 0x00000000)          = 0
   thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000, 0x11FA00A9,
   0x00000000, 0x0000001B, 0x00000000, 0x00000000) = 0x00000000
   kioctl(0, 22528, 0x00000000, 0x00000000)        = 0
   kioctl(0, 21505, 0x2FF21B50, 0x00000000)        = 0
   kioctl(0, 22528, 0x00000000, 0x00000000)        = 0
   kioctl(0, 21507, 0x2FF21B50, 0x00000000)        = 0
                                                      _select(8,
   0x2005DC28, 0x2005EBB8, 0x00000000, 0x00000000) = 1

                                            kwrite(4, " ? ? >9A06 ?
   0 L 319 ?92".., 128)        = 128
                        _select(8, 0x2005DC28, 0x2005EBB8, 0x00000000,
   0x00000000) = 1

              kread(4, " ? ? c ? g :1D1B ?11 ? 9".., 8192)
    = 48

                                                               kioctl(0,
   1074295912, 0x2FF21A04, 0x00000000)        = 0
                                              getsockopt(4, 6, 1,
   0x2FF219D0, 0x2FF219D4)        = 0

                      setsockopt(4, 6, 1, 0x2FF219D0, 4)                =
   0


   ngetsockname(4, 0x2FF21480, 0x2FF21988)                = 0
                                                      setsockopt(4, 0, 3,
   0x2FF219D0, 4)                = 0

                              _select(8, 0x2005DC28, 0x2005EBB8,
   0x00000000, 0x00000000) = 1
                     kwrite(4, "96 C C F v ? Q   l ? ?\f".., 384)
        = 384

   _select(8, 0x2005DC28, 0x2005EBB8, 0x00000000, 0x00000000)
   (sleeping...)
   Henry Barber
   Australian Development Lab
   office: +61 7 5552 4050
   mobile: +61 449 101 452

From dtucker at zip.com.au  Fri Oct  7 13:35:47 2011
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 07 Oct 2011 13:35:47 +1100
Subject: OpenSSH hanging
In-Reply-To: <OFC859F826.0BA50282-ONCA257921.007DAB6A-4A257921.007DD140@au1.ibm.com>
References: <OFC859F826.0BA50282-ONCA257921.007DAB6A-4A257921.007DD140@au1.ibm.com>
Message-ID: <4E8E6583.4060508@zip.com.au>

On 7/10/11 9:58 AM, Henry Barber wrote:
>     I'm having some strange behaviour from OpenSSH
>     It presents itself when using the "ssh -t" / pseudo terminal.
>     We are using this feature to update the wtmp and it is working fine on
>     SuSE and RH, but our AIX hosts are getting hung. The first attempt is
>     usually successful, but eventually, the session is hung and the CRTL-Z
>     does not put the process into background.
>     The ssh -v output
>     OpenSSH_5.4p1, OpenSSL 0.9.8m 25 Feb 2010

This could happen with old versions of OpenSSH: they did not correctly 
handle the case where pty allocation failed.

This was fixed in 5.6.  From http://www.openssh.com/txt/release-5.6:

  Kill channel when pty allocation requests fail. Fixed stuck client
    if the server refuses pty allocation (bz#1698)

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From alex at alex.org.uk  Sat Oct  8 20:01:38 2011
From: alex at alex.org.uk (Alex Bligh)
Date: Sat, 08 Oct 2011 10:01:38 +0100
Subject: Detect PID of sshd processes used by one public key; detect -R
 allocated port on the server
Message-ID: <7D93B2E7DE04786E20961C99@nimrod.local>

I have a situation where a number of potentially hostile clients ssh to
a host I control, each ssh'ing in as the same user, and each forwarding
a remote port back to them.

So, the authorized_keys file looks like:

no-agent-forwarding,command="/bin/true",no-pty,no-user-rc,no-X11-forwarding,permitopen="127.0.0.1:7" 
ssh-rsa AAAAB....vnRWxcgaK9xXoU= client1234 at example.com

[the permitopen stanza just disables -L forwarding by only enabling a
forwarding to a port that will always refuse connections. Ignore this.]

and the ssh line from the client looks like this:

ssh -R0:127.0.0.1:1234 -N -ldummyuser central.example.org
Allocated port 54403 for remote forward to 127.0.0.1:1234

Now, ssh -R with a 0 port option allocates a remote port, which is what I
want to do, as I have lots and lots of these clients. It tells the /client/
what port it has allocated, but I want to know on the /server/ what port
has been allocated. On the server I want to detect which port (if any)
client1234 at example.com has open, and connect to that.

I can't pass this information from the client, because the potentially
hostile client could pass back a different number. I could then connect
to a port and be fooled into connecting to wrong client.

My plan was to get the PID of the sshd process, then use lsof to find
what ports it was listening on.

The lsof bit works:

$ lsof -n -p 12287 -a -i4tcp -a -sTCP:LISTEN
COMMAND   PID     USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
sshd    12287 testuser   10u  IPv4 10196497      0t0  TCP 127.0.0.1:54403 
(LISTEN)

But there seems to be no way to get the PIDs of an ssh process associated
with a particular public key, as opposed to a particular user.

Logs would be unreliable anyway (race conditions), but the log line simply 
says this (no indication of what key is accepted):

Oct  8 09:30:15 test sshd[12214]: Accepted publickey for dummyuser from 
10.1.3.45 port 55158 ssh2
Oct  8 09:30:15 test sshd[12214]: pam_unix(sshd:session): session opened 
for user dummyuser by (uid=0)

I can't help but think that log line would be more useful if it said which
public key was accepted (am willing to provide a patch, but would prefer
to avoid a code change).

Any ideas on how to get from a public key to list of sshd processes?

-- 
Alex Bligh


From phil.pennock at globnix.org  Sat Oct  8 21:56:03 2011
From: phil.pennock at globnix.org (Phil Pennock)
Date: Sat, 8 Oct 2011 06:56:03 -0400
Subject: Detect PID of sshd processes used by one public key; detect -R
 allocated port on the server
In-Reply-To: <7D93B2E7DE04786E20961C99@nimrod.local>
References: <7D93B2E7DE04786E20961C99@nimrod.local>
Message-ID: <20111008105603.GA54589@redoubt.spodhuis.org>

On 2011-10-08 at 10:01 +0100, Alex Bligh wrote:
> I can't help but think that log line would be more useful if it said which
> public key was accepted (am willing to provide a patch, but would prefer
> to avoid a code change).

LogLevel VERBOSE

-Phil

From alex at alex.org.uk  Sun Oct  9 00:20:09 2011
From: alex at alex.org.uk (Alex Bligh)
Date: Sat, 08 Oct 2011 14:20:09 +0100
Subject: Detect PID of sshd processes used by one public key; detect -R
 allocated port on the server
In-Reply-To: <20111008120659.GA7239@mercury.spuddy.org>
References: <7D93B2E7DE04786E20961C99@nimrod.local>
 <20111008120659.GA7239@mercury.spuddy.org>
Message-ID: <AA0FA8A65CCB2E65C141A949@nimrod.local>



--On 8 October 2011 08:06:59 -0400 Stephen Harris <lists at spuddy.org> wrote:

>> no-agent-forwarding,command="/bin/true",no-pty,no-user-rc,no-X11-forward
>> ing,permitopen="127.0.0.1:7"
>
>> But there seems to be no way to get the PIDs of an ssh process associated
>> with a particular public key, as opposed to a particular user.
>
> Instead of command="/bin/true" use command="/path/to/script".  The script
> can look at parent processes and work up the tree until it reaches the
> sshd process.

(I hope you don't mind me sending the reply to the list)

This strategy does not work for two reasons:

1. when -N is used, command= / ForceCommand is not executed. It only forces
   running of a command when there is either an interactive session
   requested or a command on the command line.

2. (less of an issue), the user's shell can no longer be /bin/false; it has
   to be a real shell.

-- 
Alex Bligh

From alex at alex.org.uk  Sun Oct  9 00:24:50 2011
From: alex at alex.org.uk (Alex Bligh)
Date: Sat, 08 Oct 2011 14:24:50 +0100
Subject: Detect PID of sshd processes used by one public key; detect -R
 allocated port on the server
In-Reply-To: <20111008105603.GA54589@redoubt.spodhuis.org>
References: <7D93B2E7DE04786E20961C99@nimrod.local>
 <20111008105603.GA54589@redoubt.spodhuis.org>
Message-ID: <A086D06F50D9B1F7CF0AECDD@nimrod.local>



--On 8 October 2011 06:56:03 -0400 Phil Pennock <phil.pennock at globnix.org> 
wrote:

> On 2011-10-08 at 10:01 +0100, Alex Bligh wrote:
>> I can't help but think that log line would be more useful if it said
>> which public key was accepted (am willing to provide a patch, but would
>> prefer to avoid a code change).
>
> LogLevel VERBOSE

LogLevel VERBOSE only tells you what line number is matched. That is
not much use if authorized_keys changes over time (it does for me)
and ssh sessions could be up for days. I think it will also log
key fingerprints, but I don't know how one can obviously associate
them with a particular matched line (especially if your authorized_key
file contains the same key on multiple lines with different from=
match blocks).

-- 
Alex Bligh

From lists at spuddy.org  Sun Oct  9 00:55:00 2011
From: lists at spuddy.org (Stephen Harris)
Date: Sat, 8 Oct 2011 09:55:00 -0400
Subject: Detect PID of sshd processes used by one public key;
 detect -R allocated port on the server
In-Reply-To: <AA0FA8A65CCB2E65C141A949@nimrod.local>
References: <7D93B2E7DE04786E20961C99@nimrod.local>
 <20111008120659.GA7239@mercury.spuddy.org>
 <AA0FA8A65CCB2E65C141A949@nimrod.local>
Message-ID: <20111008135500.GA10800@mercury.spuddy.org>

On Sat, Oct 08, 2011 at 02:20:09PM +0100, Alex Bligh wrote:
> 
> 
> --On 8 October 2011 08:06:59 -0400 Stephen Harris <lists at spuddy.org> wrote:
> 
> >>no-agent-forwarding,command="/bin/true",no-pty,no-user-rc,no-X11-forward
> >>ing,permitopen="127.0.0.1:7"
> >
> >>But there seems to be no way to get the PIDs of an ssh process associated
> >>with a particular public key, as opposed to a particular user.
> >
> >Instead of command="/bin/true" use command="/path/to/script".  The script
> >can look at parent processes and work up the tree until it reaches the
> >sshd process.

> 1. when -N is used, command= / ForceCommand is not executed. It only forces
>   running of a command when there is either an interactive session
>   requested or a command on the command line.

I was assuming you would have do some work on how your application process
determined what port to talk to; you could have that dependent on having
had the script run.  So if the client uses -N then your application won't
talk to the forwarded port, which forces them to not do that :-)

> 2. (less of an issue), the user's shell can no longer be /bin/false; it has
>   to be a real shell.

Make the shell be the script.  Make the password for the account be '*'.
Now sshd will do "$SCRIPT -c $SCRIPT user1"; parse accordingly.

-- 

rgds
Stephen

From alex at alex.org.uk  Sun Oct  9 01:05:28 2011
From: alex at alex.org.uk (Alex Bligh)
Date: Sat, 08 Oct 2011 15:05:28 +0100
Subject: [PATCH] add log= directive to authorized_hosts
Message-ID: <B1BFE21F4E530F9075AEEA72@nimrod.local>

Attached is a patch which adds a log= directive to authorized_keys. The text
in the log="text" directive is appended to the log line, so you can easily
tell which key is matched.

For instance the line:

log="hello world!",no-agent-forwarding,command="/bin/true",no-pty,
no-user-rc,no-X11-forwarding,permitopen="127.0.0.1:7"
ssh-rsa AAAAB3Nza....xcgaK9xXoU= alex at example.com

produces a log line output like

Oct  8 11:04:47 test sshd[18469]: Accepted publickey for testuser from 
10.11.12.13 port 55580 ssh2 hello world!

A more useful use case might be to put the key's comment in the log=""
line.

This has been tested on 5.3, and compiles on 5.8 and 5.9. The diff
is clean against 5.9.

I have not provided support for log= being incorporated into
the certificate. I can do (though I am not sure how to test it,
I would just copy forcecommand) but was unclear if that would
create a certificate back compatibility issue.

If this patch is useful, I am happy to work on that bit.

-- 
Alex Bligh

From keisial at gmail.com  Sun Oct  9 02:34:22 2011
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Sat, 08 Oct 2011 17:34:22 +0200
Subject: [PATCH] add log= directive to authorized_hosts
In-Reply-To: <B1BFE21F4E530F9075AEEA72@nimrod.local>
References: <B1BFE21F4E530F9075AEEA72@nimrod.local>
Message-ID: <4E906D7E.8080301@gmail.com>

Alex Bligh wrote:
> Attached is a patch which adds a log= directive to authorized_keys. 
> The text
> in the log="text" directive is appended to the log line, so you can 
> easily
> tell which key is matched.
Note: the list has stripped the patch.

(...)
> produces a log line output like
>
> Oct  8 11:04:47 test sshd[18469]: Accepted publickey for testuser from 
> 10.11.12.13 port 55580 ssh2 hello world!
(...)
> If this patch is useful, I am happy to work on that bit.

Although this is interesting for your case, where the authorized_keys 
file is trusted,
I think it may provide some hole for malicious users with shell access.
Suppose that there is a script applying a regex to the log, and 
automatically banning
ips with more than X failures. Then Eve adds a key with log="Invalid 
user root from 192.168.1.1"
with 192.168.1.1 being the ip of the admin, or other users which make 
use of the machine.
After a few connections with publick key, Eve has kicked those people 
from the server.



From alex at alex.org.uk  Sun Oct  9 02:52:34 2011
From: alex at alex.org.uk (Alex Bligh)
Date: Sat, 08 Oct 2011 16:52:34 +0100
Subject: [PATCH] add log= directive to authorized_hosts
In-Reply-To: <B1BFE21F4E530F9075AEEA72@nimrod.local>
References: <B1BFE21F4E530F9075AEEA72@nimrod.local>
Message-ID: <F9EA15749B319DC32F496C74@nimrod.local>



--On 8 October 2011 15:05:28 +0100 Alex Bligh <alex at alex.org.uk> wrote:

> Attached is a patch which adds a log= directive to authorized_keys. The
> text
> in the log="text" directive is appended to the log line, so you can easily
> tell which key is matched.

Patch inline below - the list stripped it

-- 
Alex Bligh

diff --git a/auth-options.c b/auth-options.c
index 86c2317..334ec87 100644
--- a/auth-options.c
+++ b/auth-options.c
@@ -56,6 +56,9 @@ int forced_tun_device = -1;
 /* "principals=" option. */
 char *authorized_principals = NULL;

+/* "log=" option */
+char *log_auth_option = NULL;
+
 extern ServerOptions options;

 void
@@ -81,6 +84,10 @@ auth_clear_options(void)
 		xfree(authorized_principals);
 		authorized_principals = NULL;
 	}
+	if (log_auth_option) {
+		xfree(log_auth_option);
+		log_auth_option = NULL;
+	}
 	forced_tun_device = -1;
 	channel_clear_permitted_opens();
 }
@@ -206,6 +213,35 @@ auth_parse_options(struct passwd *pw, char *opts, char *file, u_long linenum)
 			opts++;
 			goto next_option;
 		}
+		cp = "log=\"";
+		if (strncasecmp(opts, cp, strlen(cp)) == 0) {
+			opts += strlen(cp);
+			log_auth_option = xmalloc(strlen(opts) + 1);
+			i = 0;
+			while (*opts) {
+				if (*opts == '"')
+					break;
+				if (*opts == '\\' && opts[1] == '"') {
+					opts += 2;
+					log_auth_option[i++] = '"';
+					continue;
+				}
+				log_auth_option[i++] = *opts++;
+			}
+			if (!*opts) {
+				debug("%.100s, line %lu: missing end quote",
+				    file, linenum);
+				auth_debug_add("%.100s, line %lu: missing end quote",
+				    file, linenum);
+				xfree(log_auth_option);
+				log_auth_option = NULL;
+				goto bad_option;
+			}
+			log_auth_option[i] = '\0';
+			auth_debug_add("Log auth option: %.900s", log_auth_option);
+			opts++;
+			goto next_option;
+		}
 		cp = "environment=\"";
 		if (options.permit_user_env &&
 		    strncasecmp(opts, cp, strlen(cp)) == 0) {
diff --git a/auth-options.h b/auth-options.h
index 7455c94..d895849 100644
--- a/auth-options.h
+++ b/auth-options.h
@@ -30,6 +30,7 @@ extern int no_user_rc;
 extern char *forced_command;
 extern struct envstring *custom_environment;
 extern int forced_tun_device;
+extern char *log_auth_option;
 extern int key_is_cert_authority;
 extern char *authorized_principals;

diff --git a/auth.c b/auth.c
index d3663a4..9bb20fc 100644
--- a/auth.c
+++ b/auth.c
@@ -199,14 +199,16 @@ auth_log(Authctxt *authctxt, int authenticated, char *method, char *info)
 	else
 		authmsg = authenticated ? "Accepted" : "Failed";

-	authlog("%s %s for %s%.100s from %.200s port %d%s",
+	authlog("%s %s for %s%.100s from %.200s port %d%s%s%s",
 	    authmsg,
 	    method,
 	    authctxt->valid ? "" : "invalid user ",
 	    authctxt->user,
 	    get_remote_ipaddr(),
 	    get_remote_port(),
-	    info);
+	    info,
+	    log_auth_option?" ":"",
+	    log_auth_option?log_auth_option:"");
 }

 /*
diff --git a/sshd.8 b/sshd.8
index 5c40007..04e0c85 100644
--- a/sshd.8
+++ b/sshd.8
@@ -518,6 +518,8 @@ Also note that this command may be superseded by either a
 .Xr sshd_config 5
 .Cm ForceCommand
 directive or a command embedded in a certificate.
+.It Cm log="text"
+Causes the text specified to be appended to authentication log messages.
 .It Cm environment="NAME=value"
 Specifies that the string is to be added to the environment when
 logging in using this key.


From alex at alex.org.uk  Sun Oct  9 02:56:37 2011
From: alex at alex.org.uk (Alex Bligh)
Date: Sat, 08 Oct 2011 16:56:37 +0100
Subject: [PATCH] add log= directive to authorized_hosts
In-Reply-To: <4E906D7E.8080301@gmail.com>
References: <B1BFE21F4E530F9075AEEA72@nimrod.local>
 <4E906D7E.8080301@gmail.com>
Message-ID: <51D6DA326EAF2A1716C5F61C@nimrod.local>



--On 8 October 2011 17:34:22 +0200 ?ngel Gonz?lez <keisial at gmail.com> 
wrote:

> Although this is interesting for your case, where the authorized_keys
> file is trusted,
> I think it may provide some hole for malicious users with shell access.
> Suppose that there is a script applying a regex to the log, and
> automatically banning
> ips with more than X failures. Then Eve adds a key with log="Invalid user
> root from 192.168.1.1"
> with 192.168.1.1 being the ip of the admin, or other users which make use
> of the machine.
> After a few connections with publick key, Eve has kicked those people
> from the server.

The log line always begins the same way, i.e. the current way, so the
log line would in this case read:

Oct  8 11:04:47 test sshd[18469]: Accepted publickey for eve from 
10.11.12.13 port 55580 ssh2 Invalid user root from 192.168.1.1

Now, if someone is so silly as to parse the log for a regexp and not
write the regexp properly then I think they deserve all they get.

-- 
Alex Bligh

From keisial at gmail.com  Sun Oct  9 05:10:13 2011
From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=)
Date: Sat, 08 Oct 2011 20:10:13 +0200
Subject: [PATCH] add log= directive to authorized_hosts
In-Reply-To: <51D6DA326EAF2A1716C5F61C@nimrod.local>
References: <B1BFE21F4E530F9075AEEA72@nimrod.local>
 <4E906D7E.8080301@gmail.com> <51D6DA326EAF2A1716C5F61C@nimrod.local>
Message-ID: <4E909205.2030003@gmail.com>

Alex Bligh wrote:
> The log line always begins the same way, i.e. the current way, so the
> log line would in this case read:
>
> Oct  8 11:04:47 test sshd[18469]: Accepted publickey for eve from 
> 10.11.12.13 port 55580 ssh2 Invalid user root from 192.168.1.1
>
> Now, if someone is so silly as to parse the log for a regexp and not
> write the regexp properly then I think they deserve all they get.

I know, the problem would be the regex. But I'm sure there are unanchored
regexes in use out there, for parsing those logs.



From alex at alex.org.uk  Sun Oct  9 19:15:24 2011
From: alex at alex.org.uk (Alex Bligh)
Date: Sun, 09 Oct 2011 09:15:24 +0100
Subject: Restricting users using one port
Message-ID: <BC5D281AE93CE7EF7357E2EB@nimrod.local>

I have ssh running on port 22 and (say) port 33333. Port 22 is restricted at
layer 3 so not much can get to it. Port 33333 is open to the world.

I only want to allow one user to authenticated using port 33333, but
all users to authenticate using port 22.

Is there any way to do this without running 2 sshd processes?

-- 
Alex Bligh

From djm at mindrot.org  Sun Oct  9 21:50:05 2011
From: djm at mindrot.org (Damien Miller)
Date: Sun, 9 Oct 2011 21:50:05 +1100 (EST)
Subject: Restricting users using one port
In-Reply-To: <BC5D281AE93CE7EF7357E2EB@nimrod.local>
References: <BC5D281AE93CE7EF7357E2EB@nimrod.local>
Message-ID: <alpine.BSO.2.00.1110092146310.32730@natsu.mindrot.org>

On Sun, 9 Oct 2011, Alex Bligh wrote:

> I have ssh running on port 22 and (say) port 33333. Port 22 is restricted at
> layer 3 so not much can get to it. Port 33333 is open to the world.
> 
> I only want to allow one user to authenticated using port 33333, but
> all users to authenticate using port 22.
> 
> Is there any way to do this without running 2 sshd processes?

At the moment, no. It might be possible to add more Match options to
select using the local connection address and port. E.g.

Match user djm laddr 172.16.0.1 lport 33333
	PasswordAuthentication yes
	PubkeyAuthentication yes
	ChallengeResponseAuthentication yes
Match laddr 172.16.0.1 lport 33333
	PasswordAuthentication no
	PubkeyAuthentication no
	ChallengeResponseAuthentication no

Darren wrote most of the Match code - what do you think, Darren?

-d

From dgoulet at ev0ke.net  Tue Oct 11 03:38:10 2011
From: dgoulet at ev0ke.net (David Goulet)
Date: Mon, 10 Oct 2011 12:38:10 -0400
Subject: Channel life span
Message-ID: <4E931F72.4010307@ev0ke.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Basic context for my questions:

Client (ssh) and server side (sshd) where the client use -L option for a
direct-tcpip channel and forward all requests. (All Linux and openssh version
5.9p1).

$ ssh -L8080:<some-ip>:8181 ...

I noticed that when a third client send data to the local port (8080) used for
forwarding, a channel is created:

...
debug1: channel 1: new [direct-tcpip]
debug1: server_input_channel_open: confirm direct-tcpip
debug3: channel 1: waiting for connection
...

the request then pass through the tunnel, reply comes back and then the channel
receives an EOF (debug2: channel 1: rcvd eof). Both the ssh client and sshd
server agree on closing the channel and it's freed. Seems the normal behavior.

So, I did try, using a third part lib for SSH (libssh2), to recreate a
direct-tcpip channel and *keep* the channel open (not sending the EOF) in order
to send data later on (where the time between writes on the channel is unknown).
However, here is what's happening. After the first write to the channel, I read
the data back (reply), and keep the channel open (don't send the EOF on my
side). A quick 5 seconds later, I get this on the sshd (server side):

debug2: channel 1: read<=0 rfd 8 len 0
debug2: channel 1: read failed
debug2: channel 1: close_read
debug2: channel 1: input open -> drain
debug2: channel 1: ibuf empty
debug2: channel 1: send eof
debug2: channel 1: input drain -> closed

and the channel is *not* usable again for transmission... I have to recreate one...

I did look at the openssh code to understand that behavior since it's not define
in the RFC 4254 that it should "close" after a timeout. I'm sure I am missing
something here that I'm doing wrong but I get this behavior even with the ssh
client in the openssh code tree.

So my questions are: Is it normal for channel to be open/close at *each*
different data transmission ?  and if not, how can I keep a channel alive for an
undefined period of time without having an EOF sent to me from the sshd server.

Thanks to all! I know it's long... but the problem is not that trivial to
explain by mail :P. Feel free to ask for more details!

Cheers!
David
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJOkx9yAAoJEELoaioR9I02drwIAMh9mYLpJYaM3ss5S7cD5BvD
J6/SzDMOgceYijVqgU5JIZJj2l9H7rwDvwZAj178cUv5DSjfHfF1X1WEGALTI6EA
son9usUM0zhkJh+Nsg4Wl2wWPpi0UOLmfQ4yb4dMkxpAU8QrcVCYE0PqCjSVRdcZ
A2lOZdAjEvwnR4QJhiRC2Yxj+h88x/wo0v03ysW9M0bTUj/bLCD8EaNlkopOU1+I
xGDhhcTDpq+e2RYf2wMWBzRRBhqEcNpaUqOSCkiKw4wfdq+8m3UmClRUBngTuPp0
y+Ldb7L81Vtt0niCuIMbj4qjxTSR9KxBlD0j2RMz/w4TCJhDwDRJtjFrx82GLRE=
=jdEM
-----END PGP SIGNATURE-----

From djm at mindrot.org  Tue Oct 11 06:27:55 2011
From: djm at mindrot.org (Damien Miller)
Date: Tue, 11 Oct 2011 06:27:55 +1100 (EST)
Subject: Channel life span
In-Reply-To: <4E931F72.4010307@ev0ke.net>
References: <4E931F72.4010307@ev0ke.net>
Message-ID: <alpine.BSO.2.00.1110110624001.1459@natsu.mindrot.org>

On Mon, 10 Oct 2011, David Goulet wrote:

> So, I did try, using a third part lib for SSH (libssh2), to recreate
> a direct-tcpip channel and *keep* the channel open (not sending the
> EOF) in order to send data later on (where the time between writes on
> the channel is unknown). However, here is what's happening. After the
> first write to the channel, I read the data back (reply), and keep the
> channel open (don't send the EOF on my side). A quick 5 seconds later,
> I get this on the sshd (server side):
>
> debug2: channel 1: read<=0 rfd 8 len 0
> debug2: channel 1: read failed

Whatever you are talking to on the server has closed its standard output
or otherwise done something that triggered a failed read. The code that
emits this message is channels.c:channel_handle_rfd() and if you read it,
you'll see that there is no other way that this message can be generated.

-d

From alex at alex.org.uk  Tue Oct 11 06:36:27 2011
From: alex at alex.org.uk (Alex Bligh)
Date: Mon, 10 Oct 2011 20:36:27 +0100
Subject: scp with different users
Message-ID: <DE6B6E00D9A8E84BD22B9804@nimrod.local>

This may be a dumb question, but is there any reason why
  scp a at b:c d:
fails, where
  scp a at b:c .
  scp c d:
succeeds?

I get "Host key verification failed.". I'm using nothing more complex
than RSA authorized_hosts based authentication.

I'm seeing this on openssh-client 1:5.8p1-1ubuntu3 and
OS-X 10.6 OpenSSH_5.2p1, OpenSSL 0.9.8r 8 Feb 2011.

-- 
Alex Bligh

From peter at stuge.se  Tue Oct 11 06:40:54 2011
From: peter at stuge.se (Peter Stuge)
Date: Mon, 10 Oct 2011 21:40:54 +0200
Subject: Channel life span
In-Reply-To: <4E931F72.4010307@ev0ke.net>
References: <4E931F72.4010307@ev0ke.net>
Message-ID: <20111010194054.9818.qmail@stuge.se>

Hi,

David Goulet wrote:
> $ ssh -L8080:<some-ip>:8181 ...
> 
> I noticed that when a third client

What are the other two clients you refer to?

What is this third client you are refering to?

What protocols are being used? 8080 is usually HTTP.

On IRC yesterday you told me that you use SSH inside the tunnel.


> send data to the local port (8080) used for forwarding, a channel
> is created:

"send data" is not so accurate. When you start ssh with -L, the
client will socket() bind() listen() and accept() on port 8080 on the
system where the client runs.

When a program later does socket() and connect() to port 8080 where
the ssh client is listening, *then* the ssh client tells the sshd it
has logged into that the client side wants to open a direct-tcpip
channel, and to where. The sshd then does socket() and connect() and
then passes data between wherever it connected to, and the channel.
I find that this is very clearly described in the SSH RFC that covers
port forwarding. I urge you to read it.


> the request then pass through the tunnel,

What type of request?


> reply comes back

What type of reply?

A complete understanding of the protocol you use inside the tunnel is
required for port forwarding over SSH just like it is for any other
network transport.


> and then the channel receives an EOF

Also not so accurate, "the channel" can not receive anything, it is
important to clearly understand what happens where, and why. Is this
EOF received by the ssh client or the sshd?


> So, I did try, using a third part lib for SSH (libssh2), to recreate
> a direct-tcpip channel and *keep* the channel open (not sending the
> EOF) in order to send data later on (where the time between writes
> on the channel is unknown). However, here is what's happening.
> After the first write to the channel, I read the data back (reply),

You must clearly say what you are communicating over the channel in
order to get any help.


> and keep the channel open (don't send the EOF on my side).

What is your side?

What are you communicating?

What is your idea of "the EOF"?
I mean: How would you "send the EOF" if you wanted to?


> A quick 5 seconds later, I get this on the sshd (server side):
> 
> debug2: channel 1: read<=0 rfd 8 len 0
> debug2: channel 1: read failed

I find this completely clear. I'm glad you also provided the
information that this happens on the server side.

So you already know that the sshd has connect() somewhere and is
constantly transferring data between that somewhere and the channel.

Here the sshd tells you that on the outgoing TCP connection that it
opened on behalf of channel 1, the read() system call returned <= 0,
which means that either there is a local OS error or that the other
end of this TCP connection made by sshd has closed the connection.


> debug2: channel 1: send eof

And thus sshd notifies the ssh client that there will be no more data
on this channel.


> and the channel is *not* usable again for transmission...

Obviously not, the TCP connection from sshd that was used to deliver
data received by sshd in the channel has been closed, so how would
you use the channel anymore?


> I did look at the openssh code to understand that behavior since
> it's not define in the RFC 4254 that it should "close" after a
> timeout.

There is no timeout involved. As I tried to explain to you already
yesterday the behavior you are seeing depends completely on the
server you are talking to and the protocol that you are using.


//Peter

From peter at stuge.se  Tue Oct 11 08:27:44 2011
From: peter at stuge.se (Peter Stuge)
Date: Mon, 10 Oct 2011 23:27:44 +0200
Subject: scp with different users
In-Reply-To: <DE6B6E00D9A8E84BD22B9804@nimrod.local>
References: <DE6B6E00D9A8E84BD22B9804@nimrod.local>
Message-ID: <20111010212744.24205.qmail@stuge.se>

Alex Bligh wrote:
> why
>  scp a at b:c d:
> fails, where
>  scp a at b:c .
>  scp c d:
> succeeds?

The former copies from c to d while the latter first copies from c to .
and then from . to d.


//Peter

From alex at alex.org.uk  Tue Oct 11 08:59:42 2011
From: alex at alex.org.uk (Alex Bligh)
Date: Mon, 10 Oct 2011 22:59:42 +0100
Subject: scp with different users
In-Reply-To: <20111010212744.24205.qmail@stuge.se>
References: <DE6B6E00D9A8E84BD22B9804@nimrod.local>
 <20111010212744.24205.qmail@stuge.se>
Message-ID: <480D885F76811904AAA08EAB@nimrod.local>

Peter,

--On 10 October 2011 23:27:44 +0200 Peter Stuge <peter at stuge.se> wrote:

> Alex Bligh wrote:
>> why
>>  scp a at b:c d:
>> fails, where
>>  scp a at b:c .
>>  scp c d:
>> succeeds?
>
> The former copies from c to d while the latter first copies from c to .
> and then from . to d.

The former copies file 'c' from user 'a' at host 'b' to the current
user at host 'd'.

The latter does the same, but via a file c in the current directory
on the current host.

What I am asking is why the former can succeed but the latter fail if
the local machine can log into both hosts. IE authenticating to
each of them individually works, but not when they are both on the
same scp command line.

-- 
Alex Bligh

From peter at stuge.se  Tue Oct 11 09:50:21 2011
From: peter at stuge.se (Peter Stuge)
Date: Tue, 11 Oct 2011 00:50:21 +0200
Subject: scp with different users
In-Reply-To: <480D885F76811904AAA08EAB@nimrod.local>
References: <DE6B6E00D9A8E84BD22B9804@nimrod.local>
 <20111010212744.24205.qmail@stuge.se> <480D885F76811904AAA08EAB@nimrod.local>
Message-ID: <20111010225021.3168.qmail@stuge.se>

Alex Bligh wrote:
>> Alex Bligh wrote:
>>> why
>>>  scp a at b:c d:
>>> fails, where
>>>  scp a at b:c .
>>>  scp c d:
>>> succeeds?
>>
>> The former copies from c to d while the latter first copies from c to .
>> and then from . to d.
>
> The former copies file 'c' from user 'a' at host 'b' to the current
> user at host 'd'.

Sorry, where I wrote c I meant to write b.


> What I am asking is why the former can succeed but the latter fail

What you asked before was the opposite. Which is it? :)

Does ssh a at b ssh d work?

Is the username on d also a, or is the username on d the same as on
the local machine?


//Peter

From alex at alex.org.uk  Tue Oct 11 09:59:54 2011
From: alex at alex.org.uk (Alex Bligh)
Date: Mon, 10 Oct 2011 23:59:54 +0100
Subject: scp with different users
In-Reply-To: <20111010225021.3168.qmail@stuge.se>
References: <DE6B6E00D9A8E84BD22B9804@nimrod.local>
 <20111010212744.24205.qmail@stuge.se>
 <480D885F76811904AAA08EAB@nimrod.local> <20111010225021.3168.qmail@stuge.se>
Message-ID: <1C7A75FD64A93A1922A5025A@nimrod.local>

Peter,

--On 11 October 2011 00:50:21 +0200 Peter Stuge <peter at stuge.se> wrote:

>> The former copies file 'c' from user 'a' at host 'b' to the current
>> user at host 'd'.
>
> Sorry, where I wrote c I meant to write b.

No problem

>> What I am asking is why the former can succeed but the latter fail
>
> What you asked before was the opposite. Which is it? :)

I wrote it the wrong way around - I think that makes us 'one all' :-)

Copying via the intermediate file works. Copying between hosts b and d
as a single command fails.

> Does ssh a at b ssh d work?

"ssh a at b" works
"ssh d" works
"ssh a at b ssh d" (as a single command) will not work, as b does not have
the private key to get to d, only localhost does.

I had presumed (perhaps wrongly), that scp was opening two sessions,
one to b and one to d, and acting as a sort of intermediary.

> Is the username on d also a, or is the username on d the same as on
> the local machine?

The username on d is the same as on the local machine.

-- 
Alex Bligh

From peter at stuge.se  Tue Oct 11 10:03:21 2011
From: peter at stuge.se (Peter Stuge)
Date: Tue, 11 Oct 2011 01:03:21 +0200
Subject: scp with different users
In-Reply-To: <1C7A75FD64A93A1922A5025A@nimrod.local>
References: <DE6B6E00D9A8E84BD22B9804@nimrod.local>
 <20111010212744.24205.qmail@stuge.se> <480D885F76811904AAA08EAB@nimrod.local>
 <20111010225021.3168.qmail@stuge.se> <1C7A75FD64A93A1922A5025A@nimrod.local>
Message-ID: <20111010230321.5132.qmail@stuge.se>

Alex Bligh wrote:
>> Does ssh a at b ssh d work?
>
> "ssh a at b" works
> "ssh d" works
> "ssh a at b ssh d" (as a single command) will not work,

Then scp from b to d will also not work.


> as b does not have the private key to get to d, only localhost
> does.

You can use ssh-agent to make direct communication from b to d work
while the key remains on localhost.


> I had presumed (perhaps wrongly), that scp was opening two
> sessions, one to b and one to d, and acting as a sort of
> intermediary.

Yes, wrongly.


>> Is the username on d also a, or is the username on d the same as on
>> the local machine?
>
> The username on d is the same as on the local machine.

Cool. It doesn't work because a at b can not authenticate for d. scp
does not first download data locally unless you explicitly tell it
to.


//Peter

From alex at alex.org.uk  Tue Oct 11 10:06:38 2011
From: alex at alex.org.uk (Alex Bligh)
Date: Tue, 11 Oct 2011 00:06:38 +0100
Subject: scp with different users
In-Reply-To: <20111010230321.5132.qmail@stuge.se>
References: <DE6B6E00D9A8E84BD22B9804@nimrod.local>
 <20111010212744.24205.qmail@stuge.se>
 <480D885F76811904AAA08EAB@nimrod.local> <20111010225021.3168.qmail@stuge.se>
 <1C7A75FD64A93A1922A5025A@nimrod.local> <20111010230321.5132.qmail@stuge.se>
Message-ID: <E757F8CEE7212BCB45A33F43@nimrod.local>



--On 11 October 2011 01:03:21 +0200 Peter Stuge <peter at stuge.se> wrote:

> Cool. It doesn't work because a at b can not authenticate for d. scp
> does not first download data locally unless you explicitly tell it
> to.

Ah - thanks. I said it was a dumb question :-)

-- 
Alex Bligh

From ricky at rzhou.org  Thu Oct 13 20:18:43 2011
From: ricky at rzhou.org (Ricky Zhou)
Date: Thu, 13 Oct 2011 05:18:43 -0400
Subject: [PATCH] Fix control persist and stdio forward interaction
Message-ID: <20111013091843.GA4090@alpha.rzhou.org>

As reported earlier at

https://lists.mindrot.org/pipermail/openssh-unix-dev/2011-March/029441.html

there is some strange interaction between ControlPersist and ssh -W that
breaks things if you're using both.  Specifically, ssh -W host:port with
ControlPersist enabled opens up two connections to host:port and sends
data from both back.

I think this is happening because channel_connect_stdio_fwd is being
called twice, once in client_setup_stdio_fwd, which is called from
ssh_init_forwarding, and once in process_mux_stdio_fwd, which is
called once the client process starts talking to the master process.

It looks like the way ControlPersist is implemented, the process forks,
with the child becoming the master process and the child making its
connection through that.   Thus, it seems like a reasonable fix to not
call client_setup_stdio_fwd if need_controlpersist_detach is set, and
just allow it to happen later.

Does the attached patch look OK?

Thanks,
Ricky
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20111013/1801e07e/attachment.bin>

From ricky at rzhou.org  Thu Oct 13 20:24:51 2011
From: ricky at rzhou.org (Ricky Zhou)
Date: Thu, 13 Oct 2011 05:24:51 -0400
Subject: [PATCH] Fix control persist and stdio forward interaction
In-Reply-To: <20111013091843.GA4090@alpha.rzhou.org>
References: <20111013091843.GA4090@alpha.rzhou.org>
Message-ID: <20111013092451.GB4090@alpha.rzhou.org>

On 2011-10-13 05:18:43 AM, Ricky Zhou wrote:
> Does the attached patch look OK?
Oops, looks like I forgot to attach the patch, so here it is.

Thanks,
Ricky
-------------- next part --------------
Index: ssh.c
===================================================================
RCS file: /cvs/openssh/ssh.c,v
retrieving revision 1.362
diff -u -r1.362 ssh.c
--- ssh.c	2 Oct 2011 07:59:03 -0000	1.362
+++ ssh.c	13 Oct 2011 09:16:27 -0000
@@ -1087,9 +1087,16 @@
 		if (!compat20) {
 			fatal("stdio forwarding require Protocol 2");
 		}
-		if (!client_setup_stdio_fwd(stdio_forward_host,
-		    stdio_forward_port))
-			fatal("Failed to connect in stdio forward mode.");
+
+		/*
+		 * If control persist is on, the stdio fwd is setup on the
+		 * master through the muxserver.
+		 */
+		if (!need_controlpersist_detach) {
+			if (!client_setup_stdio_fwd(stdio_forward_host,
+			    stdio_forward_port))
+				fatal("Failed to connect in stdio forward mode.");
+		}
 	}
 
 	/* Initiate local TCP/IP port forwardings. */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20111013/ab62c998/attachment.bin>

From glenn at zewt.org  Sat Oct 15 07:55:55 2011
From: glenn at zewt.org (Glenn Maynard)
Date: Fri, 14 Oct 2011 16:55:55 -0400
Subject: Determining the port assigned by -R 0
Message-ID: <CABirCh9OcDMx=i8r9t0HBwsa8ALBQpkjysXbi1LTHirKSFYKBg@mail.gmail.com>

It's difficult to programmatically determine the port dynamically assigned
by -R 0.  The port is output in plain (and presumably localized) text, but
I've found that by far the most common use of this is for scripts.

Is there currently any sane way to get this information?  For the short term
I'll probably just parse the plaintext "Allocated port..." message, but
that's obviously not a reliable solution.  It would be helpful if a list of
forwarded ports was stored in a parsable environment variable, as with
SSH_CLIENT.

-- 
Glenn Maynard

From djm at mindrot.org  Sat Oct 15 10:13:57 2011
From: djm at mindrot.org (Damien Miller)
Date: Sat, 15 Oct 2011 10:13:57 +1100 (EST)
Subject: Determining the port assigned by -R 0
In-Reply-To: <CABirCh9OcDMx=i8r9t0HBwsa8ALBQpkjysXbi1LTHirKSFYKBg@mail.gmail.com>
References: <CABirCh9OcDMx=i8r9t0HBwsa8ALBQpkjysXbi1LTHirKSFYKBg@mail.gmail.com>
Message-ID: <alpine.BSO.2.00.1110151010250.11833@natsu.mindrot.org>

On Fri, 14 Oct 2011, Glenn Maynard wrote:

> It's difficult to programmatically determine the port dynamically assigned
> by -R 0.  The port is output in plain (and presumably localized) text, but
> I've found that by far the most common use of this is for scripts.
> 
> Is there currently any sane way to get this information?  For the short term
> I'll probably just parse the plaintext "Allocated port..." message, but
> that's obviously not a reliable solution.  It would be helpful if a list of
> forwarded ports was stored in a parsable environment variable, as with
> SSH_CLIENT.

It's easier if you use the multiplexing socket. 

ssh -O forward -R0:xxx:yyy host

will print the allocated port to stdout on success.

From g+openssh at cobb.uk.net  Sun Oct 16 22:30:14 2011
From: g+openssh at cobb.uk.net (Graham Cobb)
Date: Sun, 16 Oct 2011 12:30:14 +0100
Subject: Interop problem with old dropbear and new openssh
In-Reply-To: <201109302245.04560.g+openssh@cobb.uk.net>
References: <201109302245.04560.g+openssh@cobb.uk.net>
Message-ID: <201110161230.22719.g+openssh@cobb.uk.net>

On Friday 30 September 2011 22:45:03 Graham Cobb wrote:
> However, recently I upgraded one of my desktops and I can no longer connect
> to the router.  Dropbear on the router is exiting with:
> 
> exit before auth: bad buf_getwriteptr
> 
> Looking at the output from ssh -vv, the problem occurs right after
> 
> debug1: sending SSH2_MSG_KEXDH_INIT
> debug1: expecting SSH2_MSG_KEXDH_REPLY
> 
> The desktop is running "SSH-2.0-OpenSSH_5.9p1 Debian-1" (it failed with 5.8
> as well).  However, another desktop still running "SSH-2.0-OpenSSH_5.5p1
> Debian-6" still works fine.  The config files are identical and I can't
> find anything in the changelog between those versions which looks like it
> would affect the content of that message.

Just to close off this thread, in case anyone finds it in the future.  The 
problem is definitely a dropbear bug.  It is broken in dropbear 0.44 but works 
with dropbear 0.53.1.  I found the OpenSSH code changes which trigger the bug 
and there are no option settings which can workround the dropbear problem.

Thanks to Damien for his help.

Graham

From dtucker at zip.com.au  Mon Oct 17 00:08:57 2011
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 17 Oct 2011 00:08:57 +1100
Subject: Restricting users using one port
In-Reply-To: <alpine.BSO.2.00.1110092146310.32730@natsu.mindrot.org>
References: <BC5D281AE93CE7EF7357E2EB@nimrod.local>
 <alpine.BSO.2.00.1110092146310.32730@natsu.mindrot.org>
Message-ID: <20111016130857.GA29306@gate.dtucker.net>

On Sun, Oct 09, 2011 at 09:50:05PM +1100, Damien Miller wrote:
> On Sun, 9 Oct 2011, Alex Bligh wrote:
> > I have ssh running on port 22 and (say) port 33333. Port 22 is restricted at
> > layer 3 so not much can get to it. Port 33333 is open to the world.
> > 
> > I only want to allow one user to authenticated using port 33333, but
> > all users to authenticate using port 22.
[...]
> 
> At the moment, no. It might be possible to add more Match options to
> select using the local connection address and port. E.g.
[...]
> Darren wrote most of the Match code - what do you think, Darren?

(apologies if this is a duplicate, my previous reply seems to have been
eaten somewhere)

It's feasible.  The initial Match processing is done just after the
client sends the username so both the local address and port are known
and there should be no additional hooks needed.

I'd suggest calling them LocalAddress and LocalPort (or ServerAddress
and ServerPort) though.

Attached are two patches: openssh-match-struct.patch which moves the
items that are checked to a struct, and
openssh-match-localaddrport.patch which implements the requested
functionality.  (You only need the latter to try it, the former is just
for review).

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
-------------- next part --------------
Index: auth.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/auth.c,v
retrieving revision 1.149
diff -u -p -r1.149 auth.c
--- auth.c	29 May 2011 11:40:42 -0000	1.149
+++ auth.c	10 Oct 2011 04:44:52 -0000
@@ -544,9 +544,12 @@ getpwnamallow(const char *user)
 #endif
 #endif
 	struct passwd *pw;
+	extern ConnectionInfo connection_info;
 
-	parse_server_match_config(&options, user,
-	    get_canonical_hostname(options.use_dns), get_remote_ipaddr());
+	connection_info.user = user;
+	connection_info.host = get_canonical_hostname(options.use_dns);
+	connection_info.address = get_remote_ipaddr();
+	parse_server_match_config(&options, &connection_info);
 
 #if defined(_AIX) && defined(HAVE_SETAUTHDB)
 	aix_setauthdb(user);
Index: servconf.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/servconf.c,v
retrieving revision 1.220
diff -u -p -r1.220 servconf.c
--- servconf.c	2 Oct 2011 07:57:38 -0000	1.220
+++ servconf.c	10 Oct 2011 05:40:13 -0000
@@ -598,19 +598,19 @@ out:
 }
 
 static int
-match_cfg_line(char **condition, int line, const char *user, const char *host,
-    const char *address)
+match_cfg_line(char **condition, int line, ConnectionInfo *ci)
 {
 	int result = 1;
 	char *arg, *attrib, *cp = *condition;
 	size_t len;
 
-	if (user == NULL)
+	if (ci == NULL)
 		debug3("checking syntax for 'Match %s'", cp);
 	else
 		debug3("checking match for '%s' user %s host %s addr %s", cp,
-		    user ? user : "(null)", host ? host : "(null)",
-		    address ? address : "(null)");
+		    ci->user ? ci->user : "(null)",
+		    ci->host ? ci->host : "(null)",
+		    ci->address ? ci->address : "(null)");
 
 	while ((attrib = strdelim(&cp)) && *attrib != '\0') {
 		if ((arg = strdelim(&cp)) == NULL || *arg == '\0') {
@@ -619,37 +619,45 @@ match_cfg_line(char **condition, int lin
 		}
 		len = strlen(arg);
 		if (strcasecmp(attrib, "user") == 0) {
-			if (!user) {
+			if (ci == NULL || ci->user == NULL) {
 				result = 0;
 				continue;
 			}
-			if (match_pattern_list(user, arg, len, 0) != 1)
+			if (match_pattern_list(ci->user, arg, len, 0) != 1)
 				result = 0;
 			else
 				debug("user %.100s matched 'User %.100s' at "
-				    "line %d", user, arg, line);
+				    "line %d", ci->user, arg, line);
 		} else if (strcasecmp(attrib, "group") == 0) {
-			switch (match_cfg_line_group(arg, line, user)) {
+			if (ci == NULL || ci->user == NULL) {
+				result = 0;
+				continue;
+			}
+			switch (match_cfg_line_group(arg, line, ci->user)) {
 			case -1:
 				return -1;
 			case 0:
 				result = 0;
 			}
 		} else if (strcasecmp(attrib, "host") == 0) {
-			if (!host) {
+			if (ci == NULL || ci->host == NULL) {
 				result = 0;
 				continue;
 			}
-			if (match_hostname(host, arg, len) != 1)
+			if (match_hostname(ci->host, arg, len) != 1)
 				result = 0;
 			else
 				debug("connection from %.100s matched 'Host "
-				    "%.100s' at line %d", host, arg, line);
+				    "%.100s' at line %d", ci->host, arg, line);
 		} else if (strcasecmp(attrib, "address") == 0) {
-			switch (addr_match_list(address, arg)) {
+			if (ci == NULL || ci->address == NULL) {
+				result = 0;
+				continue;
+			}
+			switch (addr_match_list(ci->address, arg)) {
 			case 1:
 				debug("connection from %.100s matched 'Address "
-				    "%.100s' at line %d", address, arg, line);
+				    "%.100s' at line %d", ci->address, arg, line);
 				break;
 			case 0:
 			case -1:
@@ -663,7 +671,7 @@ match_cfg_line(char **condition, int lin
 			return -1;
 		}
 	}
-	if (user != NULL)
+	if (ci != NULL)
 		debug3("match %sfound", result ? "" : "not ");
 	*condition = cp;
 	return result;
@@ -710,8 +718,8 @@ static const struct multistate multistat
 
 int
 process_server_config_line(ServerOptions *options, char *line,
-    const char *filename, int linenum, int *activep, const char *user,
-    const char *host, const char *address)
+    const char *filename, int linenum, int *activep,
+    ConnectionInfo *connectinfo)
 {
 	char *cp, **charptr, *arg, *p;
 	int cmdline = 0, *intptr, value, value2, n;
@@ -742,7 +750,7 @@ process_server_config_line(ServerOptions
 	if (*activep && opcode != sMatch)
 		debug3("%s:%d setting %s %s", filename, linenum, arg, cp);
 	if (*activep == 0 && !(flags & SSHCFG_MATCH)) {
-		if (user == NULL) {
+		if (connectinfo == NULL) {
 			fatal("%s line %d: Directive '%s' is not allowed "
 			    "within a Match block", filename, linenum, arg);
 		} else { /* this is a directive we have already processed */
@@ -1313,7 +1321,7 @@ process_server_config_line(ServerOptions
 		if (cmdline)
 			fatal("Match directive not supported as a command-line "
 			   "option");
-		value = match_cfg_line(&cp, linenum, user, host, address);
+		value = match_cfg_line(&cp, linenum, connectinfo);
 		if (value < 0)
 			fatal("%s line %d: Bad Match condition", filename,
 			    linenum);
@@ -1451,16 +1459,48 @@ load_server_config(const char *filename,
 }
 
 void
-parse_server_match_config(ServerOptions *options, const char *user,
-    const char *host, const char *address)
+parse_server_match_config(ServerOptions *options, ConnectionInfo *connectinfo)
 {
 	ServerOptions mo;
 
 	initialize_server_options(&mo);
-	parse_server_config(&mo, "reprocess config", &cfg, user, host, address);
+	parse_server_config(&mo, "reprocess config", &cfg, connectinfo);
 	copy_set_server_options(options, &mo, 0);
 }
 
+int parse_server_match_testspec(ConnectionInfo *ci, char *spec)
+{
+	char *p;
+
+	while ((p = strsep(&spec, ",")) && *p != '\0') {
+		if (strncmp(p, "addr=", 5) == 0)
+			ci->address = xstrdup(p + 5);
+		else if (strncmp(p, "host=", 5) == 0)
+			ci->host = xstrdup(p + 5);
+		else if (strncmp(p, "user=", 5) == 0)
+			ci->user = xstrdup(p + 5);
+		else {
+			fprintf(stderr, "Invalid test mode specification %s\n",
+			   p);
+			return -1;
+		}
+	}
+	return 0;
+}
+
+/*
+ * returns 1 for a complete spec, 0 for partial spec and -1 for an
+ * empty spec.
+ */
+int server_match_spec_complete(ConnectionInfo *ci)
+{
+	if (ci->user && ci->host && ci->address)
+		return 1;	/* complete */
+	if (!ci->user && !ci->host && !ci->address)
+		return -1;	/* empty */
+	return 0;	/* partial */
+}
+
 /* Helper macros */
 #define M_CP_INTOPT(n) do {\
 	if (src->n != -1) \
@@ -1534,7 +1574,7 @@ copy_set_server_options(ServerOptions *d
 
 void
 parse_server_config(ServerOptions *options, const char *filename, Buffer *conf,
-    const char *user, const char *host, const char *address)
+    ConnectionInfo *connectinfo)
 {
 	int active, linenum, bad_options = 0;
 	char *cp, *obuf, *cbuf;
@@ -1542,11 +1582,11 @@ parse_server_config(ServerOptions *optio
 	debug2("%s: config %s len %d", __func__, filename, buffer_len(conf));
 
 	obuf = cbuf = xstrdup(buffer_ptr(conf));
-	active = user ? 0 : 1;
+	active = connectinfo ? 0 : 1;
 	linenum = 1;
 	while ((cp = strsep(&cbuf, "\n")) != NULL) {
 		if (process_server_config_line(options, cp, filename,
-		    linenum++, &active, user, host, address) != 0)
+		    linenum++, &active, connectinfo) != 0)
 			bad_options++;
 	}
 	xfree(obuf);
Index: servconf.h
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/servconf.h,v
retrieving revision 1.91
diff -u -p -r1.91 servconf.h
--- servconf.h	22 Jun 2011 22:30:03 -0000	1.91
+++ servconf.h	10 Oct 2011 04:27:54 -0000
@@ -168,6 +168,15 @@ typedef struct {
 	char   *authorized_principals_file;
 }       ServerOptions;
 
+
+/* Information about the incoming connection as used by Match */
+typedef struct {
+	const char *user;
+	const char *host;	/* possibly resolved hostname */
+	const char *address; 	/* remote address */
+} ConnectionInfo;
+
+
 /*
  * These are string config options that must be copied between the
  * Match sub-config and the main config, and must be sent from the
@@ -185,12 +194,13 @@ typedef struct {
 void	 initialize_server_options(ServerOptions *);
 void	 fill_default_server_options(ServerOptions *);
 int	 process_server_config_line(ServerOptions *, char *, const char *, int,
-	     int *, const char *, const char *, const char *);
+	     int *, ConnectionInfo *);
 void	 load_server_config(const char *, Buffer *);
 void	 parse_server_config(ServerOptions *, const char *, Buffer *,
-	     const char *, const char *, const char *);
-void	 parse_server_match_config(ServerOptions *, const char *, const char *,
-	     const char *);
+	     ConnectionInfo *);
+void	 parse_server_match_config(ServerOptions *, ConnectionInfo *);
+int	 parse_server_match_testspec(ConnectionInfo *, char *);
+int	 server_match_spec_complete(ConnectionInfo *);
 void	 copy_set_server_options(ServerOptions *, ServerOptions *, int);
 void	 dump_config(ServerOptions *);
 char	*derelativise_path(const char *);
Index: sshd.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/sshd.c,v
retrieving revision 1.410
diff -u -p -r1.410 sshd.c
--- sshd.c	2 Oct 2011 08:10:14 -0000	1.410
+++ sshd.c	10 Oct 2011 04:45:55 -0000
@@ -143,6 +143,9 @@ extern char *__progname;
 /* Server configuration options. */
 ServerOptions options;
 
+/* Connection information used by Match */
+ConnectionInfo connection_info;
+
 /* Name of the server configuration file. */
 char *config_file_name = _PATH_SERVER_CONFIG_FILE;
 
@@ -1320,9 +1323,8 @@ main(int ac, char **av)
 	int opt, i, j, on = 1;
 	int sock_in = -1, sock_out = -1, newsock = -1;
 	const char *remote_ip;
-	char *test_user = NULL, *test_host = NULL, *test_addr = NULL;
 	int remote_port;
-	char *line, *p, *cp;
+	char *line;
 	int config_s[2] = { -1 , -1 };
 	u_int64_t ibytes, obytes;
 	mode_t new_umask;
@@ -1449,20 +1451,9 @@ main(int ac, char **av)
 			test_flag = 2;
 			break;
 		case 'C':
-			cp = optarg;
-			while ((p = strsep(&cp, ",")) && *p != '\0') {
-				if (strncmp(p, "addr=", 5) == 0)
-					test_addr = xstrdup(p + 5);
-				else if (strncmp(p, "host=", 5) == 0)
-					test_host = xstrdup(p + 5);
-				else if (strncmp(p, "user=", 5) == 0)
-					test_user = xstrdup(p + 5);
-				else {
-					fprintf(stderr, "Invalid test "
-					    "mode specification %s\n", p);
-					exit(1);
-				}
-			}
+			if (parse_server_match_testspec(&connection_info,
+			    optarg) == -1)
+				exit(1);
 			break;
 		case 'u':
 			utmp_len = (u_int)strtonum(optarg, 0, MAXHOSTNAMELEN+1, NULL);
@@ -1474,7 +1465,7 @@ main(int ac, char **av)
 		case 'o':
 			line = xstrdup(optarg);
 			if (process_server_config_line(&options, line,
-			    "command-line", 0, NULL, NULL, NULL, NULL) != 0)
+			    "command-line", 0, NULL, NULL) != 0)
 				exit(1);
 			xfree(line);
 			break;
@@ -1530,13 +1521,10 @@ main(int ac, char **av)
 	 * the parameters we need.  If we're not doing an extended test,
 	 * do not silently ignore connection test params.
 	 */
-	if (test_flag >= 2 &&
-	   (test_user != NULL || test_host != NULL || test_addr != NULL)
-	    && (test_user == NULL || test_host == NULL || test_addr == NULL))
+	if (test_flag >= 2 && server_match_spec_complete(&connection_info) == 0)
 		fatal("user, host and addr are all required when testing "
 		   "Match configs");
-	if (test_flag < 2 && (test_user != NULL || test_host != NULL ||
-	    test_addr != NULL))
+	if (test_flag < 2 && server_match_spec_complete(&connection_info) >= 0)
 		fatal("Config test connection parameter (-C) provided without "
 		   "test mode (-T)");
 
@@ -1548,7 +1536,7 @@ main(int ac, char **av)
 		load_server_config(config_file_name, &cfg);
 
 	parse_server_config(&options, rexeced_flag ? "rexec" : config_file_name,
-	    &cfg, NULL, NULL, NULL);
+	    &cfg, NULL);
 
 	seed_rng();
 
@@ -1710,9 +1698,8 @@ main(int ac, char **av)
 	}
 
 	if (test_flag > 1) {
-		if (test_user != NULL && test_addr != NULL && test_host != NULL)
-			parse_server_match_config(&options, test_user,
-			    test_host, test_addr);
+		if (server_match_spec_complete(&connection_info) == 1)
+			parse_server_match_config(&options, &connection_info);
 		dump_config(&options);
 	}
 
Index: regress/cfgmatch.sh
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/regress/cfgmatch.sh,v
retrieving revision 1.8
diff -u -p -r1.8 cfgmatch.sh
--- regress/cfgmatch.sh	17 Aug 2011 02:08:18 -0000	1.8
+++ regress/cfgmatch.sh	11 Oct 2011 00:47:48 -0000
@@ -52,6 +52,11 @@ echo "PermitOpen 127.0.0.1:1" >>$OBJ/ssh
 echo "Match Address 127.0.0.1" >>$OBJ/sshd_proxy
 echo "PermitOpen 127.0.0.1:$PORT" >>$OBJ/sshd_proxy
 
+# Plus some that won't match just to exercise the parsers
+echo "Match Group nosuchgroup" >>$OBJ/sshd_config
+echo "Match Host nosuchhost" >>$OBJ/sshd_config
+
+
 start_sshd
 
 #set -x
-------------- next part --------------
Index: auth.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh/auth.c,v
retrieving revision 1.149
diff -u -p -r1.149 auth.c
--- auth.c	29 May 2011 11:40:42 -0000	1.149
+++ auth.c	10 Oct 2011 05:45:34 -0000
@@ -544,9 +544,14 @@ getpwnamallow(const char *user)
 #endif
 #endif
 	struct passwd *pw;
+	extern ConnectionInfo connection_info;
 
-	parse_server_match_config(&options, user,
-	    get_canonical_hostname(options.use_dns), get_remote_ipaddr());
+	connection_info.user = user;
+	connection_info.host = get_canonical_hostname(options.use_dns);
+	connection_info.address = get_remote_ipaddr();
+	connection_info.laddress = get_local_ipaddr(packet_get_connection_in());
+	connection_info.lport = get_local_port();
+	parse_server_match_config(&options, &connection_info);
 
 #if defined(_AIX) && defined(HAVE_SETAUTHDB)
 	aix_setauthdb(user);
Index: servconf.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh/servconf.c,v
retrieving revision 1.220
diff -u -p -r1.220 servconf.c
--- servconf.c	2 Oct 2011 07:57:38 -0000	1.220
+++ servconf.c	10 Oct 2011 06:12:53 -0000
@@ -598,19 +598,20 @@ out:
 }
 
 static int
-match_cfg_line(char **condition, int line, const char *user, const char *host,
-    const char *address)
+match_cfg_line(char **condition, int line, ConnectionInfo *ci)
 {
-	int result = 1;
+	int result = 1, port;
 	char *arg, *attrib, *cp = *condition;
 	size_t len;
 
-	if (user == NULL)
+	if (ci == NULL)
 		debug3("checking syntax for 'Match %s'", cp);
 	else
-		debug3("checking match for '%s' user %s host %s addr %s", cp,
-		    user ? user : "(null)", host ? host : "(null)",
-		    address ? address : "(null)");
+		debug3("checking match for '%s' user %s host %s addr %s "
+		    "laddr %s lport %d", cp, ci->user ? ci->user : "(null)",
+		    ci->host ? ci->host : "(null)",
+		    ci->address ? ci->address : "(null)",
+		    ci->laddress ? ci->laddress : "(null)", ci->lport);
 
 	while ((attrib = strdelim(&cp)) && *attrib != '\0') {
 		if ((arg = strdelim(&cp)) == NULL || *arg == '\0') {
@@ -619,37 +620,45 @@ match_cfg_line(char **condition, int lin
 		}
 		len = strlen(arg);
 		if (strcasecmp(attrib, "user") == 0) {
-			if (!user) {
+			if (ci == NULL || ci->user == NULL) {
 				result = 0;
 				continue;
 			}
-			if (match_pattern_list(user, arg, len, 0) != 1)
+			if (match_pattern_list(ci->user, arg, len, 0) != 1)
 				result = 0;
 			else
 				debug("user %.100s matched 'User %.100s' at "
-				    "line %d", user, arg, line);
+				    "line %d", ci->user, arg, line);
 		} else if (strcasecmp(attrib, "group") == 0) {
-			switch (match_cfg_line_group(arg, line, user)) {
+			if (ci == NULL || ci->user == NULL) {
+				result = 0;
+				continue;
+			}
+			switch (match_cfg_line_group(arg, line, ci->user)) {
 			case -1:
 				return -1;
 			case 0:
 				result = 0;
 			}
 		} else if (strcasecmp(attrib, "host") == 0) {
-			if (!host) {
+			if (ci == NULL || ci->host == NULL) {
 				result = 0;
 				continue;
 			}
-			if (match_hostname(host, arg, len) != 1)
+			if (match_hostname(ci->host, arg, len) != 1)
 				result = 0;
 			else
 				debug("connection from %.100s matched 'Host "
-				    "%.100s' at line %d", host, arg, line);
+				    "%.100s' at line %d", ci->host, arg, line);
 		} else if (strcasecmp(attrib, "address") == 0) {
-			switch (addr_match_list(address, arg)) {
+			if (ci == NULL || ci->address == NULL) {
+				result = 0;
+				continue;
+			}
+			switch (addr_match_list(ci->address, arg)) {
 			case 1:
 				debug("connection from %.100s matched 'Address "
-				    "%.100s' at line %d", address, arg, line);
+				    "%.100s' at line %d", ci->address, arg, line);
 				break;
 			case 0:
 			case -1:
@@ -658,12 +667,42 @@ match_cfg_line(char **condition, int lin
 			case -2:
 				return -1;
 			}
+		} else if (strcasecmp(attrib, "localaddress") == 0){
+			if (ci == NULL || ci->laddress == NULL) {
+				result = 0;
+				continue;
+			}
+			switch (addr_match_list(ci->laddress, arg)) {
+			case 1:
+				debug("connection from %.100s matched "
+				    "'LocalAddress %.100s' at line %d",
+				    ci->laddress, arg, line);
+				break;
+			case 0:
+			case -1:
+				result = 0;
+				break;
+			case -2:
+				return -1;
+			}
+		} else if (strcasecmp(attrib, "localport") == 0) {
+			if ((port = a2port(arg)) == -1) {
+				error("Invalid LocalPort '%s' on Match line",
+				    arg);
+				return -1;
+			}
+			if (ci == NULL) {
+				result = 0;
+				continue;
+			}
+			if (a2port(arg) == ci->lport)
+				result = 1;
 		} else {
 			error("Unsupported Match attribute %s", attrib);
 			return -1;
 		}
 	}
-	if (user != NULL)
+	if (ci != NULL)
 		debug3("match %sfound", result ? "" : "not ");
 	*condition = cp;
 	return result;
@@ -710,8 +749,8 @@ static const struct multistate multistat
 
 int
 process_server_config_line(ServerOptions *options, char *line,
-    const char *filename, int linenum, int *activep, const char *user,
-    const char *host, const char *address)
+    const char *filename, int linenum, int *activep,
+    ConnectionInfo *connectinfo)
 {
 	char *cp, **charptr, *arg, *p;
 	int cmdline = 0, *intptr, value, value2, n;
@@ -742,7 +781,7 @@ process_server_config_line(ServerOptions
 	if (*activep && opcode != sMatch)
 		debug3("%s:%d setting %s %s", filename, linenum, arg, cp);
 	if (*activep == 0 && !(flags & SSHCFG_MATCH)) {
-		if (user == NULL) {
+		if (connectinfo == NULL) {
 			fatal("%s line %d: Directive '%s' is not allowed "
 			    "within a Match block", filename, linenum, arg);
 		} else { /* this is a directive we have already processed */
@@ -1313,7 +1352,7 @@ process_server_config_line(ServerOptions
 		if (cmdline)
 			fatal("Match directive not supported as a command-line "
 			   "option");
-		value = match_cfg_line(&cp, linenum, user, host, address);
+		value = match_cfg_line(&cp, linenum, connectinfo);
 		if (value < 0)
 			fatal("%s line %d: Bad Match condition", filename,
 			    linenum);
@@ -1451,16 +1490,57 @@ load_server_config(const char *filename,
 }
 
 void
-parse_server_match_config(ServerOptions *options, const char *user,
-    const char *host, const char *address)
+parse_server_match_config(ServerOptions *options, ConnectionInfo *connectinfo)
 {
 	ServerOptions mo;
 
 	initialize_server_options(&mo);
-	parse_server_config(&mo, "reprocess config", &cfg, user, host, address);
+	parse_server_config(&mo, "reprocess config", &cfg, connectinfo);
 	copy_set_server_options(options, &mo, 0);
 }
 
+int parse_server_match_testspec(ConnectionInfo *ci, char *spec)
+{
+	char *p;
+
+	while ((p = strsep(&spec, ",")) && *p != '\0') {
+		if (strncmp(p, "addr=", 5) == 0)
+			ci->address = xstrdup(p + 5);
+		else if (strncmp(p, "host=", 5) == 0)
+			ci->host = xstrdup(p + 5);
+		else if (strncmp(p, "user=", 5) == 0)
+			ci->user = xstrdup(p + 5);
+		else if (strncmp(p, "laddr=", 6) == 0)
+			ci->laddress = xstrdup(p + 6);
+		else if (strncmp(p, "lport=", 6) == 0)
+			ci->lport = a2port(p + 6);
+			if (ci->lport == -1) {
+				fprintf(stderr, "Invalid port '%s' in test mode"
+				   " specification %s\n", p+6, p);
+				return -1;
+			}
+		else {
+			fprintf(stderr, "Invalid test mode specification %s\n",
+			   p);
+			return -1;
+		}
+	}
+	return 0;
+}
+
+/*
+ * returns 1 for a complete spec, 0 for partial spec and -1 for an
+ * empty spec.
+ */
+int server_match_spec_complete(ConnectionInfo *ci)
+{
+	if (ci->user && ci->host && ci->address)
+		return 1;	/* complete */
+	if (!ci->user && !ci->host && !ci->address)
+		return -1;	/* empty */
+	return 0;	/* partial */
+}
+
 /* Helper macros */
 #define M_CP_INTOPT(n) do {\
 	if (src->n != -1) \
@@ -1534,7 +1614,7 @@ copy_set_server_options(ServerOptions *d
 
 void
 parse_server_config(ServerOptions *options, const char *filename, Buffer *conf,
-    const char *user, const char *host, const char *address)
+    ConnectionInfo *connectinfo)
 {
 	int active, linenum, bad_options = 0;
 	char *cp, *obuf, *cbuf;
@@ -1542,11 +1622,11 @@ parse_server_config(ServerOptions *optio
 	debug2("%s: config %s len %d", __func__, filename, buffer_len(conf));
 
 	obuf = cbuf = xstrdup(buffer_ptr(conf));
-	active = user ? 0 : 1;
+	active = connectinfo ? 0 : 1;
 	linenum = 1;
 	while ((cp = strsep(&cbuf, "\n")) != NULL) {
 		if (process_server_config_line(options, cp, filename,
-		    linenum++, &active, user, host, address) != 0)
+		    linenum++, &active, connectinfo) != 0)
 			bad_options++;
 	}
 	xfree(obuf);
Index: servconf.h
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh/servconf.h,v
retrieving revision 1.91
diff -u -p -r1.91 servconf.h
--- servconf.h	22 Jun 2011 22:30:03 -0000	1.91
+++ servconf.h	10 Oct 2011 06:05:56 -0000
@@ -168,6 +168,17 @@ typedef struct {
 	char   *authorized_principals_file;
 }       ServerOptions;
 
+
+/* Information about the incoming connection as used by Match */
+typedef struct {
+	const char *user;
+	const char *host;	/* possibly resolved hostname */
+	const char *address; 	/* remote address */
+	const char *laddress;	/* local address */
+	int lport;		/* local port */
+} ConnectionInfo;
+
+
 /*
  * These are string config options that must be copied between the
  * Match sub-config and the main config, and must be sent from the
@@ -185,12 +196,13 @@ typedef struct {
 void	 initialize_server_options(ServerOptions *);
 void	 fill_default_server_options(ServerOptions *);
 int	 process_server_config_line(ServerOptions *, char *, const char *, int,
-	     int *, const char *, const char *, const char *);
+	     int *, ConnectionInfo *);
 void	 load_server_config(const char *, Buffer *);
 void	 parse_server_config(ServerOptions *, const char *, Buffer *,
-	     const char *, const char *, const char *);
-void	 parse_server_match_config(ServerOptions *, const char *, const char *,
-	     const char *);
+	     ConnectionInfo *);
+void	 parse_server_match_config(ServerOptions *, ConnectionInfo *);
+int	 parse_server_match_testspec(ConnectionInfo *, char *);
+int	 server_match_spec_complete(ConnectionInfo *);
 void	 copy_set_server_options(ServerOptions *, ServerOptions *, int);
 void	 dump_config(ServerOptions *);
 char	*derelativise_path(const char *);
Index: sshd.8
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh/sshd.8,v
retrieving revision 1.225
diff -u -p -r1.225 sshd.8
--- sshd.8	2 Oct 2011 07:57:38 -0000	1.225
+++ sshd.8	10 Oct 2011 06:14:47 -0000
@@ -114,6 +114,8 @@ The connection parameters are supplied a
 The keywords are
 .Dq user ,
 .Dq host ,
+.Dq laddr ,
+.Dq lport ,
 and
 .Dq addr .
 All are required and may be supplied in any order, either with multiple
Index: sshd.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh/sshd.c,v
retrieving revision 1.410
diff -u -p -r1.410 sshd.c
--- sshd.c	2 Oct 2011 08:10:14 -0000	1.410
+++ sshd.c	10 Oct 2011 06:04:57 -0000
@@ -143,6 +143,9 @@ extern char *__progname;
 /* Server configuration options. */
 ServerOptions options;
 
+/* Connection information used by Match */
+ConnectionInfo connection_info;
+
 /* Name of the server configuration file. */
 char *config_file_name = _PATH_SERVER_CONFIG_FILE;
 
@@ -1320,9 +1323,8 @@ main(int ac, char **av)
 	int opt, i, j, on = 1;
 	int sock_in = -1, sock_out = -1, newsock = -1;
 	const char *remote_ip;
-	char *test_user = NULL, *test_host = NULL, *test_addr = NULL;
 	int remote_port;
-	char *line, *p, *cp;
+	char *line;
 	int config_s[2] = { -1 , -1 };
 	u_int64_t ibytes, obytes;
 	mode_t new_umask;
@@ -1449,20 +1451,9 @@ main(int ac, char **av)
 			test_flag = 2;
 			break;
 		case 'C':
-			cp = optarg;
-			while ((p = strsep(&cp, ",")) && *p != '\0') {
-				if (strncmp(p, "addr=", 5) == 0)
-					test_addr = xstrdup(p + 5);
-				else if (strncmp(p, "host=", 5) == 0)
-					test_host = xstrdup(p + 5);
-				else if (strncmp(p, "user=", 5) == 0)
-					test_user = xstrdup(p + 5);
-				else {
-					fprintf(stderr, "Invalid test "
-					    "mode specification %s\n", p);
-					exit(1);
-				}
-			}
+			if (parse_server_match_testspec(&connection_info,
+			    optarg) == -1)
+				exit(1);
 			break;
 		case 'u':
 			utmp_len = (u_int)strtonum(optarg, 0, MAXHOSTNAMELEN+1, NULL);
@@ -1474,7 +1465,7 @@ main(int ac, char **av)
 		case 'o':
 			line = xstrdup(optarg);
 			if (process_server_config_line(&options, line,
-			    "command-line", 0, NULL, NULL, NULL, NULL) != 0)
+			    "command-line", 0, NULL, NULL) != 0)
 				exit(1);
 			xfree(line);
 			break;
@@ -1530,13 +1521,10 @@ main(int ac, char **av)
 	 * the parameters we need.  If we're not doing an extended test,
 	 * do not silently ignore connection test params.
 	 */
-	if (test_flag >= 2 &&
-	   (test_user != NULL || test_host != NULL || test_addr != NULL)
-	    && (test_user == NULL || test_host == NULL || test_addr == NULL))
+	if (test_flag >= 2 && server_match_spec_complete(&connection_info) == 0)
 		fatal("user, host and addr are all required when testing "
 		   "Match configs");
-	if (test_flag < 2 && (test_user != NULL || test_host != NULL ||
-	    test_addr != NULL))
+	if (test_flag < 2 && server_match_spec_complete(&connection_info) >= 0)
 		fatal("Config test connection parameter (-C) provided without "
 		   "test mode (-T)");
 
@@ -1548,7 +1536,7 @@ main(int ac, char **av)
 		load_server_config(config_file_name, &cfg);
 
 	parse_server_config(&options, rexeced_flag ? "rexec" : config_file_name,
-	    &cfg, NULL, NULL, NULL);
+	    &cfg, NULL);
 
 	seed_rng();
 
@@ -1710,9 +1698,8 @@ main(int ac, char **av)
 	}
 
 	if (test_flag > 1) {
-		if (test_user != NULL && test_addr != NULL && test_host != NULL)
-			parse_server_match_config(&options, test_user,
-			    test_host, test_addr);
+		if (server_match_spec_complete(&connection_info) == 1)
+			parse_server_match_config(&options, &connection_info);
 		dump_config(&options);
 	}
 
Index: sshd_config.5
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh/sshd_config.5,v
retrieving revision 1.143
diff -u -p -r1.143 sshd_config.5
--- sshd_config.5	22 Sep 2011 11:37:13 -0000	1.143
+++ sshd_config.5	10 Oct 2011 06:15:33 -0000
@@ -675,6 +675,8 @@ The available criteria are
 .Cm User ,
 .Cm Group ,
 .Cm Host ,
+.Cm LocalAddress ,
+.Cm LocalPort ,
 and
 .Cm Address .
 The match patterns may consist of single entries or comma-separated

From dtucker at zip.com.au  Mon Oct 17 00:20:14 2011
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 17 Oct 2011 00:20:14 +1100
Subject: Restricting users using one port
In-Reply-To: <20111016130857.GA29306@gate.dtucker.net>
References: <BC5D281AE93CE7EF7357E2EB@nimrod.local>
 <alpine.BSO.2.00.1110092146310.32730@natsu.mindrot.org>
 <20111016130857.GA29306@gate.dtucker.net>
Message-ID: <20111016132014.GA30541@gate.dtucker.net>

On Mon, Oct 17, 2011 at 12:08:57AM +1100, Darren Tucker wrote:
[...]
> I'd suggest calling them LocalAddress and LocalPort (or ServerAddress
> and ServerPort) though.

On second thought, I think it should be "Match ListenAddress" to be
consistent with the existing directive.  I'm not sure if the port should
be "Match ListenPort" to be consistent with ListenAddress, or "Match
Port" to be consistent with the existing Port directive (I'm leaning
toward the former).

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From glenn at zewt.org  Mon Oct 17 03:32:04 2011
From: glenn at zewt.org (Glenn Maynard)
Date: Sun, 16 Oct 2011 12:32:04 -0400
Subject: Restricting users using one port
In-Reply-To: <20111016132014.GA30541@gate.dtucker.net>
References: <BC5D281AE93CE7EF7357E2EB@nimrod.local>
 <alpine.BSO.2.00.1110092146310.32730@natsu.mindrot.org>
 <20111016130857.GA29306@gate.dtucker.net>
 <20111016132014.GA30541@gate.dtucker.net>
Message-ID: <CABirCh9nWx6apdjv9r8+NZWD7exV8huyAggskGJtMtwXAoKgnQ@mail.gmail.com>

On Sun, Oct 16, 2011 at 9:20 AM, Darren Tucker <dtucker at zip.com.au> wrote:

> On Mon, Oct 17, 2011 at 12:08:57AM +1100, Darren Tucker wrote:
> [...]
> > I'd suggest calling them LocalAddress and LocalPort (or ServerAddress
> > and ServerPort) though.
>
> On second thought, I think it should be "Match ListenAddress" to be
> consistent with the existing directive.  I'm not sure if the port should
> be "Match ListenPort" to be consistent with ListenAddress, or "Match
> Port" to be consistent with the existing Port directive (I'm leaning
> toward the former).
>

"Match ListenAddress" sounds like it's matching against the address the
server is listening on (which may be "all interfaces"), rather than the
address that was actually connected to.

I'd suggest "LocalAddress", with the same syntax as ListenAddress, allowing
an address, port or both to be specified.  This gives a consistent syntax,
and avoids repeating the redundancy between LocalAddress and Port.

-- 
Glenn Maynard

From djm at mindrot.org  Mon Oct 17 08:06:57 2011
From: djm at mindrot.org (Damien Miller)
Date: Mon, 17 Oct 2011 08:06:57 +1100 (EST)
Subject: Restricting users using one port
In-Reply-To: <20111016130857.GA29306@gate.dtucker.net>
References: <BC5D281AE93CE7EF7357E2EB@nimrod.local>
 <alpine.BSO.2.00.1110092146310.32730@natsu.mindrot.org>
 <20111016130857.GA29306@gate.dtucker.net>
Message-ID: <alpine.BSO.2.00.1110170801090.28735@natsu.mindrot.org>

On Mon, 17 Oct 2011, Darren Tucker wrote:

> It's feasible. The initial Match processing is done just after the
> client sends the username so both the local address and port are known
> and there should be no additional hooks needed.
>
> I'd suggest calling them LocalAddress and LocalPort (or ServerAddress
> and ServerPort) though.
>
> Attached are two patches: openssh-match-struct.patch
> which moves the items that are checked to a struct, and
> openssh-match-localaddrport.patch which implements the requested
> functionality. (You only need the latter to try it, the former is just
> for review).

I like this, but I prefer LocalAddress/LocalPort over
ListenAddress/ListenPort. Instead of adding another global, perhaps you
could add a canohost.c function that returns a (cached) ConnectionInfo?

-d

From mspinzer at yahoo.com  Sat Oct 22 07:40:30 2011
From: mspinzer at yahoo.com (Mike Spinzer)
Date: Fri, 21 Oct 2011 13:40:30 -0700 (PDT)
Subject: Handing connection depending on the client computer public key
 fingerprint
Message-ID: <1319229630.5464.YahooMailNeo@web121416.mail.ne1.yahoo.com>

Hello,


I try to find a way to handle SSH connections differently depending if it comes from a 'trusted" computer or from an unknown computer (for instance giving access to a shell versus allowing only scp/sftp in a chrooted environment).
Using the IP address is not a solution since a trusted computer can be a laptop that is connected somewhere on Internet.
One solution could be to use the client?public key fingerprint;?the server would then keep a white list of public key fingerprints that represent the trusted computers.

However I can't find a way to implement this.
I tried with the Match directive, but this one doesn't take such parameter
I tried too with a ForceCommand, but fount no way to configure sshd to transmit the?public key fingerprint to the script.

Is there any way to do that?

Thanks a lot for your help,

Mike S.


From imorgan at nas.nasa.gov  Sat Oct 22 10:19:25 2011
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Fri, 21 Oct 2011 16:19:25 -0700
Subject: Handing connection depending on the client computer public key
 fingerprint
In-Reply-To: <1319229630.5464.YahooMailNeo@web121416.mail.ne1.yahoo.com>
References: <1319229630.5464.YahooMailNeo@web121416.mail.ne1.yahoo.com>
Message-ID: <20111021231925.GA12602@linux124.nas.nasa.gov>

On Fri, Oct 21, 2011 at 15:40:30 -0500, Mike Spinzer wrote:
> Hello,
> 
> 
> I try to find a way to handle SSH connections differently depending if it comes from a 'trusted" computer or from an unknown computer (for instance giving access to a shell versus allowing only scp/sftp in a chrooted environment).
> Using the IP address is not a solution since a trusted computer can be a laptop that is connected somewhere on Internet.
> One solution could be to use the client?public key fingerprint;?the server would then keep a white list of public key fingerprints that represent the trusted computers.
> 
> However I can't find a way to implement this.
> I tried with the Match directive, but this one doesn't take such parameter
> I tried too with a ForceCommand, but fount no way to configure sshd to transmit the?public key fingerprint to the script.
> 
> Is there any way to do that?
> 
> Thanks a lot for your help,

You first need to define what you mean by "trusted computer" in this
context. You presumably mean a set of public-keys for which you have
greater confidence and are thus willing to permit greater access.
However, unless the client and server systems are configured to use
hostbased authentication, the public key is really associated with a user _not_
a computer. In that case, you could place all "untrusted" users in a single
group and use the Match directive to force a command such as
sftp-server. Or you could set the shell for these untrusted users to
scponly; asuming that scponly is still around.

-- 
Iain Morgan

From krzysztof_stankiewicz at hotmail.com  Sat Oct 22 14:39:30 2011
From: krzysztof_stankiewicz at hotmail.com (Krzysztof Stankiewicz)
Date: Sat, 22 Oct 2011 14:39:30 +1100
Subject: Creating a reverse socket often (not always) fails.
In-Reply-To: <COL123-W358B3F7A3464DD96B4124996E90@phx.gbl>
References: <COL123-W358B3F7A3464DD96B4124996E90@phx.gbl>
Message-ID: <COL123-W20A42FC4560A89FBDCCF9196E90@phx.gbl>



Hi,

I'm a little stuck on getting reverse connection working reliably from embedded devices running dropbear 0.51 to Ubuntu 8.x openssh.
Connecting to local reverse socket often fails (not always) with "ssh_exchange_identification: Connection closed by remote host"

My devices can reverse ssh and open a port on my server always, but often when the server is creating the reverse socket on localhost it
freezes at "debug2: channel 2: sent ext data 706". The reverse connection works but later connecting to that reverse socket on the server
fails with "ssh_exchange_identification: Connection closed by remote host".

"often fails" means for a time it will allow connections and then same configuration for a time will fail.

Any help would be very appreciated, Ive traced it down this far and could use some further pointers if possible. Seems an obscure problem at this stage.

Thank you.

//creating reverse connection, creates a socket but subsequently conecting to it fails.
debug1: channel 1: new [port listener]
debug1: server_input_channel_open: ctype session rchan 0 win 24576 max 32768
debug1: input_session_request
debug1: channel 2: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 2 request shell reply 0
debug1: session_by_channel: session 0 channel 2
debug1: session_input_channel_req: session 0 req shell
debug2: fd 3 setting TCP_NODELAY
debug2: fd 11 setting O_NONBLOCK
debug3: fd 11 is O_NONBLOCK
debug2: fd 13 setting O_NONBLOCK
debug2: channel 2: read 702 from efd 13
debug2: channel 2: rwin 24540 elen 702 euse 1
debug2: channel 2: sent ext data 702
------freezes here even though reverse connection is fine.

//creating a good reverse connection, can connect to this local socket without a problem.
debug1: channel 1: new [port listener]
debug1: server_input_channel_open: ctype session rchan 0 win 24576 max 32768
debug1: input_session_request
debug1: channel 2: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 2
debug1: session_open: session 0: link with channel 2
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 2 request shell reply 0
debug1: session_by_channel: session 0 channel 2
debug1: session_input_channel_req: session 0 req shell
debug2: fd 3 setting TCP_NODELAY
debug2: fd 11 setting O_NONBLOCK
debug3: fd 11 is O_NONBLOCK
debug2: fd 13 setting O_NONBLOCK
debug2: channel 2: read 706 from efd 13
debug2: channel 2: rwin 24540 elen 706 euse 1
debug2: channel 2: sent ext data 706
debug2: channel 2: rcvd eof
debug2: channel 2: output open -> drain
debug2: channel 2: obuf empty
debug2: channel 2: close_write
debug2: channel 2: output drain -> closed
debug2: channel 2: rcvd close
debug2: channel 2: close_read
debug2: channel 2: input open -> closed
debug3: channel 2: will not send data after close
debug2: channel 2: almost dead
debug2: channel 2: gc: notify user
debug1: session_by_channel: session 0 channel 2
debug1: session_close_by_channel: channel 2 child 12289
debug1: session_close_by_channel: channel 2: has child


 		 	   		   		 	   		  

From krzysztof_stankiewicz at hotmail.com  Sat Oct 22 14:38:23 2011
From: krzysztof_stankiewicz at hotmail.com (Krzysztof Stankiewicz)
Date: Sat, 22 Oct 2011 14:38:23 +1100
Subject: Creating a reverse socket often (not always) fails.
Message-ID: <COL123-W358B3F7A3464DD96B4124996E90@phx.gbl>



Hi,

I'm a little stuck on getting reverse connection working reliably from embedded devices running dropbear 0.51 to Ubuntu 8.x openssh.
Connecting to local reverse socket often fails (not always) with "ssh_exchange_identification: Connection closed by remote host"

My devices can reverse ssh and open a port on my server always, but often when the server is creating the reverse socket on localhost it
freezes at "debug2: channel 2: sent ext data 706". The reverse connection works but later connecting to that reverse socket on the server
fails with "ssh_exchange_identification: Connection closed by remote host".

"often fails" means for a time it will allow connections and then same configuration for a time will fail.

Any help would be very appreciated, Ive traced it down this far and could use some further pointers if possible. Seems an obscure problem at this stage.

Thank you.

//creating reverse connection, creates a socket but subsequently conecting to it fails.
debug1: channel 1: new [port listener]
debug1: server_input_channel_open: ctype session rchan 0 win 24576 max 32768
debug1: input_session_request
debug1: channel 2: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 2 request shell reply 0
debug1: session_by_channel: session 0 channel 2
debug1: session_input_channel_req: session 0 req shell
debug2: fd 3 setting TCP_NODELAY
debug2: fd 11 setting O_NONBLOCK
debug3: fd 11 is O_NONBLOCK
debug2: fd 13 setting O_NONBLOCK
debug2: channel 2: read 702 from efd 13
debug2: channel 2: rwin 24540 elen 702 euse 1
debug2: channel 2: sent ext data 702
------freezes here even though reverse connection is fine.

//creating a good reverse connection, can connect to this local socket without a problem.
debug1: channel 1: new [port listener]
debug1: server_input_channel_open: ctype session rchan 0 win 24576 max 32768
debug1: input_session_request
debug1: channel 2: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 2
debug1: session_open: session 0: link with channel 2
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 2 request shell reply 0
debug1: session_by_channel: session 0 channel 2
debug1: session_input_channel_req: session 0 req shell
debug2: fd 3 setting TCP_NODELAY
debug2: fd 11 setting O_NONBLOCK
debug3: fd 11 is O_NONBLOCK
debug2: fd 13 setting O_NONBLOCK
debug2: channel 2: read 706 from efd 13
debug2: channel 2: rwin 24540 elen 706 euse 1
debug2: channel 2: sent ext data 706
debug2: channel 2: rcvd eof
debug2: channel 2: output open -> drain
debug2: channel 2: obuf empty
debug2: channel 2: close_write
debug2: channel 2: output drain -> closed
debug2: channel 2: rcvd close
debug2: channel 2: close_read
debug2: channel 2: input open -> closed
debug3: channel 2: will not send data after close
debug2: channel 2: almost dead
debug2: channel 2: gc: notify user
debug1: session_by_channel: session 0 channel 2
debug1: session_close_by_channel: channel 2 child 12289
debug1: session_close_by_channel: channel 2: has child


 		 	   		  

From glenn at zewt.org  Mon Oct 24 01:05:38 2011
From: glenn at zewt.org (Glenn Maynard)
Date: Sun, 23 Oct 2011 10:05:38 -0400
Subject: Determining the port assigned by -R 0
In-Reply-To: <alpine.BSO.2.00.1110151010250.11833@natsu.mindrot.org>
References: <CABirCh9OcDMx=i8r9t0HBwsa8ALBQpkjysXbi1LTHirKSFYKBg@mail.gmail.com>
 <alpine.BSO.2.00.1110151010250.11833@natsu.mindrot.org>
Message-ID: <CABirCh8puWe1DUzbG41-YNk_Xb0eOyExRpn0_fYakTL80S9cBw@mail.gmail.com>

On Fri, Oct 14, 2011 at 7:13 PM, Damien Miller <djm at mindrot.org> wrote:

>  It's easier if you use the multiplexing socket.
>
> ssh -O forward -R0:xxx:yyy host
>
> will print the allocated port to stdout on success.
>

I suppose that works, but it'd be better to do this server-side.  That way,
the script run on the server doesn't have to trust the client to pass along
correct information.  For example, if a client tries forwarding thousands of
ports, the script could reliably detect that and close the connection.
(This is a remote diagnostics script; the remote client is untrusted.)

By the way, it'd be helpful to be able to specify eg. "PermitOpen none"; I
ended up arriving at the same hack that this guy used:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543683.  It's minor, but
it'd be nice to be able to do this correctly.

-- 
Glenn Maynard

From alex at alex.org.uk  Mon Oct 24 06:41:15 2011
From: alex at alex.org.uk (Alex Bligh)
Date: Sun, 23 Oct 2011 20:41:15 +0100
Subject: Determining the port assigned by -R 0
In-Reply-To: <CABirCh8puWe1DUzbG41-YNk_Xb0eOyExRpn0_fYakTL80S9cBw@mail.gmail.com>
References: <CABirCh9OcDMx=i8r9t0HBwsa8ALBQpkjysXbi1LTHirKSFYKBg@mail.gmail.com>
 <alpine.BSO.2.00.1110151010250.11833@natsu.mindrot.org>
 <CABirCh8puWe1DUzbG41-YNk_Xb0eOyExRpn0_fYakTL80S9cBw@mail.gmail.com>
Message-ID: <69885E531E66E5865A9A18C1@nimrod.local>



--On 23 October 2011 10:05:38 -0400 Glenn Maynard <glenn at zewt.org> wrote:

> I suppose that works, but it'd be better to do this server-side.  That
> way, the script run on the server doesn't have to trust the client to
> pass along correct information.  For example, if a client tries
> forwarding thousands of ports, the script could reliably detect that and
> close the connection. (This is a remote diagnostics script; the remote
> client is untrusted.)

I've just worked around this. I used a ForceCommand that runs a script
that walks up the process tree, and does the equivalent of lsof, puts the
the key used (parameter to the ForceCommand) and the port in a local db,
and waits. It's no use if you have 2 x -R, but if you know only one is
valid, then you can find it reliably and (I believe) securely.

> By the way, it'd be helpful to be able to specify eg. "PermitOpen none"; I
> ended up arriving at the same hack that this guy used:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543683.  It's minor, but
> it'd be nice to be able to do this correctly.

+1 - I independently came up with a very similar hack.

-- 
Alex Bligh

From lukasz.bienczyk at gmail.com  Mon Oct 24 19:11:18 2011
From: lukasz.bienczyk at gmail.com (=?ISO-8859-2?Q?=A3ukasz_Bie=F1czyk?=)
Date: Mon, 24 Oct 2011 10:11:18 +0200
Subject: problem with a tty
Message-ID: <CALhvmb+-08tqBQxLaeBACxAPjFRQUm3a_AD4E5sB_UWMqxtqkA@mail.gmail.com>

hello everyone

I'm writing an application which execute ssh, I communicate with
a ssh process by stdin/stdout. Everything works fine, but lately I've noticed
that I need TTY(for changing a password), so I use "-tt" option to force tty
allocation, and now on stdout I get messages with all commands which I write.
I mean:
write(stdin): ls
read(stdout): ls
read(stdout): "ls result"

Is there a way to avoid that?

Regards,
lukasz

From hans at atbas.org  Mon Oct 24 22:38:51 2011
From: hans at atbas.org (Hans Harder)
Date: Mon, 24 Oct 2011 13:38:51 +0200
Subject: problem using sshd inside a LXC container
Message-ID: <CAKzsc6dRRraF-v9p-9BuQfyvMdPDaoLaoabk=yfrw-z0fEjPdQ@mail.gmail.com>

Currently I have a RH6.1 host with selinux enabled
On this I am running a LXC container with ubuntu (without selinux) with
OpenSSH_5.3p1 Debian-3ubuntu4, OpenSSL 0.9.8k 25 Mar 2009


when I try to do a ssh connection to the lxc container I get :
...
debug1: Next authentication method: password
root at 192.168.2.11's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions at openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: channel 0: free: client-session, nchannels 1
Connection to 192.168.2.11 closed by remote host.
Connection to 192.168.2.11 closed.
Transferred: sent 1728, received 1784 bytes, in 0.1 seconds
Bytes per second: sent 16426.3, received 16958.6
debug1: Exit status -1


Inside the container I can see an error in the auth.log:

Oct 24 11:14:11 art01 sshd[1703]: pam_unix(sshd:session): session
opened for user root by (uid=0)
Oct 24 11:14:11 art01 sshd[1703]: fatal: ssh_selinux_getctxbyname:
ssh_selinux_getctxbyname: security_getenforce() failed
Oct 24 11:14:11 art01 sshd[1703]: pam_unix(sshd:session): session
closed for user root


Now I assume I have a problem because inside the container selinux is
disabled...
If so, is there a way to tell the sshd inside the container to ignore
the selinux check....

Hans

From vinschen at redhat.com  Mon Oct 24 21:40:11 2011
From: vinschen at redhat.com (Corinna Vinschen)
Date: Mon, 24 Oct 2011 12:40:11 +0200
Subject: [patch/cygwin] don't require doc files
Message-ID: <20111024104011.GD14623@calimero.vinschen.de>

Hi,

could somebody with checkin rights please apply the below patch?
It only changes the Cygwin specific installation so that it doesn't
bail out if documentation files don't exist.  Last time the WARNING.RNG
file disappeared, and the Cygwin post-install step failed.


Thanks,
Corinna


Index: contrib/cygwin/Makefile
===================================================================
RCS file: /cvs/openssh/contrib/cygwin/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- contrib/cygwin/Makefile	9 Apr 2010 03:35:24 -0000	1.7
+++ contrib/cygwin/Makefile	24 Oct 2011 10:39:25 -0000
@@ -36,21 +36,20 @@ install-inetd-config:
 
 install-sshdoc:
 	$(srcdir)/mkinstalldirs $(DESTDIR)$(sshdocdir)
-	$(INSTALL) -m 644 $(srcdir)/CREDITS $(DESTDIR)$(sshdocdir)/CREDITS
-	$(INSTALL) -m 644 $(srcdir)/ChangeLog $(DESTDIR)$(sshdocdir)/ChangeLog
-	$(INSTALL) -m 644 $(srcdir)/LICENCE $(DESTDIR)$(sshdocdir)/LICENCE
-	$(INSTALL) -m 644 $(srcdir)/OVERVIEW $(DESTDIR)$(sshdocdir)/OVERVIEW
-	$(INSTALL) -m 644 $(srcdir)/PROTOCOL $(DESTDIR)$(sshdocdir)/PROTOCOL
-	$(INSTALL) -m 644 $(srcdir)/PROTOCOL.agent $(DESTDIR)$(sshdocdir)/PROTOCOL.agent
-	$(INSTALL) -m 644 $(srcdir)/PROTOCOL.certkeys $(DESTDIR)$(sshdocdir)/PROTOCOL.certkeys
-	$(INSTALL) -m 644 $(srcdir)/PROTOCOL.mux $(DESTDIR)$(sshdocdir)/PROTOCOL.mux
-	$(INSTALL) -m 644 $(srcdir)/README $(DESTDIR)$(sshdocdir)/README
-	$(INSTALL) -m 644 $(srcdir)/README.dns $(DESTDIR)$(sshdocdir)/README.dns
-	$(INSTALL) -m 644 $(srcdir)/README.platform $(DESTDIR)$(sshdocdir)/README.platform
-	$(INSTALL) -m 644 $(srcdir)/README.privsep $(DESTDIR)$(sshdocdir)/README.privsep
-	$(INSTALL) -m 644 $(srcdir)/README.tun $(DESTDIR)$(sshdocdir)/README.tun
-	$(INSTALL) -m 644 $(srcdir)/TODO $(DESTDIR)$(sshdocdir)/TODO
-	$(INSTALL) -m 644 $(srcdir)/WARNING.RNG $(DESTDIR)$(sshdocdir)/WARNING.RNG
+	-$(INSTALL) -m 644 $(srcdir)/CREDITS $(DESTDIR)$(sshdocdir)/CREDITS
+	-$(INSTALL) -m 644 $(srcdir)/ChangeLog $(DESTDIR)$(sshdocdir)/ChangeLog
+	-$(INSTALL) -m 644 $(srcdir)/LICENCE $(DESTDIR)$(sshdocdir)/LICENCE
+	-$(INSTALL) -m 644 $(srcdir)/OVERVIEW $(DESTDIR)$(sshdocdir)/OVERVIEW
+	-$(INSTALL) -m 644 $(srcdir)/PROTOCOL $(DESTDIR)$(sshdocdir)/PROTOCOL
+	-$(INSTALL) -m 644 $(srcdir)/PROTOCOL.agent $(DESTDIR)$(sshdocdir)/PROTOCOL.agent
+	-$(INSTALL) -m 644 $(srcdir)/PROTOCOL.certkeys $(DESTDIR)$(sshdocdir)/PROTOCOL.certkeys
+	-$(INSTALL) -m 644 $(srcdir)/PROTOCOL.mux $(DESTDIR)$(sshdocdir)/PROTOCOL.mux
+	-$(INSTALL) -m 644 $(srcdir)/README $(DESTDIR)$(sshdocdir)/README
+	-$(INSTALL) -m 644 $(srcdir)/README.dns $(DESTDIR)$(sshdocdir)/README.dns
+	-$(INSTALL) -m 644 $(srcdir)/README.platform $(DESTDIR)$(sshdocdir)/README.platform
+	-$(INSTALL) -m 644 $(srcdir)/README.privsep $(DESTDIR)$(sshdocdir)/README.privsep
+	-$(INSTALL) -m 644 $(srcdir)/README.tun $(DESTDIR)$(sshdocdir)/README.tun
+	-$(INSTALL) -m 644 $(srcdir)/TODO $(DESTDIR)$(sshdocdir)/TODO
 
 install-cygwindoc: README
 	$(srcdir)/mkinstalldirs $(DESTDIR)$(cygdocdir)

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

From keisial at gmail.com  Tue Oct 25 03:18:57 2011
From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=)
Date: Mon, 24 Oct 2011 18:18:57 +0200
Subject: problem with a tty
In-Reply-To: <CALhvmb+-08tqBQxLaeBACxAPjFRQUm3a_AD4E5sB_UWMqxtqkA@mail.gmail.com>
References: <CALhvmb+-08tqBQxLaeBACxAPjFRQUm3a_AD4E5sB_UWMqxtqkA@mail.gmail.com>
Message-ID: <4EA58FF1.7000805@gmail.com>

?ukasz Bie?czyk wrote:
> hello everyone
>
> I'm writing an application which execute ssh, I communicate with
> a ssh process by stdin/stdout. Everything works fine, but lately I've noticed
> that I need TTY(for changing a password), so I use "-tt" option to force tty
> allocation, and now on stdout I get messages with all commands which I write.
> I mean:
> write(stdin): ls
> read(stdout): ls
> read(stdout): "ls result"
>
> Is there a way to avoid that?
>
> Regards,
> lukasz
Seems that you made your shell interactive.
I don't see a parameter to make a shell connected to ttys
non-interactive, but
perhaps running 'stty -echo' is enough for your issue.


From djm at mindrot.org  Tue Oct 25 09:55:49 2011
From: djm at mindrot.org (Damien Miller)
Date: Tue, 25 Oct 2011 09:55:49 +1100 (EST)
Subject: Handing connection depending on the client computer public key
 fingerprint
In-Reply-To: <1319229630.5464.YahooMailNeo@web121416.mail.ne1.yahoo.com>
References: <1319229630.5464.YahooMailNeo@web121416.mail.ne1.yahoo.com>
Message-ID: <alpine.BSO.2.00.1110250950060.2540@natsu.mindrot.org>



On Fri, 21 Oct 2011, Mike Spinzer wrote:

> Hello,
>
>
> I try to find a way to handle SSH connections differently depending
> if it comes from a 'trusted" computer or from an unknown computer
> (for instance giving access to a shell versus allowing only scp/sftp
> in a chrooted environment). Using the IP address is not a solution
> since a trusted computer can be a laptop that is connected somewhere
> on Internet. One solution could be to use the client public key
> fingerprint; the server would then keep a white list of public key
> fingerprints that represent the trusted computers.
>
> However I can't find a way to implement this. I tried with the Match
> directive, but this one doesn't take such parameter I tried too with
> a ForceCommand, but fount no way to configure sshd to transmit the
> public key fingerprint to the script.

This seems like a reasonable feature request. Perhaps we could expose
the key or its fingerprint in a SSH_AUTH_KEY environment variable.

The only complexity is in transmitting the key from the pre-auth
privsep child up to the monitor process so it is available in the
session code later.

-d

From djm at mindrot.org  Tue Oct 25 10:08:08 2011
From: djm at mindrot.org (Damien Miller)
Date: Tue, 25 Oct 2011 10:08:08 +1100 (EST)
Subject: Determining the port assigned by -R 0
In-Reply-To: <CABirCh8puWe1DUzbG41-YNk_Xb0eOyExRpn0_fYakTL80S9cBw@mail.gmail.com>
References: <CABirCh9OcDMx=i8r9t0HBwsa8ALBQpkjysXbi1LTHirKSFYKBg@mail.gmail.com>
 <alpine.BSO.2.00.1110151010250.11833@natsu.mindrot.org>
 <CABirCh8puWe1DUzbG41-YNk_Xb0eOyExRpn0_fYakTL80S9cBw@mail.gmail.com>
Message-ID: <alpine.BSO.2.00.1110250956140.2540@natsu.mindrot.org>

On Sun, 23 Oct 2011, Glenn Maynard wrote:

> I suppose that works, but it'd be better to do this server-side.  That way,
> the script run on the server doesn't have to trust the client to pass along
> correct information.  For example, if a client tries forwarding thousands of
> ports, the script could reliably detect that and close the connection.
> (This is a remote diagnostics script; the remote client is untrusted.)

informing a shell session on the server is impractical - there's little linkage between them and port forwarding sessions

> By the way, it'd be helpful to be able to specify eg. "PermitOpen none"; I
> ended up arriving at the same hack that this guy used:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543683.  It's minor, but
> it'd be nice to be able to do this correctly.

Yes, this should be pretty easy to add. could you please file an enhancement
request at https://bugzilla.mindrot.org/ so it doesn't get lost?

-d


From dtucker at zip.com.au  Tue Oct 25 14:28:17 2011
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 25 Oct 2011 14:28:17 +1100
Subject: problem using sshd inside a LXC container
In-Reply-To: <CAKzsc6dRRraF-v9p-9BuQfyvMdPDaoLaoabk=yfrw-z0fEjPdQ@mail.gmail.com>
References: <CAKzsc6dRRraF-v9p-9BuQfyvMdPDaoLaoabk=yfrw-z0fEjPdQ@mail.gmail.com>
Message-ID: <4EA62CD1.1040407@zip.com.au>

On 24/10/11 10:38 PM, Hans Harder wrote:
> Currently I have a RH6.1 host with selinux enabled
> On this I am running a LXC container with ubuntu (without selinux) with
> OpenSSH_5.3p1 Debian-3ubuntu4, OpenSSL 0.9.8k 25 Mar 2009
[...]
> Now I assume I have a problem because inside the container selinux is
> disabled...
> If so, is there a way to tell the sshd inside the container to ignore
> the selinux check....

sshd has no knobs for this.  The code in openbsd-compat/port-linux.c 
looks roughly like this (assuming it's not been changed by debian or 
ubuntu):

	r = get_default_context(sename, NULL, &sc);
	if (r != 0) {
		switch (security_getenforce()) {
		case -1:
			fatal("%s: ssh_selinux_getctxbyname: "
			    "security_getenforce() failed", __func__);

so if you could get get_default_context() to return zero then it won't 
fatal out, but I don't know enough selinux and/or lxc to know if that's 
possible.  Failing that, you'd probably have to hack sshd.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From saku at ytti.fi  Tue Oct 25 18:57:18 2011
From: saku at ytti.fi (Saku Ytti)
Date: Tue, 25 Oct 2011 10:57:18 +0300
Subject: ssh-agent use in different security domains
Message-ID: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>

Consider this topology

                domain1-server1      domain2-server2
                            |                             |
    laptop - domain1-server1 ---- domain2-server1


Laptop has two ssh identities, domain1 and domain2.


I don't wish to store identity locally in any of the servers. As far
as I understand, there isn't any way to limit ssh-agent to allow only
signing domain2 servers with domain2 identity? So Evil Admin of
domain2 could potentially ssh using my domain1 identity to domain1
server?


But need this be so? Couldn't we have something like

cat >> .ssh/config
host *.domain1.*
  Identity permit domain1-key
  Identity deny all

host *.domain2.*
  Identity permit domain2-key
  Identity deny all
^D

Or maybe ssh-agent itself could prompt user: 'domain2-server2 wants me
to sign with identity domain1-key, allow? yes/no, [ ] always?'.

Or is this problem already solved somehow?
-- 
? ++ytti

From djm at mindrot.org  Tue Oct 25 21:28:08 2011
From: djm at mindrot.org (Damien Miller)
Date: Tue, 25 Oct 2011 21:28:08 +1100 (EST)
Subject: ssh-agent use in different security domains
In-Reply-To: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
Message-ID: <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>

On Tue, 25 Oct 2011, Saku Ytti wrote:

> Consider this topology
> 
>                 domain1-server1      domain2-server2
>                             |                             |
>     laptop - domain1-server1 ---- domain2-server1
> 
> 
> Laptop has two ssh identities, domain1 and domain2.
> 
> 
> I don't wish to store identity locally in any of the servers. As far
> as I understand, there isn't any way to limit ssh-agent to allow only
> signing domain2 servers with domain2 identity? So Evil Admin of
> domain2 could potentially ssh using my domain1 identity to domain1
> server?
> 
> 
> But need this be so? Couldn't we have something like
> 
> cat >> .ssh/config
> host *.domain1.*
>   Identity permit domain1-key
>   Identity deny all
> 
> host *.domain2.*
>   Identity permit domain2-key
>   Identity deny all
> ^D
> 
> Or maybe ssh-agent itself could prompt user: 'domain2-server2 wants me
> to sign with identity domain1-key, allow? yes/no, [ ] always?'.
> 
> Or is this problem already solved somehow?

It is always safe to attempt to authenticate to a server with an agent-
hosted key - a hostile SSH v.2 server _cannot_ replay your authentication
to another host. The risk comes in when your _forward_ your agent to a
potentially-untrustworthy server. If you aren't forwarding your agent
then you don't need to worry.

If you are forwarding your agent, then right now we don't have any way to
limit key visibility. To do this we'd need to either build it into
ssh-agent or into ssh itself. Neither is particularly desirable -
ssh-agent is intended to emulate a hardware cryptographic token: you can
put your keys in and use them to sign, but not get them out easily. Each
extra line of code in ssh-agent adds attack surface that makes key
extraction more likely.

Putting key scoping in ssh is a little better, but a fair bit more work.
Right now, ssh has the luxury of treating agent connections as dumb,
opaque pipes. If it is to perform scoping, then it must instead proxy
agent connections, which requires it to speak the entirety of the agent
protocol which would add quite a bit of code to ssh. This could be
alleviated somewhat if the agent code were in a library that is shared
by ssh-add / ssh and possible ssh-agent - I've made a small start towards
this on the plane back from EuroBSDCon, but it will be a while before it
is ready.

-d

From saku at ytti.fi  Tue Oct 25 21:48:52 2011
From: saku at ytti.fi (Saku Ytti)
Date: Tue, 25 Oct 2011 13:48:52 +0300
Subject: ssh-agent use in different security domains
In-Reply-To: <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
Message-ID: <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>

On 25 October 2011 13:28, Damien Miller <djm at mindrot.org> wrote:

> to another host. The risk comes in when your _forward_ your agent to a
> potentially-untrustworthy server. If you aren't forwarding your agent
> then you don't need to worry.

Quite. I desire to connect from domain1-server1 to domain1-server2
and from domain2-server1 to domain2-server2, so forwarding is needed.

> If you are forwarding your agent, then right now we don't have any way to
> limit key visibility. To do this we'd need to either build it into
> ssh-agent or into ssh itself.

Maybe 'ssh-add -c' is something I want (otoh it should prompt always?
Which would be annoying. But I couldn't get it working). I'd really prefer
.ssh/known_hosts style, like .ssh/agent_db,  where agent would remember
when it is allowed to sign.

> alleviated somewhat if the agent code were in a library that is shared
> by ssh-add / ssh and possible ssh-agent - I've made a small start towards
> this on the plane back from EuroBSDCon, but it will be a while before it
> is ready.

That's good news, hope it pans out. Just to verify that I'm not missing
something obvious. As I understand this is fairly typical usage scenario.
How are other people addressing this?

-- 
? ++ytti

From djm at mindrot.org  Tue Oct 25 22:15:42 2011
From: djm at mindrot.org (Damien Miller)
Date: Tue, 25 Oct 2011 22:15:42 +1100 (EST)
Subject: ssh-agent use in different security domains
In-Reply-To: <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
Message-ID: <alpine.BSO.2.00.1110252214420.27574@natsu.mindrot.org>

On Tue, 25 Oct 2011, Saku Ytti wrote:

> That's good news, hope it pans out. Just to verify that I'm not missing
> something obvious. As I understand this is fairly typical usage scenario.
> How are other people addressing this?

Well, you can run multiple agents listening at specified sockets using
ssh-agent's -a option and switch between them manually by resetting
SSH_AUTH_SOCK. There isn't any automated way at present.

-d

From saku at ytti.fi  Tue Oct 25 22:26:54 2011
From: saku at ytti.fi (Saku Ytti)
Date: Tue, 25 Oct 2011 14:26:54 +0300
Subject: ssh-agent use in different security domains
In-Reply-To: <alpine.BSO.2.00.1110252214420.27574@natsu.mindrot.org>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
 <alpine.BSO.2.00.1110252214420.27574@natsu.mindrot.org>
Message-ID: <CAAeewD8S6_3U9T=PW4EqtqFs8zSK9n+nc-oOU02piBjBrU7o3A@mail.gmail.com>

On 25 October 2011 14:15, Damien Miller <djm at mindrot.org> wrote:

> Well, you can run multiple agents listening at specified sockets using
> ssh-agent's -a option and switch between them manually by resetting
> SSH_AUTH_SOCK. There isn't any automated way at present.

Quite high overhead, I'm going to assume that people just generally take
the risk.

I talked with my non-c-challenged coworker about this issue, and he said
he'd write patch for ssh-agent to query for permission to sign. But after few
minutes of looking into ssh, he told me that ssh-agent does not know who
is asking for the signing. Which means we'd need larger change to ssh, and
I doubt upstream would accept the patch :/.

-- 
? ++ytti

From dkg at fifthhorseman.net  Thu Oct 27 05:42:24 2011
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 26 Oct 2011 14:42:24 -0400
Subject: ssh-agent use in different security domains
In-Reply-To: <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
Message-ID: <4EA85490.2010303@fifthhorseman.net>

On 10/25/2011 06:48 AM, Saku Ytti wrote:
> On 25 October 2011 13:28, Damien Miller <djm at mindrot.org> wrote:
> 
>> to another host. The risk comes in when your _forward_ your agent to a
>> potentially-untrustworthy server. If you aren't forwarding your agent
>> then you don't need to worry.
> 
> Quite. I desire to connect from domain1-server1 to domain1-server2
> and from domain2-server1 to domain2-server2, so forwarding is needed.

To be clear: agent forwarding is *not* needed in this scenario, and in
fact it is discouraged.

The better approach to this is what many people call "jumphosts", which
allow the ssh connection to terminate on your local machine, instead of
having the endpoint on the gateway machine.

so this pattern is bad:

 ssh -A -t monkey.example ssh banana.example

because the if monkey is compromised, the attacker can compromise your
connection to banana, and can make use of keys in your agent.

But this connection is good:

 ssh -oProxyCommand='ssh -W %h:%p monkey.example' banana.example

because your local machine is the endpoint for both ssh sessions, and
the only thing monkey.example can see is encrypted traffic.
furthermore, your agent is not exposed to monkey at all.

(note that -W was added to ssh recently -- i think in OpenSSH 5.5, so
you'll need a recent version on your local machine -- but you can
achieve the same effect with an older version of ssh if you have netcat
or socat installed on the intermediate machine).

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20111026/c88d6f7a/attachment.bin>

From saku at ytti.fi  Thu Oct 27 05:56:47 2011
From: saku at ytti.fi (Saku Ytti)
Date: Wed, 26 Oct 2011 21:56:47 +0300
Subject: ssh-agent use in different security domains
In-Reply-To: <4EA85490.2010303@fifthhorseman.net>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
 <4EA85490.2010303@fifthhorseman.net>
Message-ID: <CAAeewD91MuKmKPxcejf9fDfEfUmEASZCqA_s0Fv7Av3t8g5T8w@mail.gmail.com>

On 26 October 2011 21:42, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:

>> Quite. I desire to connect from domain1-server1 to domain1-server2
>> and from domain2-server1 to domain2-server2, so forwarding is needed.
>
> To be clear: agent forwarding is *not* needed in this scenario, and in
> fact it is discouraged.

> But this connection is good:
>
> ?ssh -oProxyCommand='ssh -W %h:%p monkey.example' banana.example

Lets assume banana lives in domain2.

Help me understand. How does this help? If you login to banana with
ssh-agent, cant banana hijack my session and use /any/ key I have in
ssh-agent to ssh in domain1 servers?

I.e. my understanding is regardless how the transport in transit is, the
ultimate machine must be trusted to /all/ keys my ssh-agent has
And my desire is, to only trust ultimate transit with single key in my
ssh-agent, so ultimate destinations can belong to multiple security
domains.

Optimally I'd like to see

'sign request for identity domain1-key from localhost < domain1 < domain2'

Now I'd know that domain2 (or banana) has hijacked my session and is
trying to jump to domain1 servers. Which I'd then forbid ssh-agent from doing.
But this of course is not possible, as ssh-agent has no idea who wants it to
sign.

-- 
? ++ytti

From dkg at fifthhorseman.net  Thu Oct 27 06:10:54 2011
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 26 Oct 2011 15:10:54 -0400
Subject: ssh-agent use in different security domains
In-Reply-To: <CAAeewD91MuKmKPxcejf9fDfEfUmEASZCqA_s0Fv7Av3t8g5T8w@mail.gmail.com>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
 <4EA85490.2010303@fifthhorseman.net>
 <CAAeewD91MuKmKPxcejf9fDfEfUmEASZCqA_s0Fv7Av3t8g5T8w@mail.gmail.com>
Message-ID: <4EA85B3E.9050303@fifthhorseman.net>

On 10/26/2011 02:56 PM, Saku Ytti wrote:
> Help me understand. How does this help? If you login to banana with
> ssh-agent, cant banana hijack my session and use /any/ key I have in
> ssh-agent to ssh in domain1 servers?

no, if you do not forward your agent (that is, if you do not enable
ForwardAgent), the machine you connect to cannot access the keys in your
agent, regardless of the number of intermediate hops.

By default ForwardAgent should be set to "no" in ssh_config.  If you run
a distribution that has ForwardAgent set to "yes" by default, please
inform them that it should *always* default to "no".  This would be a
serious bug.

If you've set ForwardAgent to "yes" within ~/.ssh/config, that is in
almost all cases a mistake, given the possibility of using ProxyCommand
with a jumphost.

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20111026/b62456dd/attachment.bin>

From saku at ytti.fi  Thu Oct 27 06:15:41 2011
From: saku at ytti.fi (Saku Ytti)
Date: Wed, 26 Oct 2011 22:15:41 +0300
Subject: ssh-agent use in different security domains
In-Reply-To: <4EA85B3E.9050303@fifthhorseman.net>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
 <4EA85490.2010303@fifthhorseman.net>
 <CAAeewD91MuKmKPxcejf9fDfEfUmEASZCqA_s0Fv7Av3t8g5T8w@mail.gmail.com>
 <4EA85B3E.9050303@fifthhorseman.net>
Message-ID: <CAAeewD_3zG3unaw9q-ySjcbcAAAkmJEOhuUWv+rjvHouszm++g@mail.gmail.com>

On 26 October 2011 22:10, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:

> no, if you do not forward your agent (that is, if you do not enable
> ForwardAgent), the machine you connect to cannot access the keys in your
> agent, regardless of the number of intermediate hops.

Let's not discuss this, let's just assume situation where you do need to jump
between multiple hosts in two different security domains.
If there is usage scenario for ForwardAgent, there is usage scenario for
ForwardAgent in multiple security domains.

> By default ForwardAgent should be set to "no" in ssh_config. ?If you run
> a distribution that has ForwardAgent set to "yes" by default, please
> inform them that it should *always* default to "no". ?This would be a
> serious bug.

No, I've not ran into one. And this thread is exactly because I need to
now add agent towards another domain, to which I don't want to expose
my domain1 keys.

-- 
? ++ytti

From peter at stuge.se  Thu Oct 27 06:29:45 2011
From: peter at stuge.se (Peter Stuge)
Date: Wed, 26 Oct 2011 21:29:45 +0200
Subject: ssh-agent use in different security domains
In-Reply-To: <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
Message-ID: <20111026192945.26695.qmail@stuge.se>

Saku Ytti wrote:
> Maybe 'ssh-add -c' is something I want (otoh it should prompt always?
> Which would be annoying.

I don't find it so annoying. It takes a few logins to get used to the
extra prompt, but that's it. I use x11-ssh-askpass which is fast and
shows an unobtrusive prompt.


//Peter

From peter at stuge.se  Thu Oct 27 06:31:26 2011
From: peter at stuge.se (Peter Stuge)
Date: Wed, 26 Oct 2011 21:31:26 +0200
Subject: ssh-agent use in different security domains
In-Reply-To: <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
Message-ID: <20111026193126.26982.qmail@stuge.se>

Damien Miller wrote:
> if the agent code were in a library

There's agent client code in libssh2, enough for talking to an agent
but not for being one.


//Peter

From saku at ytti.fi  Thu Oct 27 06:43:10 2011
From: saku at ytti.fi (Saku Ytti)
Date: Wed, 26 Oct 2011 22:43:10 +0300
Subject: ssh-agent use in different security domains
In-Reply-To: <20111026192945.26695.qmail@stuge.se>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
 <20111026192945.26695.qmail@stuge.se>
Message-ID: <CAAeewD-8zQWRBP=27zmwpyKBngTF8kKwRWReNbFbAz8ihbUN6A@mail.gmail.com>

On 26 October 2011 22:29, Peter Stuge <peter at stuge.se> wrote:

>> Maybe 'ssh-add -c' is something I want (otoh it should prompt always?
>> Which would be annoying.
>
> I don't find it so annoying. It takes a few logins to get used to the
> extra prompt, but that's it. I use x11-ssh-askpass which is fast and
> shows an unobtrusive prompt.

Well I must agree with you, considering the alternative being insecure
by definition or not using ssh-agent. It doesn't seem like that big problem.

(I figured out why it didn't work for me, I'm using some gnome agent, which
likely does not support this or is just buggy)

Anyhow my coworker is quite seriously thinking writing patch, which
would  display prompt for sign requests ncluding full path between
requested and localhost, (or for legacy hosts it would just prompt
that 'legacy hosts wants to sign with identity foo', no path, no host
displayed)

He said it's not exactly difficult patch to make. But how likely it would be
to get something like this integrated upstream?

Today I feel that most people simply accept the security risk, if you have
multiple ssh keys in your 'ssh-add' and you're not using -c, you are highly
likely accessing two or more security domains and are bridging the domains
together.

-- 
? ++ytti

From keisial at gmail.com  Thu Oct 27 07:09:31 2011
From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=)
Date: Wed, 26 Oct 2011 22:09:31 +0200
Subject: ssh-agent use in different security domains
In-Reply-To: <CAAeewD91MuKmKPxcejf9fDfEfUmEASZCqA_s0Fv7Av3t8g5T8w@mail.gmail.com>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
 <4EA85490.2010303@fifthhorseman.net>
 <CAAeewD91MuKmKPxcejf9fDfEfUmEASZCqA_s0Fv7Av3t8g5T8w@mail.gmail.com>
Message-ID: <4EA868FB.3050604@gmail.com>

Saku Ytti wrote:
>> But this connection is good:
>>
>>  ssh -oProxyCommand='ssh -W %h:%p monkey.example' banana.example
> Lets assume banana lives in domain2.
>
> Help me understand. How does this help? If you login to banana with
> ssh-agent, cant banana hijack my session and use /any/ key I have in
> ssh-agent to ssh in domain1 servers?

Only your ssh program instance can talk with your ssh-agent, because it
is running locally. Without agent forwarding, programs on the other host
can't connect to your agent, much less use your keys.
Thus, that leaves only one point in which the server could use your agent:
in the initial connection when you use the agent to authenticate.
But the authentication is a signature to connection-specific data, so it
can't
be used to authenticate with a different host. It *could* MITM a connection
to a server on domain1 but:
a) The MITM would only be encrypted data.
b) You should notice the RSA mismatch.

What domain2 could do is to login you with a key designed just for domain1.
I guess it would be possible with a crafted sshd to detect if your user
foo is
the same as user bar on a different machine (for which you know the
public key).


From saku at ytti.fi  Thu Oct 27 07:14:18 2011
From: saku at ytti.fi (Saku Ytti)
Date: Wed, 26 Oct 2011 23:14:18 +0300
Subject: ssh-agent use in different security domains
In-Reply-To: <4EA868FB.3050604@gmail.com>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
 <4EA85490.2010303@fifthhorseman.net>
 <CAAeewD91MuKmKPxcejf9fDfEfUmEASZCqA_s0Fv7Av3t8g5T8w@mail.gmail.com>
 <4EA868FB.3050604@gmail.com>
Message-ID: <CAAeewD8zQF2xZQP8NSgy-zBzAPFGgk0P3oALb57esgR1PyefyA@mail.gmail.com>

2011/10/26 ?ngel Gonz?lez <keisial at gmail.com>:

> Only your ssh program instance can talk with your ssh-agent, because it
> is running locally. Without agent forwarding, programs on the other host
> can't connect to your agent, much less use your keys.

Quite, but question here is, when you need to have ssh-agent in two different
security domains. How do to do it.

Right now my solution seems to be that the higher security domain (domain1)
I'll add with ssh-add -c and the less secure I can add normally (I don't care
if domain1 evil admin hijacks and jumps to domain2 as me).

To decrease annoyance of constant prompt, I'll use ControlMaster for domain1.

It's not optimal solution, but it's something that can be done today.

Optiomal solution will inform ssh-agent who exactly is requesting the signing,
so user can decide if it's expected/allowed or not.



-- 
? ++ytti

From dkg at fifthhorseman.net  Thu Oct 27 07:46:43 2011
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 26 Oct 2011 16:46:43 -0400
Subject: ssh-agent use in different security domains
In-Reply-To: <CAAeewD-8zQWRBP=27zmwpyKBngTF8kKwRWReNbFbAz8ihbUN6A@mail.gmail.com>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
 <20111026192945.26695.qmail@stuge.se>
 <CAAeewD-8zQWRBP=27zmwpyKBngTF8kKwRWReNbFbAz8ihbUN6A@mail.gmail.com>
Message-ID: <4EA871B3.2030908@fifthhorseman.net>

On 10/26/2011 03:43 PM, Saku Ytti wrote:
> On 26 October 2011 22:29, Peter Stuge <peter at stuge.se> wrote:
> 
>>> Maybe 'ssh-add -c' is something I want (otoh it should prompt always?
>>> Which would be annoying.
>>
>> I don't find it so annoying. It takes a few logins to get used to the
>> extra prompt, but that's it. I use x11-ssh-askpass which is fast and
>> shows an unobtrusive prompt.
> 
> Well I must agree with you, considering the alternative being insecure
> by definition or not using ssh-agent. It doesn't seem like that big problem.
> 
> (I figured out why it didn't work for me, I'm using some gnome agent, which
> likely does not support this or is just buggy)

This is the relevant bug against gnome's ssh-agent implementation:

 https://bugzilla.gnome.org/show_bug.cgi?id=525574

Please follow up there if you have suggestions for the GNOME team.  thanks!

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20111026/d2699b4b/attachment.bin>

From peter at stuge.se  Thu Oct 27 07:49:00 2011
From: peter at stuge.se (Peter Stuge)
Date: Wed, 26 Oct 2011 22:49:00 +0200
Subject: ssh-agent use in different security domains
In-Reply-To: <CAAeewD8zQF2xZQP8NSgy-zBzAPFGgk0P3oALb57esgR1PyefyA@mail.gmail.com>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
 <4EA85490.2010303@fifthhorseman.net>
 <CAAeewD91MuKmKPxcejf9fDfEfUmEASZCqA_s0Fv7Av3t8g5T8w@mail.gmail.com>
 <4EA868FB.3050604@gmail.com>
 <CAAeewD8zQF2xZQP8NSgy-zBzAPFGgk0P3oALb57esgR1PyefyA@mail.gmail.com>
Message-ID: <20111026204900.4851.qmail@stuge.se>

Saku Ytti wrote:
> > Only your ssh program instance can talk with your ssh-agent, because it
> > is running locally. Without agent forwarding, programs on the other host
> > can't connect to your agent, much less use your keys.
> 
> Quite, but question here is, when you need to have ssh-agent in two
> different security domains. How do to do it.

You're basically not supposed to.

Instead, you let each hop in every domain talk with your agent
directly, without using forwarding.


> Right now my solution seems to be that the higher security domain
> (domain1) I'll add with ssh-add -c and the less secure I can add
> normally (I don't care if domain1 evil admin hijacks and jumps to
> domain2 as me).

The logic seems inverted. Add the less secure domain with -c.


> To decrease annoyance of constant prompt, I'll use ControlMaster
> for domain1.

It's not so annoying, really. But ControlMaster is a good idea in any
case! It makes everything faster too!


> Optiomal solution will inform ssh-agent who exactly is requesting
> the signing, so user can decide if it's expected/allowed or not.

Regardless of C skill you've studied the SSH and agent protocols by
now, so you know that this is not so simple.


//Peter

From dkg at fifthhorseman.net  Thu Oct 27 07:52:43 2011
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 26 Oct 2011 16:52:43 -0400
Subject: ssh-agent use in different security domains
In-Reply-To: <CAAeewD_3zG3unaw9q-ySjcbcAAAkmJEOhuUWv+rjvHouszm++g@mail.gmail.com>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
 <4EA85490.2010303@fifthhorseman.net>
 <CAAeewD91MuKmKPxcejf9fDfEfUmEASZCqA_s0Fv7Av3t8g5T8w@mail.gmail.com>
 <4EA85B3E.9050303@fifthhorseman.net>
 <CAAeewD_3zG3unaw9q-ySjcbcAAAkmJEOhuUWv+rjvHouszm++g@mail.gmail.com>
Message-ID: <4EA8731B.9020906@fifthhorseman.net>

On 10/26/2011 03:15 PM, Saku Ytti wrote:
> If there is usage scenario for ForwardAgent, there is usage scenario for
> ForwardAgent in multiple security domains.

I suppose i'm arguing right now that the only legitimate usage scenario
for ForwardAgent is when the user doesn't understand how to use
ProxyCommand for a jumphost.

I'd rather streamline the jumphost case than add extra cruft that might
encourage users to forward their agent.

If someone can propose a legitimate situation where agent forwarding is
needed, i'd like to hear about it.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20111026/a4b39db0/attachment.bin>

From keisial at gmail.com  Thu Oct 27 08:48:10 2011
From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=)
Date: Wed, 26 Oct 2011 23:48:10 +0200
Subject: ssh-agent use in different security domains
In-Reply-To: <CAAeewD8zQF2xZQP8NSgy-zBzAPFGgk0P3oALb57esgR1PyefyA@mail.gmail.com>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
 <4EA85490.2010303@fifthhorseman.net>
 <CAAeewD91MuKmKPxcejf9fDfEfUmEASZCqA_s0Fv7Av3t8g5T8w@mail.gmail.com>
 <4EA868FB.3050604@gmail.com>
 <CAAeewD8zQF2xZQP8NSgy-zBzAPFGgk0P3oALb57esgR1PyefyA@mail.gmail.com>
Message-ID: <4EA8801A.6050009@gmail.com>

Saku Ytti wrote:
> 2011/10/26 ?ngel Gonz?lez <keisial at gmail.com>:
>
>> Only your ssh program instance can talk with your ssh-agent, because it
>> is running locally. Without agent forwarding, programs on the other host
>> can't connect to your agent, much less use your keys.
> Quite, but question here is, when you need to have ssh-agent in two different
> security domains. How do to do it.
What's your problem with the jumphosts solution dkg proposed?

You connect to monkey and tell monkey to tunnel a connection to banana.
A second ssh instance is launched *in your computer* which connects to
banana through that tunnel.
You have two ssh instances locally and no agent forwarding (thus no
identity thief).


From djm at mindrot.org  Thu Oct 27 11:08:10 2011
From: djm at mindrot.org (Damien Miller)
Date: Thu, 27 Oct 2011 11:08:10 +1100 (EST)
Subject: ssh-agent use in different security domains
In-Reply-To: <4EA8731B.9020906@fifthhorseman.net>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
 <4EA85490.2010303@fifthhorseman.net>
 <CAAeewD91MuKmKPxcejf9fDfEfUmEASZCqA_s0Fv7Av3t8g5T8w@mail.gmail.com>
 <4EA85B3E.9050303@fifthhorseman.net>
 <CAAeewD_3zG3unaw9q-ySjcbcAAAkmJEOhuUWv+rjvHouszm++g@mail.gmail.com>
 <4EA8731B.9020906@fifthhorseman.net>
Message-ID: <alpine.BSO.2.00.1110271107170.14389@natsu.mindrot.org>

On Wed, 26 Oct 2011, Daniel Kahn Gillmor wrote:

> On 10/26/2011 03:15 PM, Saku Ytti wrote:
> > If there is usage scenario for ForwardAgent, there is usage scenario for
> > ForwardAgent in multiple security domains.
> 
> I suppose i'm arguing right now that the only legitimate usage scenario
> for ForwardAgent is when the user doesn't understand how to use
> ProxyCommand for a jumphost.
> 
> I'd rather streamline the jumphost case than add extra cruft that might
> encourage users to forward their agent.
> 
> If someone can propose a legitimate situation where agent forwarding is
> needed, i'd like to hear about it.

Yeah, agent forwarding predates stdio forwarding by more than a decade.
I don't have time to write it, but a good explanation and HOWTO seems in
order.

-d

From saku at ytti.fi  Thu Oct 27 16:58:07 2011
From: saku at ytti.fi (Saku Ytti)
Date: Thu, 27 Oct 2011 08:58:07 +0300
Subject: ssh-agent use in different security domains
In-Reply-To: <4EA8731B.9020906@fifthhorseman.net>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
 <4EA85490.2010303@fifthhorseman.net>
 <CAAeewD91MuKmKPxcejf9fDfEfUmEASZCqA_s0Fv7Av3t8g5T8w@mail.gmail.com>
 <4EA85B3E.9050303@fifthhorseman.net>
 <CAAeewD_3zG3unaw9q-ySjcbcAAAkmJEOhuUWv+rjvHouszm++g@mail.gmail.com>
 <4EA8731B.9020906@fifthhorseman.net>
Message-ID: <CAAeewD-d++Z9vUaTHafFvFk5SritAHcr5mS4qKdDtE57+o3Zqg@mail.gmail.com>

On 26 October 2011 23:52, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:

> I suppose i'm arguing right now that the only legitimate usage scenario
> for ForwardAgent is when the user doesn't understand how to use
> ProxyCommand for a jumphost.
>
> I'd rather streamline the jumphost case than add extra cruft that might
> encourage users to forward their agent.

I sometimes need to jump from several intermediate routers and it seems to
me there is somewhat large overhead (as of  today) on using it.
I might be in domain2-server1 and need to jump back and forth on several
domain2 servers, and sometimes not even directly from server1 to serverN
but server7 might only be reachable from server3 or so.

I suppose ProxyCommand is easier to fix, as it requires no protocol
changes, and I'm certainly biased as I've used agent lot, but not
ProxyCommand. Just hard to imagine how to make it as unobtrusive
as ssh-agent, only thing ssh-agent really is missing (and only thing makes
it insecure) is not having any idea who is requesting the signing.



-- 
? ++ytti

From saku at ytti.fi  Thu Oct 27 17:00:02 2011
From: saku at ytti.fi (Saku Ytti)
Date: Thu, 27 Oct 2011 09:00:02 +0300
Subject: ssh-agent use in different security domains
In-Reply-To: <4EA8801A.6050009@gmail.com>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
 <4EA85490.2010303@fifthhorseman.net>
 <CAAeewD91MuKmKPxcejf9fDfEfUmEASZCqA_s0Fv7Av3t8g5T8w@mail.gmail.com>
 <4EA868FB.3050604@gmail.com>
 <CAAeewD8zQF2xZQP8NSgy-zBzAPFGgk0P3oALb57esgR1PyefyA@mail.gmail.com>
 <4EA8801A.6050009@gmail.com>
Message-ID: <CAAeewD8DzLxvSNfFb_5mx_pe6PoSts6752bjKOO9FJvtEQ8FhQ@mail.gmail.com>

2011/10/27 ?ngel Gonz?lez <keisial at gmail.com>:

> What's your problem with the jumphosts solution dkg proposed?

Maybe there isn't, maybe I judged it unfairly out of being used to agent. But
quickly it seems like lot of overhead, when agent has 0 overhead once
setup, normal ssh host works just fine.

> You connect to monkey and tell monkey to tunnel a connection to banana.
> A second ssh instance is launched *in your computer* which connects to
> banana through that tunnel.
> You have two ssh instances locally and no agent forwarding (thus no
> identity thief).

Yeah I get the idea, from security POV I'm always connecting directly, thus
no need for agent traversing network. Just setting it up where you need to jump
back-and-forth often and possibly through several intermediate routers seems
bit high.




-- 
? ++ytti

From saku at ytti.fi  Thu Oct 27 17:01:20 2011
From: saku at ytti.fi (Saku Ytti)
Date: Thu, 27 Oct 2011 09:01:20 +0300
Subject: ssh-agent use in different security domains
In-Reply-To: <20111026204900.4851.qmail@stuge.se>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
 <4EA85490.2010303@fifthhorseman.net>
 <CAAeewD91MuKmKPxcejf9fDfEfUmEASZCqA_s0Fv7Av3t8g5T8w@mail.gmail.com>
 <4EA868FB.3050604@gmail.com>
 <CAAeewD8zQF2xZQP8NSgy-zBzAPFGgk0P3oALb57esgR1PyefyA@mail.gmail.com>
 <20111026204900.4851.qmail@stuge.se>
Message-ID: <CAAeewD8MO++5KjHK18ofF82JO8zBtHOpX+MpZP_MYXTQ_HUegg@mail.gmail.com>

On 26 October 2011 23:49, Peter Stuge <peter at stuge.se> wrote:

> Regardless of C skill you've studied the SSH and agent protocols by
> now, so you know that this is not so simple.

Be that as it may. But if such patch would surface, where ssh gets
infrastructure for passing full sign path to ssh-agent, which is backward
compatible (just no path shown). What are chances that it would be
accepted by upstream?
Right now my gut feeling is from it's about 0 to the measurement precision.

-- 
? ++ytti

From saku at ytti.fi  Thu Oct 27 16:52:08 2011
From: saku at ytti.fi (Saku Ytti)
Date: Thu, 27 Oct 2011 08:52:08 +0300
Subject: ssh-agent use in different security domains
In-Reply-To: <20111026204900.4851.qmail@stuge.se>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
 <4EA85490.2010303@fifthhorseman.net>
 <CAAeewD91MuKmKPxcejf9fDfEfUmEASZCqA_s0Fv7Av3t8g5T8w@mail.gmail.com>
 <4EA868FB.3050604@gmail.com>
 <CAAeewD8zQF2xZQP8NSgy-zBzAPFGgk0P3oALb57esgR1PyefyA@mail.gmail.com>
 <20111026204900.4851.qmail@stuge.se>
Message-ID: <CAAeewD9aFnC9=76BkEF14baDeUuAP=HVWcrGPWm+F-8Df9dAQw@mail.gmail.com>

On 26 October 2011 23:49, Peter Stuge <peter at stuge.se> wrote:
>> Right now my solution seems to be that the higher security domain
>> (domain1) I'll add with ssh-add -c and the less secure I can add
>> normally (I don't care if domain1 evil admin hijacks and jumps to
>> domain2 as me).
>
> The logic seems inverted. Add the less secure domain with -c.

Why? I would prefer to be warned when the more secure is being
used? I.e. if Evil Admin of less secure domain tries to sign
something with my more secure key, I'd get prompt for it.
If Evil Admin of more secure domain tries to access my less
secure key, I don't care so much



-- 
? ++ytti

From apb at cequrux.com  Thu Oct 27 17:42:33 2011
From: apb at cequrux.com (Alan Barrett)
Date: Thu, 27 Oct 2011 08:42:33 +0200
Subject: ssh-agent use in different security domains
In-Reply-To: <CAAeewD8DzLxvSNfFb_5mx_pe6PoSts6752bjKOO9FJvtEQ8FhQ@mail.gmail.com>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
 <4EA85490.2010303@fifthhorseman.net>
 <CAAeewD91MuKmKPxcejf9fDfEfUmEASZCqA_s0Fv7Av3t8g5T8w@mail.gmail.com>
 <4EA868FB.3050604@gmail.com>
 <CAAeewD8zQF2xZQP8NSgy-zBzAPFGgk0P3oALb57esgR1PyefyA@mail.gmail.com>
 <4EA8801A.6050009@gmail.com>
 <CAAeewD8DzLxvSNfFb_5mx_pe6PoSts6752bjKOO9FJvtEQ8FhQ@mail.gmail.com>
Message-ID: <20111027064233.GA1639@apb-laptoy.apb.alt.za>

On Thu, 27 Oct 2011, Saku Ytti wrote:
>> What's your problem with the jumphosts solution dkg proposed?
>
> Maybe there isn't, maybe I judged it unfairly out of being used 
> to agent. But quickly it seems like lot of overhead, when agent 
> has 0 overhead once setup, normal ssh host works just fine.

Once you add a fewlines to your .ssh/config, normal "ssh host" works
fine with ProxyCommand too.  Just add this to .ssh/config:

     Host target.example
         ProxyCommand ssh -W %h:%p user at intermediary.example

and then you can simnply run "ssh target.example" and the right thing
will happen: behind the scenes, it will run "ssh -W target.example:22
user at intermediary.example" (which will use your ssh agent if
appropriate), and then it will tunnel a connection to target.example
using the channel through intermediary.example (which will again use
your ssh agent if appropriate).

Sure, you'll use a little more CPU and network resources
than with

     ssh user at intermediary.example ssh user at target.example

but you probably won't notice the difference, and it's easier and 
safer.

It used to be difficult to write ProxyCommand scripts that did not 
rely on special software on the intermediary host, but now "ssh 
-W" makes it so easy.  (I wrote a >100 line perl script several 
years ago to provide the interface that "ssh -W" provides today; 
it had to loop searching for an available local TCP port to use, 
run a child ssh process with an appropriate "-L" option, run 
another process to copy stdin/stdout to/from the local TCP port, 
and it needed to carefully clean up after a signal.)

--apb (Alan Barrett)

From alex at alex.org.uk  Thu Oct 27 17:52:26 2011
From: alex at alex.org.uk (Alex Bligh)
Date: Thu, 27 Oct 2011 07:52:26 +0100
Subject: ssh-agent use in different security domains
In-Reply-To: <4EA8731B.9020906@fifthhorseman.net>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
 <4EA85490.2010303@fifthhorseman.net>
 <CAAeewD91MuKmKPxcejf9fDfEfUmEASZCqA_s0Fv7Av3t8g5T8w@mail.gmail.com>
 <4EA85B3E.9050303@fifthhorseman.net>
 <CAAeewD_3zG3unaw9q-ySjcbcAAAkmJEOhuUWv+rjvHouszm++g@mail.gmail.com>
 <4EA8731B.9020906@fifthhorseman.net>
Message-ID: <260FB869588EFDFDDAF3B07C@nimrod.local>



--On 26 October 2011 16:52:43 -0400 Daniel Kahn Gillmor 
<dkg at fifthhorseman.net> wrote:

> On 10/26/2011 03:15 PM, Saku Ytti wrote:
>> If there is usage scenario for ForwardAgent, there is usage scenario for
>> ForwardAgent in multiple security domains.
>
> I suppose i'm arguing right now that the only legitimate usage scenario
> for ForwardAgent is when the user doesn't understand how to use
> ProxyCommand for a jumphost.

I think if anything you've understated the problems of agent forwarding.

Firstly, the problem you've already mentioned (which is solved by the 
proxycommand approach): the agent provides the data necessary to log into 
the remote host (based on the private key) at the instigation of an 
intermediate host, which might be compromised. Whilst the intermediate host 
does not get the private key, there is currently nothing in the protocol to 
prevent the intermediate host asking for such a key for bogus reasons, 
which as far as I can tell is as good as having access to the private key 
whilst the ssh session is up. Even if something was done with the host key 
of the remote host such that the private key could only be used to ssh to 
that host, nothing would stop the intermediate host using this to ssh in to 
that host and perform different commands from those the user intended. I 
think this is unfixable.

Secondly, the problem you haven't mentioned (which is also solved by the 
proxy command): a root user on the intermediate session has access to the 
cleartext of the session to the remote host.

There is a quasi-legitimate reason for ForwardAgent: where the intermediate 
host is in the same trust zone, but it is inconvenient to store the private 
keys there, or where the private keys are encrypted and there's some 
friendly UI at the local host. Though these also work with ProxyCommand, I 
am not sure you can ProxyCommand and ssh -W with (e.g.) scp. How do you do, 
for instance "scp -3" with two different ProxyCommands?

I'm also not sure you can use ProxyCommand to use more than one 
intermediate host in a row.

What I'd like to see is (and I think this is just command line processing, 
plus possibly detection of -W support on the intermediate host):

   ssh --via intermediateA1.example.com
       --via intermediateA2.example.com
       remoteA.example.com

and

   scp -3 --via intermediateA1.example.com
          --via intermediateA2.example.com
          remoteA.example.com:file
          --via intermediateB1.example.com
          --via intermediateB2.example.com
          remoteB.example.com:file

For completeness, rather than -W, I've used port forwarding of port 22 to
achieve the same thing. This can cope with as many hops as you like, but
is a bit clunky.

-- 
Alex Bligh

From apb at cequrux.com  Thu Oct 27 18:36:13 2011
From: apb at cequrux.com (Alan Barrett)
Date: Thu, 27 Oct 2011 09:36:13 +0200
Subject: ssh-agent use in different security domains
In-Reply-To: <260FB869588EFDFDDAF3B07C@nimrod.local>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
 <4EA85490.2010303@fifthhorseman.net>
 <CAAeewD91MuKmKPxcejf9fDfEfUmEASZCqA_s0Fv7Av3t8g5T8w@mail.gmail.com>
 <4EA85B3E.9050303@fifthhorseman.net>
 <CAAeewD_3zG3unaw9q-ySjcbcAAAkmJEOhuUWv+rjvHouszm++g@mail.gmail.com>
 <4EA8731B.9020906@fifthhorseman.net>
 <260FB869588EFDFDDAF3B07C@nimrod.local>
Message-ID: <20111027073613.GA1500@apb-laptoy.apb.alt.za>

On Thu, 27 Oct 2011, Alex Bligh wrote:
>I'm also not sure you can use ProxyCommand to use more than one 
>intermediate host in a row.

You can.  Just put this in your .ssh/config, and then run "ssh host3".
It works fine for scp too.

     Host host3
        ProxyCommand ssh -W %h:%p host2
        User user3
     Host host2
        ProxyCommand ssh -W %h:%p host1
        User user2
     Host host1
        User user1

>What I'd like to see is (and I think this is just command line 
>processing, plus possibly detection of -W support on the intermediate 
>host):
>
>  ssh --via intermediateA1.example.com
>      --via intermediateA2.example.com
>      remoteA.example.com
>
>  scp -3 --via intermediateA1.example.com
>         --via intermediateA2.example.com
>         remoteA.example.com:file
>         --via intermediateB1.example.com
>         remoteB.example.com:file

There's no need for -W support on intermediate hosts; 
the intermediate host sees a channel request that's 
(almost?) indistinguishable from what would happen with "-L".

I agree that "--via" would be a convenient command line shorthand 
for cases where you don't want to edit .ssh/config.  (Passing -O 
ProxyCommand on a command line typed by hand is cumbersome for one 
hop, and infeasible for more than one hop.)

--apb (Alan Barrett)

From saku at ytti.fi  Thu Oct 27 19:07:40 2011
From: saku at ytti.fi (Saku Ytti)
Date: Thu, 27 Oct 2011 11:07:40 +0300
Subject: ssh-agent use in different security domains
In-Reply-To: <20111027073613.GA1500@apb-laptoy.apb.alt.za>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
 <4EA85490.2010303@fifthhorseman.net>
 <CAAeewD91MuKmKPxcejf9fDfEfUmEASZCqA_s0Fv7Av3t8g5T8w@mail.gmail.com>
 <4EA85B3E.9050303@fifthhorseman.net>
 <CAAeewD_3zG3unaw9q-ySjcbcAAAkmJEOhuUWv+rjvHouszm++g@mail.gmail.com>
 <4EA8731B.9020906@fifthhorseman.net>
 <260FB869588EFDFDDAF3B07C@nimrod.local>
 <20111027073613.GA1500@apb-laptoy.apb.alt.za>
Message-ID: <CAAeewD_2RCxhXEaYmPngQrG3n35MeS5zezjCTNGj=SArWf1bsw@mail.gmail.com>

On 27 October 2011 10:36, Alan Barrett <apb at cequrux.com> wrote:

> I agree that "--via" would be a convenient command line shorthand for cases
> where you don't want to edit .ssh/config. ?(Passing -O ProxyCommand on a
> command line typed by hand is cumbersome for one hop, and infeasible for
> more than one hop.)

Or maybe just 'ssh box1,box2,box3' which would be equivalent to

cat >> .ssh/config
box3
  path box1,box2

Or original problem:
cat >> .ssh/config
box *domain1
  path box1,domain1-jump-box
box *domain2
  path box1,domain2-jump-box


-- 
? ++ytti

From saku at ytti.fi  Thu Oct 27 19:08:34 2011
From: saku at ytti.fi (Saku Ytti)
Date: Thu, 27 Oct 2011 11:08:34 +0300
Subject: ssh-agent use in different security domains
In-Reply-To: <CAAeewD_2RCxhXEaYmPngQrG3n35MeS5zezjCTNGj=SArWf1bsw@mail.gmail.com>
References: <CAAeewD-B8rhi6rUrY-HP4ZBz-PXCqBsUjP3YpUxgC2SwydweWQ@mail.gmail.com>
 <alpine.BSO.2.00.1110252118380.27574@natsu.mindrot.org>
 <CAAeewD-2Qe4GexetNFWOq_7XrnuB3hWj234Qwtk1JQo2J5ZJsg@mail.gmail.com>
 <4EA85490.2010303@fifthhorseman.net>
 <CAAeewD91MuKmKPxcejf9fDfEfUmEASZCqA_s0Fv7Av3t8g5T8w@mail.gmail.com>
 <4EA85B3E.9050303@fifthhorseman.net>
 <CAAeewD_3zG3unaw9q-ySjcbcAAAkmJEOhuUWv+rjvHouszm++g@mail.gmail.com>
 <4EA8731B.9020906@fifthhorseman.net>
 <260FB869588EFDFDDAF3B07C@nimrod.local>
 <20111027073613.GA1500@apb-laptoy.apb.alt.za>
 <CAAeewD_2RCxhXEaYmPngQrG3n35MeS5zezjCTNGj=SArWf1bsw@mail.gmail.com>
Message-ID: <CAAeewD8pQUJe--+3qWfYZ62U6VEDcRjATd1P-zT6zXMiBC-oKA@mail.gmail.com>

Gnaah host box3 and s/box /host /, obviously.

On 27 October 2011 11:07, Saku Ytti <saku at ytti.fi> wrote:
> On 27 October 2011 10:36, Alan Barrett <apb at cequrux.com> wrote:
>
>> I agree that "--via" would be a convenient command line shorthand for cases
>> where you don't want to edit .ssh/config. ?(Passing -O ProxyCommand on a
>> command line typed by hand is cumbersome for one hop, and infeasible for
>> more than one hop.)
>
> Or maybe just 'ssh box1,box2,box3' which would be equivalent to
>
> cat >> .ssh/config
> box3
> ?path box1,box2
>
> Or original problem:
> cat >> .ssh/config
> box *domain1
> ?path box1,domain1-jump-box
> box *domain2
> ?path box1,domain2-jump-box
>
>
> --
> ? ++ytti
>



-- 
? ++ytti