[Bug 2680] Regression in server-sig-algs offer in 7.4p1 (Deprecation of SHA1 is not being enforced)

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2680

--- Comment #8 from Damien Miller  ---
Though there at least one error in the contents of server-sig-algs: we
shouldn't offer ssh-dss when we're unwilling to offer a ssh-dss hostkey
(true by default).

I'll look at filtering the contents for that.

-- 
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 2680] Regression in server-sig-algs offer in 7.4p1 (Deprecation of SHA1 is not being enforced)

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2680

--- Comment #7 from Damien Miller  ---
(In reply to Jakub Jelen from comment #6)
> Although the patch looks reasonable and I considered it as a
> resolved issue, it is not as the current master (openssh 7.5) still
> reports:
> 
> debug1: kex_input_ext_info:
> server-sig-algs= dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,null>

That's AFAIK what it's supposed to be, excepting the "null" at the end
of the list - where does that come from?

> The correct list:
> 
> debug1: kex_input_ext_info:
> server-sig-algs=

Doesn't list non-RSA signature algorithms. Per
https://tools.ietf.org/html/draft-ietf-curdle-ssh-ext-info-10 :

> This extension is sent by the server, and contains a list of public
> key algorithms that the server is able to process as part of a
> "publickey" authentication request.

That doesn't limit the contents to just new signature algorithms.

We don't currently provide a knob to disable SHA1 signtures, but feel
free to file another bug to request it and I'll try to get it done
before 7.6.

-- 
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 2735] Wrong address family handling for tun devices

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2735

Darren Tucker  changed:

   What|Removed |Added

   Attachment #3016|ok?(dtuc...@zip.com.au) |ok+
  Flags||

-- 
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 2735] Wrong address family handling for tun devices

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2735

Damien Miller  changed:

   What|Removed |Added

   Attachment #3005|0   |1
is obsolete||
   Attachment #3006|0   |1
is obsolete||
   Attachment #3011|0   |1
is obsolete||
   Assignee|unassigned-b...@mindrot.org |d...@mindrot.org
 Status|NEW |ASSIGNED
   Attachment #3016||ok?(dtuc...@zip.com.au)
  Flags||

--- Comment #4 from Damien Miller  ---
Created attachment 3016
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3016=edit
revised again

re-revised; this one should makes the endian swizzling less confusing
and more correct

-- 
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 2647] Tracking bug for OpenSSH 7.5 release

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2647
Bug 2647 depends on bug 2680, which changed state.

Bug 2680 Summary: Regression in server-sig-algs offer in 7.4p1 (Deprecation of 
SHA1 is not being enforced)
https://bugzilla.mindrot.org/show_bug.cgi?id=2680

   What|Removed |Added

 Status|RESOLVED|REOPENED
 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 2680] Regression in server-sig-algs offer in 7.4p1 (Deprecation of SHA1 is not being enforced)

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2680

Jakub Jelen  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelen  ---
Although the patch looks reasonable and I considered it as a resolved
issue, it is not as the current master (openssh 7.5) still reports:

debug1: kex_input_ext_info:
server-sig-algs=

The problem is in the order of the checks in the condition
"!include_sigonly && kt->sigonly". With the following patch I can see
the correct list offered by the server again:

diff --git a/sshkey.c b/sshkey.c
--- a/sshkey.c
+++ b/sshkey.c
@@ -203,7 +203,7 @@ sshkey_alg_list(int certs_only, int plain_only, int
include_sigonly, char sep)
for (kt = keytypes; kt->type != -1; kt++) {
if (kt->name == NULL)
continue;
-   if (!include_sigonly && kt->sigonly)
+   if (include_sigonly && !kt->sigonly)
continue;
if ((certs_only && !kt->cert) || (plain_only &&
kt->cert))
continue;

The correct list:

debug1: kex_input_ext_info: server-sig-algs=

-- 
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 2745] New: [PATCH] add support for VersionAddendum to the client

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2745

Bug ID: 2745
   Summary: [PATCH] add support for VersionAddendum to the client
   Product: Portable OpenSSH
   Version: 7.5p1
  Hardware: All
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P5
 Component: ssh
  Assignee: unassigned-b...@mindrot.org
  Reporter: epaul...@unit1127.com

Created attachment 3015
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3015=edit
patch to support versionaddendum in client

A few years back, there was discussion on the mailing list about adding
SNI support to SSH by fiddling with the version banner exchange at the
very beginning of the protocol exchange, before the encrypted channel
is created. Daniel Gillmor at the time suggested that if this was to be
done, using the VersionAddendum mechanism might be a good way to do it:

https://lists.mindrot.org/pipermail/openssh-unix-dev/2013-November/031811.html

