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).
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.)
There was (and might still be) an escape sequence that allowed setting the xterm title, and another sequence that caused that title to be sent to the terminal AS INPUT!
I'd imagine this latter control sequence was eliminated.
* Support for the 1024-bit diffie-hellman-group1-sha1 key exchange
is disabled by default at run-time. It may be re-enabled using
the instructions at http://www.openssh.com/legacy.html
* Support for ssh-dss, ssh-dss-cert-* host and user keys is disabled
by default at run-time. These may be re-enabled using the
instructions at http://www.openssh.com/legacy.html
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.
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...
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.
* sshd(8): fix circumvention of MaxAuthTries using keyboard-
interactive authentication. By specifying a long, repeating
keyboard-interactive "devices" string, an attacker could request
the same authentication method be tried thousands of times in
a single pass. The LoginGraceTime timeout in sshd(8) and any
authentication failure delays implemented by the authentication
mechanism itself were still applied. Found by Kingcope.
Someone using OTP like google auth would likely be affected on linux, but it is not default and you can hardly bruteforce it either. On top of that fail2ban should deal with such bruteforce attempts just fine.
What I would like is an open source/self hosted solution where if I login as root to a system I would get a pop-up or message asking to verify this. Obviously for the individual sys admins it may not be useful - but for a company it makes sense. Personally I just want it as a sanity security check.
I could probably easily write it - just haven't had a chance to do it.
FWIW, don't login as root or su to root. Force yourself to always have to type in sudo. That half second is a good sanity check on whatever you're about to do. Plus, figuring out how to do crazy pipe things or here-docs as root is part of the fun :)
Kind of hard when VPS hosters configure their systems with root access. I'm not really sure I want to start mucking with the way they have it configured too much. When I self-hosted VMs I did configure them with root disabled.
I'm experienced enough to the point where if I was going to do something stupid - typing in sudo won't stop me from doing it (I'm not saying I'm an expert - I'm saying that sudo has become muscle memory so it doesn't register in my mind).
The added benefit to the message is a notification in the event that the system is compromised.
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.
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.
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.
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.
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/ for the most recent result).
43 comments
[ 3.1 ms ] story [ 109 ms ] threadThat seems like a pretty significant "oops" to have gone unnoticed for two releases?
I remember exploiting this issue more than a decade ago: http://seclists.org/bugtraq/1999/Sep/432
[1] http://www.azarask.in/blog/post/a-new-type-of-phishing-attac...
There was (and might still be) an escape sequence that allowed setting the xterm title, and another sequence that caused that title to be sent to the terminal AS INPUT!
I'd imagine this latter control sequence was eliminated.
* Support for ssh-dss, ssh-dss-cert-* host and user keys is disabled by default at run-time. These may be re-enabled using the instructions at http://www.openssh.com/legacy.html
I guess I upgraded to an RSA key "just in time", though obviously far later than I apparently should have.
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
It says they only plan on "refusing all RSA keys smaller than 1024 bits" (e.g. 768 bits.
> Deprecating or disabling SHA1
SSH1, not SHA1!
yeah, I added that .. 2048 is really minimum best practice these days ;)
SSH1, not SHA1!
Good point, edited - btw next paragraph also says disabling 1024 bit diffie-hellman-group1-sha1 key exchange.
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?
I could probably easily write it - just haven't had a chance to do it.
I'm experienced enough to the point where if I was going to do something stupid - typing in sudo won't stop me from doing it (I'm not saying I'm an expert - I'm saying that sudo has become muscle memory so it doesn't register in my mind).
The added benefit to the message is a notification in the event that the system is compromised.
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.
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
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.
OpenSSH since the 6.5 release (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...