gmane.network.openssh.devel

Re: [PATCH] Expose remote forwarding ports as environment variable

Alex Bligh — 2013-05-18T09:02:54

On 17 May 2013, at 23:07, Darren Tucker wrote:


Doh - it's a parameter to the second ssh, not the first - sorry.

Re: [PATCH] Expose remote forwarding ports as environment variable

Darren Tucker — 2013-05-17T22:07:54


Enforce it via ForceCommand?

Re: [PATCH] Expose remote forwarding ports as environment variable

Alex Bligh — 2013-05-17T14:38:23

On 17 May 2013, at 14:30, Darren Tucker wrote:



The problem for me is at this step. You have to trust the client's command
on the server. What happens if they don't pass the correct -MS command?

In my application the clients are untrusted machines which may be behind
NATs etc.

Re: [PATCH] Allow matching HostName against Host entries

Ryan Kavanagh — 2013-05-17T14:06:31

Hi all,

On Thu, May 02, 2013 at 10:32:15PM -0400, Ryan Kavanagh wrote:

Again, I think this patch would be useful to have incorporated into
OpenSSH. Is there anything I can do to help get it incorporated /
reviewed? Does anybody have any remaining concerns, or is it mostly an
issue of someone getting around to applying it?

Best wishes,
Ryan

Re: [PATCH] Expose remote forwarding ports as environment variable

Nico Schottelius — 2013-05-17T14:09:32

Darren Tucker [Fri, May 17, 2013 at 11:30:03PM +1000]:

That is but a very cool solution. I must admit, I've not considered
this approach beforehand.

I must confess that I like this approach, not just because it's very
advanced and creative usage,

Independently of this, I was wondering, if my supplied patch could be
applied anyhow, because I think it makes ssh callback easier to
access.

Cheers,

Nico

Re: [PATCH] Expose remote forwarding ports as environment variable

Darren Tucker — 2013-05-17T13:30:03

On Fri, May 17, 2013 at 10:53 PM, Nico Schottelius <
nico-openssh-unix-dev< at >schottelius.org> wrote:


Markus actually added support to ProxyCommand to allow it to use stdin and
stdout directly so you can make ssh talk back to an sshd on the "client"
end via a pair of named pipes.  It's a bit Rube Goldberg but knowing Markus
I don't doubt it works.

1) on the client create a pair of named pipes
2) have ssh #1 on the client invoke a controlmaster ssh -N #2 on the server
with the latter using "ProxyCommand=-". Redirect ssh #1's stdio to and from
the named pipes and background it.

client$ ssh <fromssh >tossh -T -y server ssh -y -N -T -MS/tmp/ctl
-oProxyCommand=- client &

3) start and sshd on the client with its stdin connected to those named
pipes:

client$ /usr/sbin/sshd -i -f < $fromssh > $tossh

4) on the server, use the control socket to talk to the sshd running on the
"client".
server$ ssh -S /tmp/ctl client

You could probably use socat on the machine to connect stdio on ssh and
sshd on the client which m

Re: [PATCH] Expose remote forwarding ports as environment variable

Nico Schottelius — 2013-05-17T12:53:17

Philipp Marek [Fri, May 17, 2013 at 07:19:16AM +0200]:

I was actually considering this option before writing the patch.

Unfortunately there are various problems with this approach,
to name two:

    - It requires socat additionally on both sides
    - Socat only allows 1 (!) connection and exits afterwards,
      so it does not solve the problem of accessing the box multiple
      times (like required by cdist/ccollect)

Furthermore, one of the biggest advantages of using ssh
code is that robust code to handle the problem is already in place.
OpenSSH just would need to expose this information.


Yep, would have been nice if it worked easily and reliably.

Cheers,

Nico

socat session:

~/.ssh/authorized_keys:

    command="socat - TCP-LISTEN:1234" ssh-rsa AAAAB3NzaC1yc

[13:21] bento:~% socat TCP4:localhost:22,forever "EXEC:ssh nico-dev-vm-snr01"
Pseudo-terminal will not be allocated because stdin is not a terminal.