This patch does that. 

For example, a user might want to do
ssh -oVersionAddendum=X-Host:realhost.site.com sharedIpAddr.site.com

With the patch, someone who wanted to put in place a quick proxy
running on port 22 of sharedIpAddr.site.com that looked for a string
like
X-Host:realhost.site.com 
could then proxy the connection to realhost.site.com. 

The patch supports '%h' per Daniel's suggestion, so you can do:
ssh -oVersionAddendum=Host:%h server.example.net

or just put VersionAddendum in your configuration file. 

The caveats that Daniel warned are still true - this may not be
something an admin wants to turn on by default so you're not leaking
the actual host you're connecting to over the unencrypted banner
exchange (though if you have a shared secret with the proxy you could
encrypt the host string). Also, because the banner strings are used as
part of the key exchange if the proxy sends something different than
the actual end host sends key exchange will fail. 

I largely copied the code from how the server side handles
VersionAddendum. The big change is that I passed around the 'host'
variable in ssh_connect.c so the %h expansion would work when the
banner string is actually constructed - if there's a global I could
read from I wouldn't need to change the calls up the stack. Other
expansions don't work, like %u or %p, because the data for those are
not passed along right now.

I didn't add anything to ssh_api.c - it doesn't look like that file
uses the config settings so I don't think VersionAddendum would get
picked up there, but maybe I'm not reading it right. 

Subscriptions to the mailing list are not working right now so I
haven't posed this to the list, but hopefully after the server
migration stuff is worked out I'll be able to subscribe and send this
there.

If it's easier for folks to read or use, this patch is in the
client_version_addendum branch here:
https://github.com/epaulson/openssh-portable/commit/69daef3b8a99d6c85f357f200c4aaa06fe28eaff

Thanks!

-- 
You are receiving this mail because:
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 2742] Improve -R option, allow to purge all similar keys

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2742

Jakub Jelen  changed:

   What|Removed |Added

 CC||jje...@redhat.com

--- Comment #1 from Jakub Jelen  ---
> also prints a commandline to purge old key from known_hosts when the change 
> is correct.

OpenSSH does not print that line. It is a Debian addition [1].

I don't think ssh-keygen should resolve the hostname to IP address and
remove also that lines.


[1]
https://anonscm.debian.org/cgit/pkg-ssh/openssh.git/tree/debian/patches/mention-ssh-keygen-on-keychange.patch

-- 
You are receiving this mail because:
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 2742] Improve -R option, allow to purge all similar keys

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2742

--- Comment #2 from Dirk Stöcker  ---
> OpenSSH does not print that line. It is a Debian addition [1].

Seems openSUSE copied this patch. Maybe it should find its way into the
official tool ;-)

> I don't think ssh-keygen should resolve the hostname to IP address and remove 
> also that lines.

That's NOT what I proposed. This would not work always anyway (dynamic
IPs again or otherwise changed IPs or switch from a dual stack network
to a IPV4 or ...).

What I propose is to offer to delete all keys with "the same key data".
As the host key changed any entry with the same key data very likely is
obsolete as well. There may be cases when this is not true (e.g.
different hosts using the same key), so it should be optional.

-- 
You are receiving this mail because:
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 2743] ssh with -T hangs putty

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2743

Darren Tucker  changed:

   What|Removed |Added

 CC||dtuc...@zip.com.au

--- Comment #1 from Darren Tucker  ---
I can reproduce this but I think PuTTY is at fault.  Or at least
there's a mismatch between what you expect and what PuTTY does.

I built sshd with -DPACKET_DEBUG I can see the keystroke arrive at the
server:

debug1: input: packet len 32
debug1: partial packet: block 16, need 16, maclen 20, authlen 0, aadlen
0
read_poll enc/full: buffer 0x80ff8ec0 len = 36
: 9d 58 ac 75 69 f6 e3 01 c9 4a 10 f7 97 44 3c 69  .X.uiJ...Dhttps://lists.mindrot.org/mailman/listinfo/openssh-bugs

[Bug 2736] Question-"PermitTTY no" is not working as expected

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2736

Darren Tucker  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

-- 
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 2743] ssh with -T hangs putty

[bugzilla-daemon]

https://bugzilla.mindrot.org/show_bug.cgi?id=2743

--- Comment #2 from balu  ---
Thanks for the quick reply.

In the putty logs, it doesn't show the incoming packet so not sure if
the server is sending back the character to putty.

FYI, I tried the win32-openssh client, it works with the windows ssh
server (with -T option) but didn't work with the UNIX ssh server. So I
am guessing the per-keystroke echo is working fine and something else
is the issue.

-- 
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