If SSH were configured like its predecessor – to trust machines and the usernames they provided – very bad things could happen.įor example, imagine Mr. (Things were bad in the bad old days.) Other machines, including quine, don’t get the updates as quickly. User on a machineĬonsider a network with a machine called russell that’s carefully managed and receives all security updates within months instead of years. SSH was designed as a replacement, but with cryptographic goodness. The point here is that rsh, along with the related rlogin, were based on trust between machines. SSH was a solution to that, and many other problems. It was too easy for someone to get a machine to masquerade as russell to whitehead. 2 And as machines became cheaper and more connected to the network, the people who ran the system could no longer rely on the idea that every machine on their network was honest. One was that it didn’t provide a reliable way for russell to prove to whitehead that it really was russell. There were many problems with this scheme. Anyone with the same username on both machines could log in to one from the other with no further authentication. There was some ability to configure things for specific users but this was fundamentally a machine-to-machine trust relationship. I could use rsh to hop over to whitehead if that machine listed russell as a trusted device for this purpose. It makes sense that if I’d logged on to russell as user goldberg, and the operators configured whitehead to trust russell, I should be able to jump over to whitehead with little fuss. Both are administered by the same people with similar policies. 1 As more computers in these environments were made available, it became useful for users to log in to one of them from another.įor example, imagine two machines called russell and whitehead. I could do stuff within my own account but I couldn’t touch the system’s configuration. The user accounts on these computers were managed by system administrators, and ordinary users had limited rights on them. In my case, the computers were owned and operated by the universities I attended. Instead, they used terminals connected to somebody else’s computers. In the before timeīack in the 1980s, very few individuals used their own Internet-connected computers. This will also make it clear that the reasons for some of the SSH key management practices became obsolete quickly. Next, I’ll go into some history in an attempt to explain what those original reasons were and why the conventional wisdom was what it was. Only then can we evaluate whether we’re doing something good or bad. But when in the course of geeky events it becomes necessary for one set of geeks to dissolve practices and conventions, a decent respect to the opinions of others requires that they should declare the causes which impel such a break with tradition.įirst, we need to understand the reasons for the conventions we’re breaking. I don’t think either of these beliefs are controversial. SSH private keys should be locked and unlocked when other high-value user credentials are locked and unlocked.SSH key pairs belong to people, not to the machine those people SSH from.We designed the 1Password SSH agent with the belief that: The 1Password SSH agent and its integration fix those problems, but it means that some of us old-timers need to adjust how we think about SSH keys. But certain security practices - and unintended consequences - followed, and they’ve been problematic since. This all made sense at the time SSH was invented. A key pair didn’t so much belong to a person, but a user logged on to a particular host. SSH key management tools and conventions grew out of that environment. Some of us old-timers need to adjust how we think about SSH keys. SSH private keys were associated not just with individuals, but individual accounts on particular hosts. The short version is that SSH was originally a drop-in replacement for rsh (remote shell) and rlogin, which were centered around one machine trusting another machine, or one account on a machine trusting an account on another machine. Today, I’ll discuss a re-evaluation of the security properties and habits some of us old-timers may have regarding SSH keys, and which of those habits are outdated. The 1Password SSH agent is a big step toward aligning practices with the modern world.Įarlier this year, we introduced the 1Password SSH agent as part of our commitment to bring developers the kinds of things developers want to see. SSH key management practices reflect the environment in which they were first introduced.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |