[Bug 2287] AuthorizedKeysCommandUser should have it's default documented

2014-12-11 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2287

Christoph Anton Mitterer  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #2 from Christoph Anton Mitterer  ---
Hi.

I've just tried that, and it seems it's not ignored, but sshd fails to
start, when AuthorizedKeysCommandUser is unset, while
AuthorizedKeysCommand is set.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2266] Bugs intended to be fixed in 6.8

2014-12-11 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2266
Bug 2266 depends on bug 2287, which changed state.

Bug 2287 Summary: AuthorizedKeysCommandUser should have it's default documented
https://bugzilla.mindrot.org/show_bug.cgi?id=2287

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching the reporter of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2310] functionality to start process before ssh and/or to "wrap" such command around ssh

2014-12-11 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2310

Christoph Anton Mitterer  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |---

--- Comment #3 from Christoph Anton Mitterer  ---
Actually I've made some further tests on this issue in the meantime and
it seems as if there is just some "timing issue", which is why I reopen
the issue for now, perhaps you can have a look, whether that could be
fixed easily.



Remember, what I've basically tried to achieve is to get automated
(i.e. passwordless) login to ssh hosts that require a kerberos ticket
(+afs) for login and for the home dir access.
And not only this, the whole thing should also work for multiple reams,
i.e. when I connect to some nodes at CERN I want a ticket for CERN.CH
being automatically generated and used with ssh,... while when I
contact
to the university's nodes, I want the same for the PHYISIK.LMU.DE
realm.


Okay from the k5start side everything seems to work. What I do is
basically
$ k5start -q -f kt -K 10 -- user@REALM ssh 

The keytab file (kt) works, and when I run ssh with the above, login
works fine as well and the I get an AFS ticket (it's probably created
on the server side).


Now I try to get the whole thing into ssh_config, because I want all be
done automatically and especially for different realms, so I do about
the following:

Host lxplus.cern.ch
GSSAPITrustDns yes

Host *.cern.ch
User mitterer
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
GSSAPIRenewalForcesRekey yes 
ProxyCommand k5start -q -f kt -K 10 -- mitte...@cern.ch nc %h
%p

The usage of ProxyCommand with k5start and nc is a hack here, which I
hoped to solve the problem that the ticket is generated before the
connection is done,... and nc %h %p simply passes everything through.
In other words, this is the trick which I've tried to get the feature
what I've asked for in the original submission of this ticket.


This however doesn't work, which makes sense, as the ssh process has no
way to know where the credential cache is that k5start creates randomly
for this program invocation (nc), e.g. at /tmp/krb5cc_1000_VZ7FI5.

It also exports KRB5CCNAME='FILE:/tmp/krb5cc_1000_CERN', of course, but
this only gets known to nc.

At that point, ssh already looked for KRB5CCNAME, didn't find any, and
never tries again.



Do you see any simple solution to get that working somehow? Maybe even
in a completely different way (extending ssh-agent and k5start to
interact?) or some other tricky hack?
If not, and you still think that adding such feature isn't worth to
make ssh nicely usable with kerberos, than just close it again if you
feel necessary.


Thanks,
Chris.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2310] functionality to start process before ssh and/or to "wrap" such command around ssh

2014-12-11 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2310

--- Comment #2 from Christoph Anton Mitterer  ---
(In reply to Damien Miller from comment #1)
> This functionality can easily be achieved using shell functions,
> shell aliases, shell scripts or wrapper binaries.

Could you please elaborate on how this can be easily achieved the ways
you describe, especially when considering that people may use arbitrary
HostName definitions or features like CanonicaliseHostname, which would
basically make it necessary for any wrapper program to implement a full
ssh_config parser.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2318] ControlPath name collisions when using shared locations like /tmp for the sockets.

2014-12-11 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2318

--- Comment #3 from Christoph Anton Mitterer  ---
(In reply to Damien Miller from comment #2)
> I don't see a compelling reason to change this.
Becuase it's a better an cleaner way of handling it, for those people
who do want to use shared locations, and likely is trivial or doesn't
require much work?

Apart from that,... same argumentation with the bug #2311 - since
closing that one is a mistake, closing this one is either.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2291] ssh -Q kex lists diffie-hellman-group1-sha1 twice

2014-12-11 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2291

--- Comment #2 from Christoph Anton Mitterer  ---
thx :)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2311] simple attack when control channel muxing is used

2014-12-11 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2311

--- Comment #6 from Christoph Anton Mitterer  ---
(In reply to Damien Miller from comment #4)
> As I mentioned, root being able to access user sockets is
> intentional behaviour. I'm not interested in adding additional
> checks to prevent this - they would need to be behind an option to
> avoid breaking existing, legitimate uses and I don't believe that
> the maintenance and complexity cost of a new config option is
> warranted.
> 
> Don't use shared directories for mux sockets.

It seems kinda strange that you blindly close this issue away, even
though it's a very valid issue (which someone might have sooner or
later worked upon - while now it will just be forgotten),... especially
since my analysis contained several other issues, which are not simply
solved by adding documentation.

Also you seem to completely ignore the security issue pointed out by
someone on the list, that it's apparently only the MUC server, which
makes UID checks while the client blindly trusts.

Especially when one looks at similar situations (strictmodes on key
files, etc.) where one didn't just let this handle improperly by
documentation, instead properly intercepting it on a code level.
Actually someone did even provide a patch which would have likely
properly fixed some of the issues described herein, so why didn't that
got merged?

Or is control muxing simply considered a dead feature where development
is no longer desired to be seen?




(In reply to Tomas Mraz from comment #5)
> It should be documented in the ssh manual page that the socket must
> be created in proper places.
It already is (at least partially)

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2143] X11 forwarding for ipv4 is broken when ipv6 is disabled on the loopback interface

2014-12-11 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2143

--- Comment #4 from Andrey Borzenkov  ---
(In reply to Darren Tucker from comment #3)
> Note that just ignoring the error will re-introduce
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1483

Patch ignores one specific error only - EADDRNOTAVAIL. bind returns it
when requested address is not present on host. If listening address is
present, bind fails with EADDRINUSE and current behavior is not
changed.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2311] simple attack when control channel muxing is used

2014-12-11 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2311

Tomas Mraz  changed:

   What|Removed |Added

 CC||t...@centrum.cz

--- Comment #5 from Tomas Mraz  ---
It should be documented in the ssh manual page that the socket must be
created in proper places.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2276] AuthorizedKeysCommand: add an option for alternate owner

2014-12-11 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2276

--- Comment #2 from Alon Bar-Lev  ---
(In reply to Damien Miller from comment #1)
> I think it would be reasonable to relax the permission check to
> allow the command to be owned by the user who started sshd as well
> as root. I don't think another option is warranted or necessary.

I thought that the original code was designed to block the user that
ssh into local to modify the command, I did not want to violate this
restriction.

Did I understand incorrectly why we limit ownership?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2275] sftp undocumented flags

2014-12-11 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2275

Damien Miller  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||d...@mindrot.org
 Resolution|--- |FIXED

--- Comment #1 from Damien Miller  ---
not sure when this was committed, but it's fixed in -current.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2276] AuthorizedKeysCommand: add an option for alternate owner

2014-12-11 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2276

Damien Miller  changed:

   What|Removed |Added

 CC||d...@mindrot.org

--- Comment #1 from Damien Miller  ---
I think it would be reasonable to relax the permission check to allow
the command to be owned by the user who started sshd as well as root. I
don't think another option is warranted or necessary.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2266] Bugs intended to be fixed in 6.8

2014-12-11 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2266
Bug 2266 depends on bug 2274, which changed state.

Bug 2274 Summary: Build fixes for musl libc
https://bugzilla.mindrot.org/show_bug.cgi?id=2274

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are watching the reporter of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2274] Build fixes for musl libc

2014-12-11 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2274

Damien Miller  changed:

   What|Removed |Added

 CC||d...@mindrot.org
 Status|NEW |RESOLVED
 Blocks||2266
 Resolution|--- |FIXED

--- Comment #1 from Damien Miller  ---
Fixed - thanks. This will be in OpenSSH 6.8.

commit 48b68ce19ca42fa488960028048dec023f7899bb
Author: d...@openbsd.org 
Date:   Thu Dec 11 08:20:09 2014 +

upstream commit

explicitly include sys/param.h in files that use the
 howmany() macro; from portable

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2266] Bugs intended to be fixed in 6.8

2014-12-11 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2266

Damien Miller  changed:

   What|Removed |Added

 Depends on||2274

-- 
You are receiving this mail because:
You are watching the reporter of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs