Is there an explanation of why the roaming feature was removed from the server? It sounds like a useful feature to me and I run into this all the time.
OpenSSH: client bug CVE-2016-0777
201–210 of 226 posts
Re: OpenSSH: client bug CVE-2016-0777
#202Earlier quoted context omitted.
You could use something like ansible for the management of keys. Or you could centralize your authentication, which would probably be a lot more sane.
Even with central management, I don't know that I want to have 2500 keys floating around even if I have a management stack in place. That seems like an attack vector all in its own. Changing a key every other day on a 90 day rotation with 50 boxes. And fifty boxes isn't even that much. That's like 2 racks. Even with config management this won't scale past about 2 or 3 people and 10-20 boxes. Central auth is an option…
It's not that bad, it's part of the user data and should be provisioned the same way.
OpenSSH can also be used in a PKI fashion, where you use certificates instead of known_hosts and authorized_keys records. It's quite all right, but it comes with the same problems a full PKI does as you need to keep track of when the certificates expire. You also need a way to distribute CRLs so you still need configuration management.
Re: OpenSSH: client bug CVE-2016-0777
#203Earlier quoted context omitted.
What if my infrastructure is over 50 hosts? How am I going to distribute key files for 50 people with 50 keys every 14 days?
You automate it. At 50 hosts some automation like puppet or ansible, etc is worth the trouble, especially if it helps you make sure that all hosts have the correct keys on them - that's just basic security - make sure there are no keys that shouldn't be there. What do you do now if someone leaves? Remove that person's key from all 50 hosts one at a time? Or, at the very least, you use tmux with sync panes or csshx -…
Well I have an automated credentials and authentication infrastructure in place. The point is that if I have 50 hosts (and my infrastructure has considerably more) and 3 employees with 50 keys each, there will be 2 key changes a day on a 90 day rotation.
Are my guys going to spend 5 minutes every morning making and pushing keys?
What if my hosts auto provision themselves and there are 5 new hosts every morning?
Am I going to make keys as part of infrastructure deployments and push them back to the workstations and update other peoples ssh configs?
I'm just saying if you've worked at scale, you'll realize that a key per box won't scale. I mean, anything can scale if you put enough effort into it. But the chances of disaster in lack of access or security breach, from over complication is way to high here.
Automating bad processes just makes it easier for them to fuck you.
Re: OpenSSH: client bug CVE-2016-0777
#204Earlier quoted context omitted.
Indeed. The page gives bad advise. If your config has `Host` blocks, like often in people's personal configs, or if you have a `Match` block, the new directive only applies to the last of those blocks in the config file.
Which is why they're appending a newline and Host *?
Note that the example was changed as a result of my initial comment.
Re: OpenSSH: client bug CVE-2016-0777
#205Earlier quoted context omitted.
Even with central management, I don't know that I want to have 2500 keys floating around even if I have a management stack in place. That seems like an attack vector all in its own. Changing a key every other day on a 90 day rotation with 50 boxes. And fifty boxes isn't even that much. That's like 2 racks. Even with config management this won't scale past about 2 or 3 people and 10-20 boxes. Central auth is an option…
It's not that bad, it's part of the user data and should be provisioned the same way. OpenSSH can also be used in a PKI fashion, where you use certificates instead of known_hosts and authorized_keys records. It's quite all right, but it comes with the same problems a full PKI does as you need to keep track of when the certificates expire. You also need a way to distribute CRLs so you still need configuration manageme…
The suggestion was not PKI though. I'd be happy with that. I already have a PKI in place. The suggestion was for a 1 key per box.
Re: OpenSSH: client bug CVE-2016-0777
#206If you have a mac (Yosemite), it looks like you want to add " UseRoaming no" under the "Host *" line in /etc/ssh_config (as root). You can test it before and after with this: ssh -v -T git@github.com 2>&1 | grep Roaming debug1: Roaming not allowed by server ssh -v -T git@github.com 2>&1 | grep Roaming (no output is good)
Here is a user-friendly script that will disable UseRoaming on your os x computer. If you want to send this out to your coworkers, remind them that they have to right-click and choose open to execute a .command script (unless they have "allow apps downloaded from anywhere" enabled)
Re: OpenSSH: client bug CVE-2016-0777
#207We went to other way and kissed SSH goodbye a long time ago in favor of immutable infrastructure and automation: https://boxfuse.com/blog/no-ssh
you've never had to debug anything in production, have you?
It's not 2006 anymore. For the vast majority of the cases there is no need for SSH when it comes to logging, profiling and debugging.
Re: OpenSSH: client bug CVE-2016-0777
#208theo must be mad. Shaming people for leaving useless non essential feature in their code that results in security breach. And now the jewel of his crown has been compromised. The funniest part is now that his jewel has been tarnished, maybe people will understand what he was saying. And maybe too, people that believed privacy can be achieved on the internet will finally look at the problem of believing the 2 general…
We detached this subthread from https://news.ycombinator.com/item?id=10901618 and marked it off-topic.
Re: OpenSSH: client bug CVE-2016-0777
#209As far as I know, this will affect any OSX, am I right ?
It will affect any OSX that is new enough to have that code in it. Same is true with other OS. For instance, on an older, patched FreeBSD 7.2 system, we see this result: /root/.ssh/config: line 1: Bad configuration option: UseRoaming /root/.ssh/config: terminating, 1 bad configuration option ... which means that sshd predates the roaming code. I haven't tested, but I'll bet my snow leopard workstation also predates t…
Ok, an update - snow leopard is indeed too old for this to be relevant. SL with the last and latest software updates still doesn't have the roaming code in sshd and therefore you don't need to fix anything (at least wrt roaming...)
Re: OpenSSH: client bug CVE-2016-0777
#210Could we say it partially because of mono-culture?
Almost no one uses GNU lsh as a client/server, dropbear is mostly used as a embedded system sshd.
OpenSSH has to many thing integrated and enabled by default.