Did Apple Just Give Up? - <AUTHOR> https://medium.com/@se4nn/wtf-happened-at-apple-4a27e55c3c31#.lu2mromba <comment><USER2> >This is what I think is happening at Apple. Now some of you may disagree, because you're still Apple fanboys

Because if you disagree with me, it can only be because you're blinded by your loyalty, not because your experience is different from mine.

Beyond that, I have a genuine question: why are users so stupid? If it's so obvious to this person that Apple's UI is a series of design failures, why do users continue to buy them, year after year? Both as brand new devices and as replacements for broken ones, otherwise rational individuals continue to purchase substandardly designed products.

<comment><USER3> blind devotion to a product long-past its prime. that's my explanation why users are stupid.

Why did people watch Happy Days long after it started to suck? Fonzie Jumping the Shark was two seasons into the pain. But it didn't lose ratings until that episode.

What's popular is not always good. and what's good is not always popular.

<comment><USER2> "People enjoy things that I find substandard so they must be of lower intelligence."

I'll answer my own question: Users aren't stupid, they just have priorities that differ than those of technology bloggers.

Dismissing your users is an excellent way to ship a frustrating product. Apple has done the opposite, but the use-cases between the masses and the tech elite have drifted far enough that those who don't work on Apple's UX team can drive clicks using smug elitism -- the yin to the 'Apple Fanboy' yang.

<comment><USER3> so, instead of acknowledging my response in any way, you create a strawman, then answer your own question you made up?

why not just edit the grandparent post, rather than waste time with a response?

Try again: are you really mystified by mob mentality?

<comment><USER2> The question was more rhetorical, an extension of the implication raised in the article that I wholeheartedly disagree with. Assuming that users are 'stupid' en masse sidesteps questions of usability instead of analyzing what is users actual prefer in their UX.

"Mob mentality" is that assumption. Customers are more than capable of returning their devices to the carrier if they really dislike their devices. They can also sell them, and many do.

But many more do not. Apple's OS is not broken, this blogger just hasn't taken the time to research why people prefer something he doesn't.

<comment><USER3> that's a lot of words to say "yes, in fact, I _am_ mystified by the dynamics of mobs".

</comment></comment></comment></comment></comment></comment><comment><USER4> If Gruber wrote this, it might actually get traction at Apple.

IMO the peak for a company is when they build a grandiose edifice, e.g. the Apple spaceship campus. It's downhill from there.

</comment><comment><USER5> It's gotten so bad that I actually suspect competitors have planted sabetours in the company ranks.

</comment><comment><USER6> Yet another pointless example of how FUD dominates tech articles. Are there any verifiable data to back up their claims, like actual sales numbers dropping or even a single losing quarter? Any new competitors that may disrupt the market? Does the article make a testable prediction? Are they willing to bet anything tangible to back that up?

If the answer to most/all of these questions is "no" you may be dealing with another example of time-wasting BS.

</comment><comment><USER7> Whoever decided the new Apple TV would not support bluetooth keyboards should be fired.</comment>


Torrent User Attacks Mod for Copyright Theft on Torrent News Section - <AUTHOR> http://extratorrent.com/article/2619/instagram+against+twitter.html

<comment><AUTHOR> Yet another stolen article you are trying to take credit for....</comment>


Where the Good Jobs Are - <AUTHOR> https://www.nytimes.com/2019/05/02/business/economy/good-jobs-no-college-degrees.html <comment><USER2> >> The median wage for workers with some college education but no four-year degree is $835 per week, about 10 percent less than it was at the turn of the century, after inflation

This is a crazy sentence if you think about it. For a significant part of society wages did not only stagnate, they dropped. I don't think the trend will reverse any time soon. If the wages of another profecion rose 10 percent and were equal before, we would see a 22 percent difference (which is a lot!).

Since this is the trend for all workers with some college education but without a four year degree, i think it's a dire situation for those people. There's no easy way out (the article suggesst moving!).

The suggestion in the article may be smart on an individual level, but it could lead to a further segregation between sucessfull and not sucessfull regions.

<comment><USER3> It would be interesting to calculate how much better wages are given country of origin. What I mean is, there are currently about 28 million immigrants living in the U.S. with about 1.2 million arriving every year (both documented and undocumented.)

According to statistics, 30% of new immigrants have no high school diploma, so while the average wage is low, it's probably much higher than they would be getting in their native country (otherwise, presumably, many woudn't have left in the first place.)

This may be putting pressure on wage growth for native-born Americans but overall growth as a whole may be stronger than it looks.

<comment><USER4> If anyone has data on this, I'd love to know.

But I'm willing to bet globalization (wages in China) have a much larger effect on wages for average US jobs than immigrants coming to the US do.

There's a lot more competition to do almost anything in China or India than there is from (potentially) lower paid immigrants in the US.

Sure, not everything can be outsourced. But for everything else...

</comment></comment></comment><comment><USER5> I've hired people with both some college and an actual degree. I honestly haven't seen a big difference in ability. In fact, the ones with only some college (especially those with a family) seem to be more reliable and willing to do the occasional boring things that those with a degree tend try to avoid doing.

That's probably my own experience and it involves a low sample size, but as a small business owner, Id argue that you can really benefit by dropping the degree barrier and looking for other indicators of maturity and reliability.

<comment><USER6> Somewhat different experience: I was a hiring manager at a large tech company where we needed mostly hardware engineers. Company was very big on credentials, so we always recruited from top unis. We had just a handful of "partial-degreed" engineers who had often worked their way up from electronic technician positions while attending college part time. Turns out we needed both types. The top credentialed engineers did lovely designs but never got any of their hardware to actually work. The "mechanics" always had to come in to fix things.

Added: It really was quite like this Dilbert comic [https://dilbert.com/strip/2019-01-21](https://dilbert.com/strip/2019-01-21)

<comment><USER7> Why exactly did you need those credentialed designers that churned out non- working "lovely" designs?

<comment><USER8> Not OP, but sometimes 'lovely' designs also nearly work and all that is needed to bridge the final gap is knowledge earned through practical experience.

<comment><USER9> This happens in construction too. Architect/engineer sign off on a design, the "no education" guy swinging the hammer has to make adjustments in the field to get it to actually work.

<comment><USER6> I worked for my dad a couple summers when I was a teenager. He was a contractor doing wood frame construction in southern California. I never heard him swear so much as when the plans called for something that was next to impossible to build.

Later on I did some framing work on my own. Ran into several cases where the designer completely ignored the dimensional instability of wood due to changes in humidity. Often that was really hard for the "no education" guys to fix.

</comment></comment></comment></comment></comment></comment><comment><USER10> Putting "Registered Nurses" at the top of the list of occupations that are available without a bachelor's degree seems kind of misleading.

Yes, it is technically possible to become one without a bachelor's degree, but it does require a minimum of three-quarters of a bachelor's degree and it is becoming more and more common for new RNs to be required to go ahead and get a bachelor's.

<comment><USER11> Indeed, the criterion for requiring a degree is a regulatory one, involving licensing. But a degree may be a _practical_ requirement if you're competing with people who all have degrees. One reason for a nurse to stay in school for another year is to open up future jobs or education opportunities, e.g., grad school.

</comment></comment><comment><USER12> In the UK there was a drive by the Labour government to push everyone into higher education. Not to blame them for this but it has effectively made it worse for some people who took any degree and at the same time has made it hard to fill trades and apprenticeship schemes (at least in Scotland).

There is a kind of snobbery to working jobs which I think is wrong. My pal who is now a leccie (Electrician) can charge crazy money and is laughing all the way to the bank. Maybe I will quit my dev job and become his apprentice :)

<comment><USER13> >> My pal who is now a leccie (Electrician) can charge crazy money and is laughing all the way to the bank.

Can he scale his business to more than a single employee? Does he get many connections that allow him to move on - e.g. become a senior engineer at a nuclear facility? What happens to him when we move on to some other "smart" electricity scheme which outdates all of his practical skills?

<comment><USER14> Source: I live in the UK and have multiple friends in trade work.

Most can take on other workers or young apprentices quite easily. The two i know that have done it now only work their trade 2-3 days a week and spend most their time doing the admin / business side.