[root< at >nico-dev-vm-snr01 yum.repos.d]# ssh -p 1234 root< at >localhost
exit

[13:21] bento:~% so

Re: how to check whether the ssh tunnel is up

Vincent Lin — 2013-05-17T06:30:41

Hi Gert,

But SSH knows. I have added some code in the openssh client part. If the
remote socket is ready, the ssh server will send the result to the ssh
client. Once the client receives the result, I can write to a file. And
other process can read the status from the file.

Thanks
Vincent


On Thu, May 16, 2013 at 4:21 PM, Gert Doering <gert< at >greenie.muc.de> wrote:

Re: [PATCH] Expose remote forwarding ports as environment variable

Philipp Marek — 2013-05-17T05:19:16

If you need a local TCP port, how about using socat to link it to SSH's 
stdin/stdout, and (if needed) do the reverse on the server side?

Then there's no port actually forwarded (just the "normal" data flow), 
so there won't (and can't) be any collisions, and you can simply 
determine which port is _really_ in use.


Regards,

Phil

Re: [PATCH] Specify PAM Service name in sshd_config

Darren Tucker — 2013-05-17T04:26:56

Here's the existing values across all of the places they show up:
http://www.dtucker.net/openssh/percent_expand_opts.html

Please try not to make it any more inconsistent :-)

Re: [PATCH] Specify PAM Service name in sshd_config

Damien Miller — 2013-05-17T01:58:50


Sorry, _local bind address_

Re: [PATCH] Specify PAM Service name in sshd_config

Damien Miller — 2013-05-16T23:42:54


I think this approach is reasonable. Whomever implements it, please
include host address too :)

I'm not sure what changes will be necessary to support this - remember
that we now offer multiple auth, so a user might run pubkey+kbdint or
GSSAPI+password. Which auth, account and session stack should we run in
these cases?

-d

Re: [PATCH] Expose remote forwarding ports as environment variable

Nico Schottelius — 2013-05-16T19:53:44

Darren Tucker [Thu, May 16, 2013 at 04:16:01PM +1000]:

That's a very good point, although I believe that the majority
of remote port forwardings is defined using -R and is never changed
in almost any cases.

That said, I'd propose to change the variable name to reflect
this and/or add a hint to the manpage describing this behaviour.


This is not exactly what I'm trying to accomplish.
I am sorry, I may have not made my intention clear enough.

My objective is to be able to connect back to the client
directly after the connection has been established from
the server, most likely using the authorized_keys file.

Let me show you an example:

controlhost:~cdist/.ssh/authorized_keys:

    command="cdist callback",no-pty ssh-dss...

targethost% ssh -R 0:localhost:22 cdist< at >controlhost cdist callback

cdist callback then uses the first value found in
$SSH_REMOTE_FORWARDING_PORTS and connects to that port to
configure the target host.

As pointed out by Alex, the patch I've provided solves the problem
to manage this

Re: [PATCH] Expose remote forwarding ports as environment variable

Alex Bligh — 2013-05-16T17:11:33

On 16 May 2013, at 07:16, Darren Tucker wrote:


Any ideas on how you can do this server side? EG, I have n people
with different public keys, Alice, Bob, Charlie, who each ssh in
with a forceCommand or similar to stop them doing anything except
a -R port forwarding, using the same UID.

At the server end, I want to connect to Alice's -R forwarding.
I can't rely on Alice telling me which -R port she's connecting
to, as she might tell me Bob's port. So I need to know which
session is associated Alice using server side information only.

I have a nasty hack which (in essence) involves making forceCommand
run something server side which records the PID of sshd, looks
at the table of listening sockets, sees what processes own them,
and links up the two. This is pretty disgusting.

Re: [PATCH] Specify PAM Service name in sshd_config

Schmidt, Kenneth P — 2013-05-16T15:52:42


On 5/15/13 12:36 p.m., "Ben Lindstrom" <mouring< at >eviladmin.org> wrote:


I agree.  I will code something up and submit a new patch that allows
macros.  I don't know what values are available at the point of
authentication, but it looks like anything in the authentication context
and global options are easily available.  I will start with the
executable, the authentication method, and the server port initially and
see if there are any other options we want to add later.

