

OpenSSH 7.0 released - fs111
http://www.openssh.com/txt/release-7.0

======
ams6110
_OpenSSH 6.8 and 6.9 incorrectly set TTYs to be world-writable. Local
attackers may be able to write arbitrary messages to logged-in users_

That seems like a pretty significant "oops" to have gone unnoticed for two
releases?

~~~
mnw21cam
It's not that big a deal. Try "man mesg", which works by fiddling with the
world-write bit on your TTY. All that an attacker can do write text to a
victim's terminal (and mess up said terminal using interesting escape codes).

~~~
schoen
I wonder if there are attacks where you can alter the state of an idle user's
terminal (based on what process you see that terminal has running) to trick
the user into taking an inappropriate action when the user returns to the
terminal. (There's certainly generic social engineering, but I'm wondering
more about counterfeiting a situation that could really exist so that even a
knowledgeable and skeptical user could be fooled.)

~~~
derefr
Basically, tab-napping[1] for TTYs.

[1] [http://www.azarask.in/blog/post/a-new-type-of-phishing-
attac...](http://www.azarask.in/blog/post/a-new-type-of-phishing-attack/)

------
nandhp
> Support for ssh-dss, ssh-dss-cert-* host and user keys is disabled by
> default at run-time

I guess I upgraded to an RSA key "just in time", though obviously far later
than I apparently should have.

~~~
cmrx64
Might as well upgrade to a ed25519 key while you're at it :) Smaller and
faster!

------
WizzleKake
_Several ciphers will be disabled by default [in the next release]: blowfish-
cbc, cast128-cbc, all arcfour variants and the rijndael-cbc aliases for AES._

I still use arcfour; it seems to be the fastest when using scp or rsync (rsync
-e 'ssh -c arcfour') for copying large files. I hope the OpenSSH package
manager for my distribution keeps arcfour enabled for this reason.

~~~
cesarb
RC4 (arcfour) should not be used, because it's broken. It has biases in its
output (which is XOR-ed with the plaintext), which given enough cyphertext
allows one to recover the plaintext (see
[http://www.rc4nomore.com/](http://www.rc4nomore.com/) for the most recent
result).

OpenSSH since the 6.5 release
([http://www.openssh.com/txt/release-6.5](http://www.openssh.com/txt/release-6.5))
has a better alternative, ChaCha20. It's even faster than RC4, and has no
known weaknesses AFAIK. Some more information:
[https://security.stackexchange.com/questions/46812/what-
does...](https://security.stackexchange.com/questions/46812/what-does-
chacha20-poly1305openssh-com-mean-for-me)

~~~
Scaevolus
ChaCha20 is slower than RC4 in my testing (176MB/s vs 213MB/s). Since I have
AESNI and PCMLMUL, aes128-gcm is the fastest-- 430MB/s.

    
    
        $ for c in $(ssh -Q cipher); do echo $c; dd if=/dev/zero bs=1M count=8K | ssh -o Compression=no -c $c localhost dd of=/dev/null 2>/dev/null; done

------
mike-cardwell
This doesn't seem like a particularly interesting release. A few fixes. A few
defaults changed. Am I missing something?

~~~
s_dev
I understand that no piece of software is ever finished but I think OpenSSH
serves its purpose very well and isn't the kind of software that is worth
adding experimental features that would change its scope/purpose and therefore
releases tend towards bug fixes and security patches and in this sense makes
it kind of "finished" as much as I hate saying it like that. An important
aspect of unix philosophy is one tool does one job very well.

~~~
mike-cardwell
I agree. I'm just trying to figure out what prompted this to be posted here? I
assumed there would be something particularly interesting about this release,
but I can't see it...

~~~
s_dev
I suppose such a large number of people here would be absolutely dependant on
OpenSSH so any kind change or update is news to them. As well the 7.0 version
number makes for a lovely even number and catching headline.

~~~
joshbaptiste
Yep, major version number changes usually bring about excitement to view
what's new...

------
thebeardisred
Excited for this. Now we just need an RSA implementation for OpenSSH which
doesn't require OpenSSL for the RSA.

~~~
yellowapple
I'd imagine that OpenSSH is likely designed around using libressl for that,
no?

------
nailer
Looks like
[http://blogs.msdn.com/b/powershell/archive/2015/06/03/lookin...](http://blogs.msdn.com/b/powershell/archive/2015/06/03/looking-
forward-microsoft-support-for-secure-shell-ssh.aspx) didn't make it into this
release.

------
jamiesonbecker
Excellent release. OpenSSH + Userify = authtopia

Summary

\+ New default: PermitRootLogin prohibit-password, which also prohibits all
interactive login forms.

\+ DSS keys are finally disabled by default

\+ Use _at least_ 2048 bits for your RSA keys

\+ Deprecating or disabling MD5, SHA1, Blowfish CBC, ARC4, and a few other
older ciphers/hmac's.

\+ Bug and vuln fixes

~~~
xorcist
> Userify

Which turns out to be a Cloud solution that promises "root privileges with
just one mouse click" across all my servers. What could possibly go wrong?

~~~
jamiesonbecker
Touché, snark notwithstanding ;)

It's an unfortunate fact of life that most large enterprises require the
ability to quickly grant and revoke permissions across the enterprise. Some
enterprises literally have no formal user deprovisioning process (even manual)
across Linux/UNIX servers. Given that the only real alternative out there
right now is LDAP, we think Userify is a pretty cool fix.

However, any powerful authorization framework can be dangerous, and the more
power, the more danger. It's definitely a fair point.

~~~
xorcist
That's not entirely truthful. The "only real alternative to LDAP" is not
letting a third party manage your credentials. If you don't want a directory
service, pretty much every administration tool fits the bill. Red Hat has a
tool, Ubuntu has one, but it's the cloud age so you're probably using Ansible
or Puppet anyway where you get the same functionality for free. At least check
it in git.

~~~
jamiesonbecker
Well, obviously it's better to not trust anyone, ever. (I have trust issues
too:)) You are trusting a third party as soon as you launch stuff in a public
cloud or with your OS. For example, entropy.ubuntu.com, your distribution's
update mechanism, Android/IOS app store, even Gentoo's github repos.

We designed this as safely as we could: Userify doesn't need (or want) secret
credentials, only public keys. We encrypt with NaCl before data hits Redis. We
only communicate with TLS. The Userify shim does need root permissions because
it's managing user accounts.

Userify is available for on-premise deployment (currently Enterprise, and,
soon, Pro in your AWS VPC), and Cloud is available for people who want free.
Soon, we're launching "Pro", which is an in-between product for people who
want in-VPC without paying enterprise pricing.

(I assume you're talking about RH IPA, which is some nifty wrappers around
LDAP. As someone who spent a lot of time implementing LDAP on UNIX at big
companies, LDAP and centralized auth in general carries a lot of risks: for
example, what happens if just a single one of your boxes is compromised, and
rather than just sniff passwords, it starts DoS'ing your LDAP server? oops.
now you can't get into any of your servers, even the ones they haven't yet
owned.)

We focus on a lot more than just authentication. That's just the beginning of
the story.

Userify Enterprise provides layered role-based access control, a user-friendly
front-end for key updates, project functionality, and the ability to remove
users across a single project or the entire companies. Ansible or Puppet don't
offer any of those things. We have built-in deployment for Chef, for instance.
We try hard not to duplicate functionality that you can get elsewhere (for
example, systems management, log monitoring.)

Those are designed for systems management, and they're good at that. We're
designed for complex, multi-tiered user management with a focus on the user,
not the system. (Hence our name) We view these as orthogonal directions, and
it makes sense to use Userify with a good devops/cf system like
Ansible/Chef/Puppet/Salt/etc.

Small shops can still manually manage a dozen or so users across a few groups
of servers. We've got a bunch of companies with hundreds of servers and less
than 10 devops across all of them.

For companies like that, Userify gives a bunch of other benefits.. for
example, you can rotate your SSH keys without requesting a production code
deployment, or update an SSH key without write access to git, or remove a
contractor's account on their last day, etc.

On-boarding and off-boarding get a lot easier, rotating keys is easier,
training users is easier, managing lots of different role sets is easier, and
Userify doesn't require any changes to PAM or NSS modules -- installing is a
one-liner and it just uses /usr/sbin/adduser and /etc/sudoers.d.

The shim is just a few hundred lines.. read through it at
[https://github.com/userify/shim](https://github.com/userify/shim)

------
sshuser2
I bet Linux distros will have this in a day or two, while most BSDs will have
to wait months or years to get OpenSSH 7.0.