Not sure how piratical skills in electricity can become outdated? New legislation can be released around safety i guess...?

<comment><USER15> As long as there are pre-paid meters, pirate sparkies will be in demand

</comment></comment></comment></comment><comment><USER16> Weird how all of these think pieces pondering places and lifestyles available without a degrees only focus on healthcare and manufacturing.

I've met numerous people in my 10+ years of software development without a degree. I don't have one either.

As I heard from one candidate in an interview, "software development is one of very few career paths left to have a middle class lifestyle without a degree."

My biased opinion is that devs without a degree hustle a little more and are more willing to tackle brownfield projects and nasty refactoring/conversion efforts.

<comment><USER17> > As I heard from one candidate in an interview, "software development is one > of very few career paths left to have a middle class lifestyle without a > degree."

That's very true, and it's because technology is more of a meritocracy than most other professions. Your compiler doesn't care about your credentials, or who your family is, emotional pleas, or any of the other myriad factors that get people into jobs they're not capable of. The culture of meritocracy is pretty heavily under assault, but I'm confident it will survive for a while yet.

</comment></comment><comment><USER18> And by 'good jobs' they mean 'anything near a decent wage'... for dropouts. This is one of the most patronizing, anti-competitive articles I've seen in a long time. If you want evidence of coastal elitism, read this article as exhibit A.

As a dropout who learns faster on youtube than in a classroom, and making more than my state senator's entire family, let me give everyone reading this advice: Don't be scared away by elites protecting their jobs in large cities. Come in at 70% of the price, excellent work ethic, and give them a run for their money. Most Americans live in a country that values cost efficiency over credentials. We hold meritocracy above bureaucracy, and it should be celebrated not discouraged.

<comment><USER19> Hey now, dont knock it till you try it. the article talks about college drop- outs, not highschool flunkies, and i think theres a real point to be made here.

College isnt for everyone, but parents push super hard to get their kids there and I dont know why. I went to a 2 year trade school for diesel engine repair. It was affordable and I could pay my way through with a job at a local pizza chain. Try finding a 4 year college you can afford with that pay-grade.

living in a big city isnt for everyone. I did a stint in Brooklyn once, learning to service buses and garbage trucks. The pay is good but the pace is sometimes insane because thats the pace of the city you live in. Theres a lot of pressure to deliver it right the first time, and i dont regret learning that work ethic, but I didnt find home in that city.

What i can say for the trade i have is that its rewarding and sometimes pays close to cut-rate lawyer money. I dont worry about bills and ive got plenty of cash to hit the pub once a week to see the game. The world needs electricians, plumbers, and even mechanics to keep running. Check out the hourly base pay of most of these trades and try to imagine pulling a little overtime, which is usually part of the trade in salary jobs as well im told. HVAC is also a great trade with endless advancement and opportunity.

<comment><USER20> If you can't afford college but you have enough of a support system to get good grades and extracurriculars, there's a good chance you'll get into a good university with a generous financial aid program. If you get into a top university and your parents make combined <$100,000/yr, it's likely you won't have to pay any tuition at all.

</comment></comment></comment><comment><USER21> ==To figure out how many of these jobs are open to people without degrees, the economists scoured nearly 30 million local job ads across 121 metropolitan areas to determine their minimum educational requirements. They called them "opportunity jobs."==

I would be interested to know what percentage of these jobs are actually filled by people without degrees. It could be that these markets have less degree holders so they change the requirements to increase applications. What matters is who ultimately gets hired.

</comment><comment><USER22> Who cares if nursing or carpentry don't require college. They require specialized qualifications in nursing or carpentry, regardless of how we categorize the certificate or lack thereof.

I don't see how any of this relates to "opportunity," in the sense that they're going for in this article. These jobs aren't any more accessible than college-required jobs.

</comment><comment><USER23> Having worked in Cedar Rapids there's really only 1 employer that makes up the "good job" pool - used to be called Rockwell Collins.

I'd guess there's a similar situation in most of towns on this list, which would mean living there is a huge risk unless you plan on working at the one or two companies in town for life.

<comment><USER24> I feel like there is an implicit assumption in the article that people without a college degree won't want to switch jobs as often because they have less upward mobility as a whole.

</comment></comment><comment><USER25> The article ranks cities by their percent share of "good jobs" rather than total count.

If you calculate totals, the "superstar" cities do better, thanks to their larger overall populations.

For example: The lowest scoring city, Washington, has 452,600 good jobs. The highest scoring city, Toledo, has only 100,980 such jobs.

<comment><USER26> and by CoL you're gonna get screwed in one of these "good jobs" in superstar cities

<comment><USER25> The article's definition of "good job" is cost-of-living adjusted: """ It has to pay more than the national median wage, $37,690 in 2017, adjusted for the cost of living in the area. """

<comment><USER27> I question their CoL adjustments. The median US rent is ~$1k/month[1], whereas in SJ it's ~$2.7k[2]. That's ~$20k more per year, _twice_ what they adjusted for. ($37k → $47k, or $10k additional CoL expenses.) That's not accounting for any other CoL, such as higher gas prices and CA's higher state tax.