Re: how to check whether the ssh tunnel is up

Vincent Lin — 2013-05-16T08:15:07

Alex,

OK, I got it, all I want is to know the remote socket is ready so that the
server side can wirte data. I will leave the rest part to the server side.
I don't care whether the ssh tunnel is successful or not. And I can't know
that. The server side should take care of that tunnel.

Thanks
Vincent


On Thu, May 16, 2013 at 12:21 AM, Alex Bligh <alex< at >alex.org.uk> wrote:

Re: how to check whether the ssh tunnel is up

Gert Doering — 2013-05-16T08:21:00

Hi,

On Thu, May 16, 2013 at 04:15:07PM +0800, Vincent Lin wrote:

You actually can't know whether the remote socket is ready for *you* 
without checking the full path back to you - some other user on the
remote machine might already have opened the specific remote forwarding
port before...

gert

Re: Session rekeying support in OpenSSH

Darren Tucker — 2013-05-16T07:08:53

The changes to RekeyLimit have been committed and will be in the 6.3
release.  Here's the same changes against the just-released 6.2p2.

Index: clientloop.c
===================================================================
RCS file: /var/cvs/openssh/clientloop.c,v
retrieving revision 1.237
diff -u -p -r1.237 clientloop.c
--- clientloop.c9 Jan 2013 04:55:51 -00001.237
+++ clientloop.c16 May 2013 06:46:59 -0000
< at >< at > -583,7 +583,7 < at >< at > client_wait_until_can_do_something(fd_se
 {
 struct timeval tv, *tvp;
 int timeout_secs;
-time_t minwait_secs = 0;
+time_t minwait_secs = 0, server_alive_time = 0, now = time(NULL);
 int ret;
 
 /* Add any selections by the channel mechanism. */
< at >< at > -632,12 +632,16 < at >< at > client_wait_until_can_do_something(fd_se
  */
 
 timeout_secs = INT_MAX; /* we use INT_MAX to mean no timeout */
-if (options.server_alive_interval > 0 && compat20)
+if (options.server_alive_interval > 0 && compat20) {
 timeout_secs = options.server_alive_interval;
+server_alive_time = now + options.s

Re: [PATCH] Expose remote forwarding ports as environment variable

Darren Tucker — 2013-05-16T06:16:01

That's not going to be entirely accurate because the environment is
inherited at the time the shell is started, but port forwards can be
added and deleted at any time (either via escape sequences or the
control socket).

Taking the example from your web page, you can already do what you want
via the control socket:

$ ssh -Nf -MS/tmp/ctl localhost
$ p=`ssh -S/tmp/ctl -O forward -R 0:127.0.0.1:22 localhost`
Allocated port 24647 for remote forward to 127.0.0.1:22
$ ssh -S/tmp/ctl localhost "echo do something with port $p"
do something with port 24647
$ ssh -S/tmp/ctl -O exit localhost

Announce: Portable OpenSSH 6.2p2 released

Damien Miller — 2013-05-16T02:58:59

This is a portable OpenSSH bugfix release.

Changes since OpenSSH 6.2p1
===========================

Bugfixes:

 * ssh(1): Only warn for missing identity files that were explicitly
   specified.

 * Fix bug in contributed contrib/ssh-copy-id script that could result in
   "rm *" being called on mktemp failure. bz#2105

 * sshd(8): Quiet disconnect notifications on the server from error() back
   to logit() from error() for normal, client-initiated disconnections.
   bz#2057

 * Avoid conflicting definitions of __int64 on Cygwin

Checksums:
==========

 - SHA1 (openssh-6.2p2.tar.gz) = c2b4909eba6f5ec6f9f75866c202db47f3b501ba

Reporting Bugs:
===============

- Please read http://www.openssh.com/report.html
  Security bugs should be reported directly to openssh< at >openssh.com

OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt,
Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and
Ben Lindstrom.

Re: [PATCH] Specify PAM Service name in sshd_config

Ángel González — 2013-05-15T23:04:09

+1
Using a %macro in PAMServiceName is the way to go.