[1]: [https://www.deptofnumbers.com/rent/us](https://www.deptofnumbers.com/rent/us)

[2]: [https://www.rentcafe.com/average-rent-market- trends/us/ca/sa...](https://www.rentcafe.com/average-rent-market- trends/us/ca/santa-clara-county/san-jose/)

</comment></comment></comment></comment><comment><USER28> >> Mr. Wardrip, Mr. Fee and Ms. Nelson define a "good job" in simple terms: It has to pay more than the national median wage, $37,690 in 2017, adjusted for the cost of living in the area.

I'm not usually one to be pedantic, but it seems like there's many MANY "terrible jobs" that pay $37k or more. I assume they had to keep it simple for their definition, and much of what makes a job actually good is subjective, but I was hoping this would have a little more nuance. It seems obvious to say pay is only part of what makes a good job good.

<comment><USER29> To perform a statistical analysis, you want an objective measure, and money is a great proxy for value. You can pay people to be frustrated and stressed.

The interesting thing about this definition, to me, is the Lake Wobegon-esque effect that statistically half of all jobs are "good" because they're above the median. A poverty level or inflation-adjusted absolute metric might be more useful; you could measure the effect of policies based on the reduction of or increase in the number of good jobs.

</comment></comment><comment><USER30> Without really doing research myself. If there is 1 factory left in Youngstown, and it's hiring for 3 welders or something, and 1 accountant. And those are the only 4 jobs in Youngstown, then Youngstown's "share" of good shit jobs is pretty high and there is still absolutely no reason to move there. My bro makes a lot more than me in DC without a college degree (or skills) bc he's good at talking and handsome. I had to leave DC b/c I just am not good enough to get a good job there, and if you don't make a lot there, then you have to move. So I get that if you're a loser in capitalism move to a cheap city, but this share metric I think makes cheap cities look like good cities. The shares are likely high b/c there are NO educated jobs, and the cities are probably harder places to earn in (there are more nurse jobs in DC than Toledo, and my brother would not be able to do whatever the hell he does in Toledo, there is still more sense there than money).

<comment><USER18> I think the main drive of the article is "just don't even try to move here" which is very anti-competitive. Sounds to me like writers in NY have a hard profession, and do not want more people competing with them for lower wages.

</comment></comment><comment><USER31> TL;DR if you don't have a college degree (or have one that does not get you a foothold in a lucrative industry) stay out of all the cities that are a clusterf*ck of white collar professionals driving up prices on everything.

<comment><USER32> That holds up even if you do have a degree. You can save money on cost of living regardless of credentials.

<comment><USER33> Yeah but then you can also make use of the benefit your degree has created for you (and because of what you paid for it).

</comment></comment></comment><comment><USER34> A very good related article also out from the Times: [https://www.nytimes.com/interactive/2019/05/01/magazine/lord...](https://www.nytimes.com/interactive/2019/05/01/magazine/lordstown- general-motors-plant.html)

"The last Cruze remained inside the plant, awaiting a final inspection. By then, it had already come to be much more than a car. It was a token of the most coveted working-class possession: a secure, well-paying job with health insurance and a pension."

I mean, guys, it's not much folks are asking for here.

</comment><comment><USER35> As a white-collar professional and a software developer, what's something that we can do to lessen our effect on this phenomenon? I don't current live in a large city, but I've considered moving to one if I need to find work in the future. I've been lucky to work remote for most of my career, so living in a metro area with fewer tech jobs hasn't been an issue. However, if I were to move to one of the big tech cities, obviously I would be contributing to the pricing problems that already exist.

<comment><USER31> Stop paying too much for housing because the commute is 15min or the schools are good. Stop buying hipster beer and eating at those stereotypical gentrified restaurants that charge too much for everything. Buy your groceries somewhere other than Whole Paycheck.

Basically just live below your means.

But that is going to be hard for most people in tech to do because most people in tech were raised upper middle class and they simply don't know how to live below that and a lot of the rest are not from the US and they're mostly just going to do whatever makes them fit in.

And unless you can get everyone with money to live like they don't (which you can't) that's not actually going to solve anything. Telling everybody to just change their lifestyle is not a real solution to anything anyway.

<comment><USER36> The last thing one should do to solve housing inequality is to intentionally buy a lower priced home that could have formerly been afforded by a family with lesser means (thus forcing them to attempt to afford a higher priced property) in a sanctimonious attempt to avoid doing just that.

Ultimately, there is nothing an individual can do to help housing affordability. That is a societal problem.

If you really want to help housing equality, buy ana apartment building, not a house, and add more units

<comment><USER31> >The last thing one should do to solve housing inequality is to intentionally buy a lower priced home

And driving demand for luxury condos (or whatever) is better? Then you're giving an incentive for some developer to bulldoze the cheap "blighted" homes and apartments to make more luxury condos or overpriced new townhouses, or whatever.

There's no winning here.

<comment><USER36> > And driving demand for luxury condos (or whatever) is better? Then you're > giving an incentive for some developer to bulldoze the cheap "bliAnd driving > demand for luxury condos (or whatever) is better? Then you're giving an > incentive for some developer to bulldoze the cheap "blighted" homes and > apartments to make more luxury condos or overpriced new townhouses, or > whatever.

No you're not. If you buy a luxury condo, you have reduced demand for luxury condos, since there's one less individual who both wants and can afford a luxury condo. If they build enough luxury condos as people who can afford them, then eventually it's no longer profitable to build luxury condos, and they'll have to concentrate elsewhere. However, the false restriction of the market enabled by policies such as 'neighborhood preservation' and lack of funding for rapid public transit means that development companies can basically make their entire year's profit only meeting the demand of the rich.

(Also, every new development is going to be branded as a 'luxury condo'. No one sells a 'boring old condo', ever).

> There's no winning here.

Yup. If you define 'winning' as 'I don't want my purchase of something to affect the price of similar things', then certainly, you cannot win.

<comment><USER37> _Also, every new development is going to be branded as a 'luxury condo'. No one sells a 'boring old condo', ever_

This is true everywhere. Builders are not going to build cheap houses. My wife and I were looking for a house three years ago. At the time, it was only three of us - including my 15 year old step son. We were looking at buying in a county in the Atlanta burbs. We had two choices - old small houses being sold by the relatively few people who lived their or buy in one of the many neighborhoods where builders were building new houses. We purposefully chose the cheapest, smallest floor plan offered by the builder - and even that was over 3000 square feet, five bedroom. I'm not trying to humble brag. It was less than 330K all in and we only needed 5% down. Any software developer with 5-7 years of experience could easily afford it - especially a dual income couple.

</comment></comment></comment></comment></comment></comment><comment><USER38> This article title is ridiculous. These aren't the "good jobs" at all. These are the "best jobs available assuming you have no particular skills and no college degree".

<comment><USER39> What is your definition of a good job?

</comment></comment><comment><USER40> Anyone else notice the publish date for this piece is May 2. It's in the future. I wonder if this is a presentation bug or it was accidentally published early

<comment><AUTHOR> What is the date where you are?

<comment><USER40> That isn't going to matter is it. The date in some regions goes up to Friday May 1 but not on to Saturday May 2. At least not at the point in time I'm writing this.

The URL has 5/2 in it which appears to be a date.

<comment><USER41> I think you may just be mistaken about the date, friend... The last TZ hit may 2 several hours ago.

</comment></comment></comment></comment><comment><USER42> $835/week is $43000 a year, which is approximately what postdocs (people who hold PhD degrees) receive.

<comment><USER43> And soon we'll have nationwide $15/hour minimum wage (~$30K/year) for people who take your coffee order or put fries in a bag.

<comment><USER31> 45k/yr if you work 60hr/wk (which isn't all that bad if you're doing something that isn't stressful).</comment></comment></comment>


Show HN: My SSH server knows who you are - <AUTHOR> https://blog.filippo.io/ssh-whoami-filippo-io/ <comment><USER3> FYI, this happens because SSH automatically presents a public key to the server when trying to authenticate. If the server doesn't know that key, then SSH tries the next one. You can enumerate all of someone's keys this way (like this SSH server does)

If you want to disable this sort of behaviour you can disable SSH from sending keys automatically, and then tell SSH which identity files need to be sent to each host.

In your .ssh/config, something like:

        # Ignore SSH keys unless specified in Host subsection
        IdentitiesOnly yes

        # Send your public key to github only
        Host github.com
            IdentityFile ~/.ssh/id_rsa

This is also handy if you're security conscious and like to use a different private/public key pair for each host you have an account with!

<comment><AUTHOR> Exactly! Once I get the keys I just check them against a scraped database of GitHub keys and ask the API for your name.

(And if you have agent forwarding active I show you a big WARNING [0].)

There's an explanation in the README [1] but the actually interesting stuff is in server.go [2]. Finally I mentioned a few reasons it might not work for you below [3].

[0] [http://git.io/vOVYm](http://git.io/vOVYm)

[1] [https://github.com/FiloSottile/whosthere](https://github.com/FiloSottile/whosthere)

[2] [https://github.com/FiloSottile/whosthere/blob/master/src/ssh...](https://github.com/FiloSottile/whosthere/blob/master/src/ssherver/server.go)

[3] [https://news.ycombinator.com/item?id=10005169](https://news.ycombinator.com/item?id=10005169)

<comment><USER4> > (And if you have agent forwarding active I show you a big WARNING [0].)

It amazes me that people enable that for random servers. Seems like SSH should make that harder. Enabling it for a specific server you trust makes sense; enabling it for all servers doesn't. SSH could reject "ForwardAgent" outside a Host block, for instance, and force you to at least write a "Host *" block.

EDIT: Check out this search: [https://github.com/search?utf8=%E2%9C%93&q=ForwardAgent&type...](https://github.com/search?utf8=%E2%9C%93&q=ForwardAgent&type=Code&ref=searchresults)

<comment><USER5> For those who don't get why this is terrible, imagine if GitHub were compromised and their ssh agent tampered with. When you clone a repo, they could use your forwarded agent to log into your production hosts. That's pretty bad.

<comment><USER6> I don't fully understand how this would work - the key being "forwarded agent". My (poor) understanding is that in order for compromised github to get to a host I'm connected to they would somehow need to invoke ssh on my host, somehow. The only way that would not be the case is if ssh maintains an in- memory persistent _thing_ that a) maintains connections to foreign hosts, and b) can somehow be signaled from active connections. If that's true, then a) I didn't realize it could do that, and b) it would be quite handy sometimes, although the security implications are rather serious.

<comment><USER4> The SSH agent maintains your private keys and provides the necessary responses to ssh when it wants to authenticate to a server. If you ssh to a server and forward your SSH agent, that server can then run ssh themselves and impersonate you to a different remote server, and your SSH agent will supply the necessary authentication information.

Or, in short: never use ForwardAgent (or ssh -A) to a server you don't trust.

<comment><USER6> The remote ssh process asks your host to unencrypt it's traffic? Your process takes an encrypted stream, sends the plaintext, and your keys never leave your machine. That's...incredibly clever, although I can only think of one scenario where it would be necessary (navigating securely through a sequence of ssh sessions where some of the secondary hosts are inaccessible from your originating host. E.g. a kind of "secure trojan horse".

Sometimes I feel just so awed at the ingenuity of people, especially with software and computers.

<comment><USER7> its very useful for so called "Bastion Hosts", an SSH server that allows further access into the network and is totally locked down.

<comment><USER8> You don't need agent forwarding for that. Just use ssh's dumb tcp forwarding and keep your agent on your local host.

Ex.:

        Host bastion.company
        	ProxyCommand none

        Host *.company
        	ProxyCommand ssh -W %h:%p bastion.company

<comment><USER9> Because enabling tcp forwarding is so much more safe on a jump box? That's just asking for another pile of unauditable trouble.

<comment><USER8> Safer than dumping all your private keys onto the jump box and using that to validate the final target? Why yes. This way, your local ssh client validates the final target public key, not the jump box.

<comment><USER9> The whole point of agent forwarding is that you don't have to place your keys on the jump box. With -c for per use confirmation it seems much more secure.

<comment><USER8> > The whole point of agent forwarding is that you don't have to place your > keys on the jump box.

A socket that allows dumping the keys isn't really an improvement. If the box is compromised, agent forwarding can still be abused.

> seems much more secure.

Emphasis on "seems".

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Didn't work for me. Here's what I got.

I cleaned out .ssh/knownhosts after connecting.

        +</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>---+
        |                                                                     |
        |             _o/ Hello!                                              |
        |                                                                     |
        |                                                                     |
        |  Did you know that ssh sends all your public keys to any server     |
        |  it tries to authenticate to? You can see yours echoed below.       |
        |                                                                     |
        |  We tried to use that to find your GitHub username, but we          |
        |  couldn't :( maybe you don't even have GitHub ssh keys, do you?     |
        |                                                                     |
        |  By the way, did you know that GitHub publishes all users'          |
        |  ssh public keys and Ben (benjojo.co.uk) grabbed them all?          |
        |                                                                     |
        |  That's pretty handy at times :) But not this time :(               |
        |                                                                     |
        |                                                                     |
        |  P.S. This whole thingy is Open Source! (And written in Go!)        |
        |  https://github.com/FiloSottile/whosthere                           |
        |                                                                     |
        |  -- @FiloSottile (https://twitter.com/FiloSottile)                  |
        |                                                                     |
        +</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>---+

Connection to whoami.filippo.io closed.

Arams-MacBook-Pro:~ acomjean$ emacs .ssh/known_hosts

<comment><AUTHOR> Hi! A few reasons it might fail:

* You don't have your SSH keys on GitHub

* You don't have your GitHub keys on that laptop

* Your key is not RSA (because I'm LAZY)

* Your ssh version uses only recent algorithms not supported by Go's x/crypto/ssh

* You actually disabled IdentityKeys

Nothing to do with usernames or heuristics, by the way. All it does is first enumerate your client keys, then let you in, then check a huge GitHub keys database, then ask the GitHub API for your name.

[https://github.com/FiloSottile/whosthere#how-it- works](https://github.com/FiloSottile/whosthere#how-it-works)

<comment><USER11> \- The key might be to new for the dataset.

<comment><USER12> This was the case for me. The keys I'm using now I added this past weekend, and I get the "couldn't find you" message.

</comment></comment></comment></comment><comment><USER13> Didn't work for me, not because I don't have a Github key, but because I use separate keys for everything, and don't have a default key (requires plenty of ~/.ssh/config muckery).

I had been doing this because I'm paranoid, and because I have a tendency to copy keys for my colo boxes to work computers, and my Git keys to the colo boxes. Now I have a new reason -- public keys basically act like a giant supercookie for SSH.

<comment><USER14> Same here. Here's my ~/.ssh/config for anyone interested in what it looks like:

        Host github.com
          User toxicFork
          IdentityFile ~/.ssh/github-toxicFork
        Host bitbucket.org
          User toxicFork
          IdentityFile ~/.ssh/bitbucket-toxicFork

And my personal security policy:

\- Once I want to use a device for development, I create separate key pairs for all of the services I want to use, register it on that server's account config and then add it to my config file by hand ( I should find or write a script to do these automatically :D )

\- Once I want to retire a device (or if it gets lost) I just remove the public keys from the services

\- NEVER move or copy private keys, I'd rather create a new private key and remove the references for the old public keys instead

<comment><USER15> Good policies, the mere presence of an id_<ciphername> key in .ssh means you can be identified between multiple ssh servers. I identified this in the OpenSSH source a while ago and posted it on reddit at one point, but few people understood. Glad someone made a practical attack out of it now. IP correlation may seem a more obvious attack, but such an attack could be used to identify for example, someone running a darknet operation or using VPNs for privacy or simply to tie an IP to a name using a public key service like in this example.

</comment></comment></comment><comment><USER16> "don't worry, I don't have any OpenSSH 0day" > That's exactly what someone with a 0 day would say!

<comment><USER17> Someone with an OpenSSH client 0day would just quietly open an SSH port and wait about five minutes for the next sucker.

You don't have to phish on HN to get people to connect to an SSH port.

<comment><AUTHOR> But I wouldn't get access to all these "DevOps-style" startups backends... Oh. Oh, I shouldn't have said that.

;)

</comment></comment></comment><comment><USER18> Nice trick!

Also - everybody should probably be aware that SSH zero-day isn't the only bad thing which can happen to you if you connect to a malicious SSH server. Your terminal emulator has a higher chance of being vulnerable (e.g. take a look here: [https://www.proteansec.com/linux/blast-past-executing- code-t...](https://www.proteansec.com/linux/blast-past-executing-code- terminal-emulators-via-escape-sequences/)) than openssh does.

P.s. "(And written in Go!)" \- the trick would still be very cool if it was written in C, JavaScript, PHP, COBOL or any other language (and it would be freaking awesome if written in brainfuck!).

</comment><comment><USER15> I brought this attack up on reddit 3 years ago.

[http://www.reddit.com/r/crypto/comments/xf6pa/openssh_offers...](http://www.reddit.com/r/crypto/comments/xf6pa/openssh_offers_your_public_keys_to_all_servers/)

Glad to see someone implemented an attack and can demonstrate it well now.

Cheers Filippo.

<comment><USER19> "attack"

<comment><USER20> It's an attack on privacy expectations.

There are at least two ways to escalate from here:

\- One if agent forwarding is enabled. \- Another: learning details like people's names is often a first step in social engineering.

<comment><USER15> There's also another leak which isn't really shown here and that leak is that, with just a public key, you can offer to servers and they'll tell you if it's present or not.

Using this you could scan the internet (given 6-12 hours and a shitty VPS that you can throw away this is quite possible) for someone's public key to find all of their servers, which could lead to a bypass of DDoS protection, identification of a Tor hidden service, etc.

<comment><USER21> Yep, see also Rachelbythebay's comment in this thread (in particular the second post she links to); this is definitely exploitable. [https://news.ycombinator.com/item?id=10008012](https://news.ycombinator.com/item?id=10008012)

</comment></comment></comment></comment></comment><comment><USER22> It occurs to me that you could use this same mechanism to reduce the configuration load on machines that provision users using cloud-init(8).

Right now, cloud-init accepts a list of GitHub usernames that should be allowed to log into the machine (which is pretty clever in-and-of-itself), and then creates users for them and sets their authorized_keys to whatever values the GitHub public-SSH-key API returns.

But, rather than "burning in" a set of allowed users, you could do something much more interesting: allow any key to authenticate, and then map it back to a user and find out if that user has write-access to the GitHub project!

<comment><USER20> It will probably work. But it seems like you are increasing the attack surface here: the current method gets the list of keys once, and if github isn't compromised at that very instant in time, you are safe. Your proposed method relies on trust in github at all times.

</comment></comment><comment><USER23> Hey, cool, someone did part one with the GitHub public keys.

[http://rachelbythebay.com/w/2013/04/07/ssh/](http://rachelbythebay.com/w/2013/04/07/ssh/)

Now, someone, do part two.

[http://rachelbythebay.com/w/2013/07/20/ssh/](http://rachelbythebay.com/w/2013/07/20/ssh/)

<comment><USER24> Wow after both of those blog posts, TWO years ago, I'm surprised github hasn't stopped exposing this identity information and us HN users haven't started being more paranoid about our ssh_configs.

<comment><USER25> why would they? after all they are public keys, they are supposed to be public. if you really are afraid of github exposing your public key, I think you can always create a separate pair to use only with github.

<comment><USER20> And in some sense github is doing as a favour, by partially solving the key distribution problem.

If you send me your public key via email, I don't know whether you are who you claim you are. If I get your public key via github, at least I know that you are the person contributing to all those open source projects.

</comment></comment></comment></comment><comment><USER24> I see most people acting like this was obvious but I gotta believe that a clear majority of ssh users had no idea about this. Yet it's extremely obvious when you think about it.

This, this is true hacking. This is so elegant. I love you Filippo. Keep being awesome!

</comment><comment><USER26> Neat. I wonder how many "attackers" that scan ssh etc. could be identified by this.

<comment><USER27> There are probably some morons out there, but I'd be surprised if most automated ssh scanners were offering up a private/public keypair.

<comment><USER28> The best moron I ever saw had his full name as computer name and we gave him a phone call at his house - his mother answered first, it was awesome!

<comment><USER26> You don't happen to have recordings of it, by chance?

<comment><USER28> No, sadly. It was a long time ago.

</comment></comment></comment></comment></comment><comment><USER29> > Did you know that ssh sends all your public keys to any server it tries to > authenticate to? You can see yours echoed below.

> We tried to use that to find your GitHub username, but we couldn't :( maybe > you don't even have GitHub ssh keys, do you?

> By the way, did you know that GitHub publishes all users' ssh public keys > and Ben (benjojo.co.uk) grabbed them all?

> That's pretty handy at times :) But not this time :(

Better luck next time, I guess :)

<comment><USER30> > By the way, did you know that GitHub publishes all users' ssh public keys > and Ben (benjojo.co.uk) grabbed them all? > That's pretty handy at times :) > But not this time :(

>Better luck next time, I guess :)

Who cares if they publish Public Keys. They're meant to be public, it's one of the few well named things in computer science. They are basically meant to be spewn everywhere.

<comment><USER31> You may be interested in knowing that you can DOS someone if you know only their public keys. [https://medium.com/@gmalette/mistaking-authentication-for- id...](https://medium.com/@gmalette/mistaking-authentication-for- identification-983447739eee)

<comment><USER32> DOS is a bit of a misleading term here. You're not actually denying them service at all. You're just tricking the service provider into potentially mis-identifying them as a different user, depending on how their SSH is configured, and it's easily solved by a small SSH config change on their end. And it only works against someone who has multiple keys anyway.

> _A simple solution would be to avoid the single user login firstname.lastname@example.com, > and use that as identification, for example email@example.com._

Except this completely ignores the reason why services use email@example.com. It's not because they're lazy. It's because the URL is supposed to identify the project, not the user. If the URL included the user's own username, that URL wouldn't work for anyone else, which breaks git-submodules, breaks any kind of config file that specifies repositories (e.g. for use by a CI server), and removes the ability for people to copy&paste a `git clone` command from a README (or blog post or wherever else).

So yes, there is a theoretical annoyance attack here, but nobody really cares because it's never going to happen accidentally, it can't be used against most people, and it's so trivially bypassed nobody's going to bother doing it except as a PoC. The benefits of using firstname.lastname@example.com greatly outweigh the downsides.

<comment><USER31> > and it's easily solved by a small SSH config change on their end

The article does mention it. The issue is not fixing the problem, it's actually finding it.

> [...] that URL wouldn't work for anyone else, which breaks git-submodules, > breaks any kind of config file that specifies repositories (e.g. for use by > a CI server)

It doesn't explain why Heroku uses it. Do you really push different submodules to Heroku?

For Github et. al, that's easily solved by project-level or organization-level identity.

> that URL wouldn't work for anyone else

And using `git@` doesn't work if you use multiple accounts because you'd specify the IdentityFile by host.

> nobody really cares because it's never going to happen accidentally

Except it does. Those service providers often get contacted because this happens BY ACCIDENT.

I've done it to myself by adding my public key to my work account. I couldn't access my personal stuff without changing my SSH config.

A while ago at work, we were using a shared key that was used to setup the initial vagrant config. New hires often added that key to their github or heroku account.

I've heard similar stories elsewhere too.

<comment><USER32> > _It doesn 't explain why Heroku uses it. Do you really push different > submodules to Heroku?_

I don't use Heroku, but, sure, why not? If I push a repo to Heroku that includes submodules, presumably Heroku then fetches those submodules (I'm assuming it supports submodules at all, which seems like an obvious thing to support). Therefore, those submodules must be specified by a URL that works for everyone, not just you.

> _For Github et. al, that 's easily solved by project-level or organization- > level identity._

How does that solve anything? You're no longer identifying the user whose key is supposed to be used, which means this no longer solves your problem. And if you're going to suggest that it should only consult users who have access to the repo, for a public project that's _everybody_ , which makes it functionally identical to git@.

> _And using `git@` doesn 't work if you use multiple accounts because you'd > specify the IdentityFile by host._

Sure it does. IdentityFile is explicitly allowed to be specified multiple times for a single host, and the files will be tried in turn. So you can specify all your keys that way.

> _Those service providers often get contacted because this happens BY > ACCIDENT._

Someone uploads a private key that doesn't belong to them by accident, that screws up other innocent people? I'm rather skeptical. What's your source on this? And no, your own anecdotes do not constitute proof that providers often have to deal with this.

> _A while ago at work, we were using a shared key that was used to setup the > initial vagrant config. New hires often added that key to their github or > heroku account._

Your work is handing out a shared public/private keypair and encouraging people to set this up as a default identity in SSH? That sounds awful, and it's entirely a problem you created and not even remotely the burden of GitHub or Heroku to care about.

<comment><USER31> > If I push a repo to Heroku that includes submodules, presumably Heroku then > fetches those submodules

You're missing the point. You may use submodules hosted on github with Heroku, but you don't use Heroku to host that repo. You're not going to `git submodule add email@example.com:project`. So for the sake of argument, if we pretend that git repo hosts do need to use `git@`, I don't see a single reason why Heroku would.

> And if you're going to suggest that it should only consult users who have > access to the repo, for a public project that's everybody, which makes it > functionally identical to git@

Now you're confusing two things. Do you want to clone a public module as a subrepo, or allow commit access? Public repos can be cloned without identification. If you want commit access, why would project-level not work?

> Sure it does. IdentityFile is explicitly allowed to be specified multiple > times for a single host, and the files will be tried in turn

Again, missing the point. If you don't specify a different host, you'll always be identified and authenticated as the first key that matches, therefore you'll only use a single account. That's why you have to use different hosts.

> And no, your own anecdotes do not constitute proof that providers often have > to deal with this.

If you're not going to believe anything I say, I got nothing. Otherwise, 2 things

\- I opened an issue and the response was basically "Ooooo that explains some of those tickets". They specifically mentioned issues with vagrant. \- I presented this at a local meetup and someone else had put themselves in this position.

> Your work is handing out a shared public/private keypair and encouraging > people to set this up as a default identity in SSH?

No. As I said, it was meant to setup the vagrant box and then not be used. By default vagrant connects using an insecure keypair.

<comment><USER32> > _You may use submodules hosted on github with Heroku, but you don 't use > Heroku to host that repo._

Ah, I see what you mean. But is that actually true? If you push a repo to Heroku, are you still expecting to host the canonical version of that repo elsewhere, instead of just using Heroku as the canonical version? Because if it's the latter, and you're working with other people, then it's still useful to have a single URL that identifies the repo.

> _Do you want to clone a public module as a subrepo, or allow commit access? > Public repos can be cloned without identification._

But you're going over SSH, so you have to negotiate the connection before the server knows what action you're taking. So the SSH connection will be the same whether you're pushing or pulling. You can't negotiate different identities for pushing vs pulling, so whatever identity you settle on has to work for both.

> _If you don 't specify a different host, you'll always be identified and > authenticated as the first key that matches, therefore you'll only use a > single account. That's why you have to use different hosts._

Ah, I see.

It sounds to me like using username@ is still completely useless regarding your proposed "attack", but does have some small utility for people who have multiple accounts. But I still think the obvious general utility of having a single URL that works for everyone is more important.

As an aside, it looks to me like you could try using the `Match` keyword in your ssh_config and have it run an external command that determines which account you should be using. This could be controlled with an environment var, or maybe it could look at $PWD. If you can come up with some suitable command, then you can use that to control which identity file to use.

> _If you 're not going to believe anything I say, I got nothing._

I believe your personal, anecdotes, but you can't just make a broad claim about providers with no evidence and expect me to believe that it really is as widespread an issue as you claim.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER33> There may be some people concerned with GitHub publishing their identity to everyone, but it is pretty easy to use a separate key for GitHub (they'll even generate it for you) if you configure your ssh client appropriately with Host sections. Also, the same technique works if you want to use two different accounts on GitHub (one for work & one for personal). [http://stackoverflow.com/questions/19310368/using-two-ssh- ke...](http://stackoverflow.com/questions/19310368/using-two-ssh-keys-with- github-along-with-connection-multiplexing)

</comment><comment><USER34> If this surprises people, it's definitely doing some good.

Nicely presented, Filippo!

<comment><USER35> surprise to me. added

IdentitiesOnly yes

to my config file.

</comment></comment><comment><USER36> Forgive me ignorance here but what steps should I take to avoid someone from getting my public key off github and then using it to screw with my repos? Was there a major step I missed here when I made these keys?

<comment><USER37> It's a _public_ key for a reason. You need to the private key to authenticate, so you're safe having everyone know your public key.

<comment><USER38> It's fairly pointless of github to publish your public key though. Nobody can trust that it's actually yours.

<comment><USER39> > It's fairly pointless

If it enables security research it's already a win in my eyes.

Might expose classes of weak keys in the future for example.

<comment><USER3> Great point. That's already happened, and a lot of weak keys were found [0].

[0] [https://blog.benjojo.co.uk/post/auditing-github-users- keys](https://blog.benjojo.co.uk/post/auditing-github-users-keys)

</comment></comment></comment></comment></comment><comment><USER40> Nice idea, but __don 't __run the command if you have

        Host *
          ForwardAgent yes

On your ~/.ssh/config

<comment><USER41> What is the effect of ForwardAgent ?

<comment><USER11> Forwarding your keys basically. It's like giving someone you don't know a handshake AND all your keys.

<comment><USER42> _public_ keys I hope?!

<comment><USER43> No, it gives the remote server use of your _private_ keys during the lifetime of your connection through connection to your local agent.

Yes, it's really stupid to enable AgentForwarding.

<comment><USER41> OMG! This was an important and helpful precision. Thank you very much.

</comment></comment></comment></comment></comment></comment><comment><USER44> Ooh goodie, we get to re-open the argument about whether it was bad of GitHub to publish the public keys![1] Pick your talking points: "They're called public for a reason.", "This could enable identity tracking.", "If your security model prefers public keys to be kept secret, it's absurd -- security by obscurity.", "This could enable factoring weak keys.", "This is good for security research.", "It's wrong to reveal metadata without consent, even if it doesn't break the crypto."

You could build in another PoC by doing the trick where you hide a command inside the copy-paste version of the ssh command line you gave.[2]

[1] [https://news.ycombinator.com/item?id=9645703](https://news.ycombinator.com/item?id=9645703) [2] [https://thejh.net/misc/website-terminal-copy- paste](https://thejh.net/misc/website-terminal-copy-paste)

</comment><comment><USER45> A great reminder that public key identity management is quite the unsolved annoyance. Why should you use the same key everywhere, allowing others to track you? Ideally you would have one key per service.

<comment><USER46> Yes.

And all of my machines are named "host", with user "user" :)

</comment></comment><comment><USER47> Wow, thanks for demonstrating this. A dead simple technique like this could have compromised me when trying to use SSH pseudonymously.

</comment><comment><USER48> Pretty interesting. Although it couldn't find my github ssh keys for some reason. Maybe the database has some stale entries? I imagine it's quite a lot of user data to go through and process.

</comment><comment><USER49> That's actually super handy. Next time I have to add someone to a shell account, I'll probably just look them up on GitHub first to find their public key instead of asking.

<comment><USER50> ... thereby making any successful manipulation of the github key database (by the github people or by an attacker, as has happened before - google e.g. [http://egorhomakov.com/](http://egorhomakov.com/) ) a successful penetration of YOUR system.

Security and convenience unfortunately conflict often.

</comment></comment><comment><USER51> It just closes my connection.

        root@paragonie:~# ssh whoami.filippo.io
        Connection to whoami.filippo.io closed.

I'm not sure what I'm supposed to be seeing.

<comment><USER52> ...presumably it doesn't allow root logins via SSH

<comment><USER51> Oh, duh, username!

<comment><USER53> Why on _earth_ are you logged in as root? man sudo

<comment><USER54> sometimes you just sudo -s

<comment><USER55> I prefer su -

<comment><USER54> You need a root password for that one.

</comment></comment></comment></comment></comment></comment></comment><comment><USER56> It seems that I get no output because I have an SSH certificate:

      robryk@sharya-rana ~> ssh -v whoami.filippo.io
      <...>
      debug1: Next authentication method: publickey
      debug1: Offering RSA public key: /home/robryk/.ssh/id_rsa
      debug1: Authentications that can continue: publickey,keyboard-interactive
      debug1: Offering RSA-CERT public key: /home/robryk/.ssh/id_rsa
      Connection closed by 18.104.22.168

</comment><comment><USER57> A good reminder that your public keys are, in fact, public. For most people, this is probably a good thing, unless you're specifically trying to hide your identity.

<comment><USER58> But I wish anonymity was the default, not something I have to enable as a special case... :(

</comment></comment><comment><USER59> I use different keypairs for different trust domains. (also makes it easier to hand over access when you quit a job.)

SSH keys are actually pretty horrible from a security perspective; no expiration, generally held in software, etc. And without a lot of work, single-factor. I love the ssh security model of being pretty good and better than telnet for everything (which it ~fully displaced, unlike https vs. http), but client keys are one of the weak points.

<comment><USER20> > And without a lot of work, single-factor.

Wouldn't a passphrase be a second factor?

By the way, we use a security fob at work for that. Seems to work fairly well. The private key never leaves the fob, you have to press a button to sign anything, and every once in a while you have to enter your passphrase.

<comment><USER59> passphrase is set/unset locally and not communicated to the server if it is present/used/etc. Could be disabled. along with various other things.

HW token with ssh key inside is probably the best. The annoying thing is devices w/o USB. For iOS devices and android devices which support it it's probably better to just use the HW sec features. Something which did bt 4.0le and maybe had a single local LED and button would be better still.

<comment><USER20> > The annoying thing is devices w/o USB.

Some new tokens use NFC.

<comment><USER59> Yeah, but sadly closed iOS sometimes oddly security hostile ecosystem bullshit.

Bluetooth would be vastly better for interop.

</comment></comment></comment></comment></comment><comment><USER60> Neat stuff. You could use this to let users identify themselves to services/ssh services via pubkey as their GitHub username - <USER2> [https://github.com/shazow/ssh-chat](https://github.com/shazow/ssh-chat) \- but with users automatically unique and identified by GitHub.

<comment><USER61> CoreOS used to do this, but stopped doing it: [https://github.com/coreos/coreos- cloudinit/issues/334](https://github.com/coreos/coreos-cloudinit/issues/334) Basically, they don't want server provisioning to depend on Github being up.

</comment></comment><comment><USER62> Would be interesting to see what can also be done with Keybase API.

</comment><comment><USER63> Cripes, people. WHO CARES?

So I SSHed in. I got the message. Then I saw all the people freaking out here and couldn't believe my eyes.

Ask yourself this:

How often do you SSH in to arbitrary hosts? Ones that you don't control, or work for, or trust with your source code?

Did you really expect that you could give the same long unique base64 string to a bunch of different hosts and NOT have them connect your identity between them?

Do you not understand that the whole point of public keys is to uniquely and reliably identify yourself to an arbitrarily large number of parties?

Honestly, the only real eye-opener here is that Github gives out your public keys and can be scraped to collect all of them. But some of us have been using that functionality to share / snag each other's public keys for a long time now anyway.

</comment><comment><USER64> Found me; very nice. I wouldn't have guessed how you did it without the explanation about GitHub.

I wonder if this means we should be rotating keys periodically? I know most companies require users to rotate their password every X days.

Also, does GitHub have a setting to disable public key publishing?

<comment><USER65> They're public keys, they're intended to be public. What are you trying to hide by hiding your public key?

<comment><USER66> Though it may be incredibly impractical or theoretically impossible, depending on the key and time of day, there is always a possibility that a public key can be used as an attack vector to guess a private key.

<comment><USER31> Or simply to DOS you out of your other accounts. [https://news.ycombinator.com/item?id=10005358](https://news.ycombinator.com/item?id=10005358)

</comment></comment></comment></comment><comment><USER67> Does the server get the client's public key before or after the client has identified the server? I suspect it's after - which would imply that this is much less harmful than it looks like, since by then you've already confirmed the identity of the server.

So if my assumption is correct (some quick googling for images of the ssh key exchange suggests it is), then the reason it "works" in this case is because people intentionally say "yes" when presented with the fingerprint, just to see what would happen. If you were ssh-ing to a server that you've used before, there is little to worry about because the ssh client first authenticates the server, and the server presumably needs to know who you are anyway.

<comment><USER68> The server only gets the key after it has been identified; you can see that by using "ssh -v".

</comment></comment><comment><USER69> From [http://www.cisco.com/web/about/ac123/ac147/archived_issues/i...](http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_12-4/124_ssh.html)

"publickey: The details of this method depend on the public-key algorithm chosen. In essence, the client sends a message to the server that contains the client's public key, with the message signed by the client's private key. When the server receives this message, it checks to see whether the supplied key is acceptable for authentication and, if so, it checks to see whether the signature is correct."

</comment><comment><USER70> Didn't work for me because I use a separate key for each "class" of machines, where class is github, bitbucket, work, home, ...

You can reduce the maintenance load by using the %h (remote hostname) and %r (remote username) substitutions in IdentityFile. I make a symlink from the key I want to e.g. id-rsa-<remoteuser>@<remotehostname>.key and use IdentitiesOnly.

See 'man ssh_config'

Use %u (local user) and %l (local hostname) for extra control.

It doesn't have %p (port) but the Host parameter in future versions of openssh will let you match on that too.

</comment><comment><USER71> Isn't this just ssh functioning as usual? You can specify which public key ssh should use by updating .ssh/config

Otherwise, what's the harm in other people knowing your public key?

<comment><USER72> Yes, but it's also ssh functioning in a way people don't know about.

</comment></comment><comment><USER54> Luckily, putty/kitty does not send anything to unknown hosts. Good try though. Please accept a record of my IP address connecting to your honeypot as a token of gratitude.

<comment><USER20> The standard linux ssh client also asks for confirmation before sending anything interesting to a new server.

</comment></comment><comment><USER73> weird idea: server that hosts open source git repos, but won't let you ssh in to clone unless your GitHub account has contributed to an open source project this year.

<comment><USER74> This would make this repos not open source, unless they are replicated elsewhere as well.

</comment></comment><comment><USER75>
      ssh_dispatch_run_fatal: Connection to 22.214.171.124: no matching key exchange method found

Hm.

      kex: client->server email@example.com

Meh.

<comment><USER76> Same. Apparently this server does not support any modern day crypto.

</comment></comment><comment><USER77> I wish there was a way to have ssh automatically ssh-add keys you use... with a expiration date. I've tried to get this to work a few times, but I use a unique key for every login, so I need something to parse ~/.ssh/config to find the right Host def and ssh-add it. The code is obviously in ssh, but it's not exposed to the command line as far as I can tell.

</comment><comment><USER78> Good thing I use HTTP to push to Github (or not?)

<comment><USER45> Just use another key. I have like 20. It sucks that doing this is pretty complicated though. Separation of identities is _crucial_ on the internet.

</comment></comment><comment><USER79> This is clever, and very sneaky!

Let's say I downloaded every public key from GitHub to ~/.ssh. Would this identify me as everyone on GitHub, or just the owner of the first public key to match?

Furthermore, I wonder how Go channels compare to libevent (more specifically, epoll/queue) for high-performance network software. Is there any previous work which compares the two?

<comment><USER80> Adding those public keys would not identify you as everyone, as you do not have all the matching private keys.

<comment><USER79> Someone else commented on here that:

> FYI, this happens because SSH automatically presents a public key to the > server when trying to authenticate. If the server doesn't know that key, > then SSH tries the next one. You can enumerate all of someone's keys this > way (like this SSH server does)

Therefore, even though I can't authenticate as Linus Torvalds, an SSH server can see me present his public key and hence, log that public key for future use, like sending a message? Is that not correct?

</comment></comment></comment><comment><USER81> I dont want to "play" with ssh_config file. My concern here is how pageant/ssh-agent behave, i think i'll try to fix/find a way around that (e.g. attended calls to agent signing api / configurable calls to agent keys listing).

I think i'll drive a node-webkit/systray project being an alternative to pageant (#nwagent on freenode)

</comment><comment><USER82> "Public keys" are supposed to be public anyway, isn't that what it's designed for? I see no harm

<comment><USER83> Using the same public key on two sites is like using the same username - something that you would do only if you want your identity linked between those sites. It's also a much stronger proof of identity than having the same username, because that's what they were designed for.

<comment><USER19> So don't use the same public key on two different site

</comment></comment></comment><comment><USER84> like google analytics cookies track your every activity on every website, sending public keys feel the same way.

now I have to re-evaluate my ssh usage after discovering ssh sends all my public keys. need to setup per server identities, without too much usage hassle .

hope github will stop publishing public keys.

</comment><comment><USER85> Interesting, it didn't work for me because I use a Yubikey Neo with PKCS11 for my SSH keys.

</comment><comment><USER86> The last time this came up, I wrote a little script to update your authorized_keys file with your github keys.

[https://github.com/GauntletWizard/pamgithub](https://github.com/GauntletWizard/pamgithub)

</comment><comment><USER87> No sure if I am missing something here, but that's the idea behind PKI infrastructure: You can share your public keys without putting your identity at risk.

The "server knows who you are" or rather, I "tell the server who I am"

Interesting experiment though.

</comment><comment><USER88> I first thought this was something new but wait he just gets public ssh keys. It is public for a reason, meaning anyone can have it and they are frankly useless. Can't find any comment below saying why this is dangerous ?

</comment><comment><USER89> The connection gets closed immediately for me, what is it supposed to do?

<comment><USER90> For those who couldn't make it work:

            +</comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>---+
            |                                                                     |
            |             _o/ Hello!                                              |
            |                                                                     |
            |                                                                     |
            |  Did you know that ssh sends all your public keys to any server     |
            |  it tries to authenticate to? You can see yours echoed below.       |
            |                                                                     |
            |  We tried to use that to find your GitHub username, but we          |
            |  couldn't :( maybe you don't even have GitHub ssh keys, do you?     |
            |                                                                     |
            |  By the way, did you know that GitHub publishes all users'          |
            |  ssh public keys and Ben (benjojo.co.uk) grabbed them all?          |
            |                                                                     |
            |  That's pretty handy at times :) But not this time :(               |
            |                                                                     |
            |                                                                     |
            |  P.S. This whole thingy is Open Source! (And written in Go!)        |
            |  https://github.com/FiloSottile/whosthere                           |
            |                                                                     |
            |  -- @FiloSottile (https://twitter.com/FiloSottile)                  |
            |                                                                     |
            +</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>---+

<comment><USER91> And for those that want to see what a successful key check looks like:

        +</comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>---+
        |                                                                     |
        |             _o/ Hello Evan Tschuy!
        |                                                                     |
        |                                                                     |
        |  Did you know that ssh sends all your public keys to any server     |
        |  it tries to authenticate to?                                       |
        |                                                                     |
        |  That's how we know you are @tschuy on GitHub!
        |                                                                     |
        |  Ah, maybe what you did't know is that GitHub publishes all users'  |
        |  ssh public keys and Ben (benjojo.co.uk) grabbed them all.          |
        |                                                                     |
        |  That's pretty handy at times :) for example your key is at         |
        |  https://github.com/tschuy.keys
        |                                                                     |
        |                                                                     |
        |  P.S. This whole thingy is Open Source! (And written in Go!)        |
        |  https://github.com/FiloSottile/whosthere                           |
        |                                                                     |
        |  -- @FiloSottile (https://twitter.com/FiloSottile)                  |
        |                                                                     |
        +</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>---+

Connection to whoami.filippo.io closed.

</comment><comment><USER92> After the question of adding this server to known hosts OS X asked me for the passoword of my private key. Is this normal? Of course I refused and got the message like displayed in other comments.

</comment><comment><USER93>
        We tried to use that to find your GitHub username, but we
        couldn't :( maybe you don't even have GitHub ssh keys, do you?

You just need to properly configure your SSH.

</comment><comment><USER94> In all seriousity, I would love a similar SSH server that automatically uses keys from GitHub for authentication. Great for setting up a little private git server without fiddling with keys.

<comment><USER95> Just keep in mind that you're now at the mercy of github. Or whomever pwns their servers.

<comment><USER20> You can salvage something from that idea: github is in the public eye. If they do something fishy, you'll probably now about it a month later.

So, for your login service you scrap github periodically, and only trust things that have been there a month ago already.

(A bit like ssh being vulnerable to MitM attack on the very first connection, but not afterwards.)

</comment></comment></comment><comment><USER96> It didn't work for me even though I have a github account and ssh key installed from the same machine. Maybe related to the fact I use several keys and keychain to manage keys.

</comment><comment><USER97> I'd noticed before that ssh was rather aggressive about offering public keys to servers, but I didn't know Github published my public keys, and so this totally surprised me.

</comment><comment><USER98> Ok, as a total noob, what does this this suppose to demonstrate?

</comment><comment><USER99> Go has a great SSH library from what I can tell. I'm currently working on a project that is based around SSH, and Go seemed to be the only real option.

</comment><comment><USER100> At first, I thought that this is pretty harmless, but now I suspect that there may be a way to exploit a dump of public keys tied to personal information: let's say that some powerful adversary (like NSA) uses some kind of rainbow tables to associate public keys with private. Having a lot of public keys, they are likely to know some private ones and identities behind them.

This hypothesis requires some mathematical ground, though. It may be that probability of guessing a private key is still negligible.

<comment><USER19> > rainbow tables

There is no such thing in public key crypto.

The only thing that comes close to it that I can think of is the problem where weak public parameters were hard coded in a library (Apache) and were used by many many many person. Look at the logjam paper.

</comment></comment><comment><USER101> Just kicked me off after I accepted it's fingerprint, maybe it's down? I have a 8192 bit RSA key.

</comment><comment><USER102> Eh, I only forward my github ssh key to the host github.com so you don't know who I am ;-)

</comment><comment><USER103> I simply got a "Connection to whoami.filippo.io closed."

<comment><USER104> Same here...

</comment></comment><comment><USER105> so what does this imply, security wise? Isn't public key a give-away anyways? which is what public means?

Or I'm going to ssh-keygen a new one once a while.

</comment><comment><USER106> Doesn't work on OS X 10.10.4?

</comment><comment><USER107> i know what you did last summer on my server, would have been better title.

</comment><comment><USER108> I don't see what's wrong with that.

</comment><comment><USER90> I use putty, this failed.

<comment><USER109> Strictly speaking, it didn't fail; _PuTTY_ on Windows works a bit differently from command-line _ssh_ on OS X/Linux, and doesn't show you everything. It brings you directly to a "login as:" prompt after throwing up a dialog about missing/unknown keys. What you were supposed to see never made it to the screen.

<comment><USER110> Worked fine on my PuTTY, got the message after leaving an empty user at the "login as:" prompt

<comment><USER109> Interesting. When I tried it at work earlier (Windows 7, latest PuTTY) it closed out the window without showing anything. I just tried it at home (Windows 10, latest PuTTY) and it worked as you said.

<comment><USER111> There is a setting for it:

[http://i.imgur.com/6G3NxvJ.png](http://i.imgur.com/6G3NxvJ.png)

<comment><USER109> Right there in front of me. Now I'm wondering when and why I changed that behavior at home (I'm assuming the "Only on clean exit" setting is the default).

</comment></comment></comment></comment></comment></comment><comment><USER112> tl;dr:

1\. ssh sends the pubkey you use on github ^1

2\. his server compare with the publicly ^2 available pub key you uploaded to github.com

^1 (not mine, i set keys per domain)

^2 news to me!</comment>


Don't give me that crap about security, just put the backdoors in the encryption - <AUTHOR> https://www.theregister.co.uk/2019/07/23/us_encryption_backdoor/ <comment><USER2> This is a result of LEAs not adjusting to the modern world. Policing city streets and physical locations is nothing like policing technology. LEAs don't see a difference between a lock on a door and a cryptographic lock on a cellphone. They can get a warrant to unlock the door, or worse just kick it in. Even if they did get a warrant to unlock a phone, if there is no key they cannot "kick" the door in (unless the use some other exploits), so they are demanding a key to every lock.

<comment><USER3> They require all homes to have a rear door with a cheap padlock that "only they" will have the key. The funny thing of all this is that it accomplishes exactly nothing.

<comment><USER4> Inviolable control isolated to the carpals, metacarpals, and phalanges of a few... could very well be the "what we want to accomplish" which is a more worrisome truth than we can admit as a representative republic without a ranked choice ballot.

</comment></comment></comment><comment><USER5> I'd be surprised if this doesn't already exist in some shape or form. Is this article just a coverup to lead people to believe it doesn't? The big tech companies are pretty expensive for a reason, and likely that half the added cost goes to funding 20% more infrastructure to continue projects like PRISM. We make it so easy by putting all our data in a few companies. Have hooks in Google/AWS/MS and you're pretty much set.

</comment><comment><USER6> Adding backdoors would lead to the Huaweization of American tech companies -- Sales of US tech products outside of the US would drop drastically. And the non-stupid bad actors (however small that subset is) would use something open- source, or perhaps sourced from their non-US allies.

<comment><USER7> I'm curious how much it's affected Australia since they passed a similar, though incredibly weak law.

Web Crypto + WebRTC + keybase === end to end, peer to peer, encryption.

<comment><USER4> Can the Australian law be invoked in such a way to make a backdoor for government eyes in a publicly and widely distributed software? If so, then it's some big brother shit.

</comment></comment></comment><comment><USER7> So, what he's saying is he wants China, Russia, etc to be able to read all of Congress', Senate's and President's emails, messages and tap all phone calls?

</comment><comment><USER4> BARR, there is no way to untangle the yarn produced in nations outside our own. LET IT BE KNOWN that combatting encryption with courtside pry will only lead to weakened civil liberties, more secret courts to cover up your secret breaking of the law, and more vulnerability and security disclosures both civilian and governmental. Introduce no back door, appeal to peoples' sense of ethics. We are not all beasts like you may have been convinced.

</comment><comment><USER8> I'll gladly purchase products overseas if the US chooses to break it's technology.</comment>


Compiling a Lisp to x86-64: Primitive binary functions - <AUTHOR> https://bernsteinbear.com/blog/compiling-a-lisp-5/ <comment><AUTHOR> I'm writing a series on compiling Lisp to x86-64 and I would appreciate any and all feedback.

Find the first post at [https://bernsteinbear.com/blog/compiling-a- lisp-0/](https://bernsteinbear.com/blog/compiling-a-lisp-0/)</comment>


President Obama Is Waging a War on Hackers - <AUTHOR> http://www.wired.com/2015/01/president-obama-waging-war-hackers/

<comment><USER2> Yawn.

See... * War on Drugs * War on Terrorism

<comment><USER3> Yeah, but this time he is targeting people with higher earnings. So the backlash could be real when potential victims could be middle and upper class IT, developers and security researchers.

Who has not built a scraper for something one or other time in his career.</comment></comment>