Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

1Password for SSH and Git (Beta)

developer.1password.com

Post reply on HN
Print view View original

341–350 of 406 posts

Re: 1Password for SSH and Git (Beta)

#341

Post by throwanem »

jaboutboul wrote: post #202
c0balt wrote: post #195

Earlier quoted context omitted.

Maybe a solution would be to get inspiration from keepass(xc) attachement's feature. It allows you to save abitrary files as attachement to an entry (btw this is how keepassxc does ssh key managment). Other keys/ certs (like HTTPS certs) would be supported such a feature too. The 'only' downside is the comparatively high increase in database size for the hoster.

1Password already has this…

Judging by both the GP's not having been aware of it, and the process described in a sibling comment [1], I suspect the feature has a discoverability problem.

(Does the same feature exist on mobile? How are file attachments represented on mobile?)

[1] https://news.ycombinator.com/item?id=30365088

Re: 1Password for SSH and Git (Beta)

#342

Post by tialaramex »

captn3m0 wrote: post #18
nerdawson wrote: post #5

I’ve been treating SSH keys in the same way I would a password. Each service gets a new key generated for it. From doing some reading though it sounds like I might be wasting my time. Apparently it’s fine to have one key for an individual machine and to use that for everything. What’s everyone else’s take on that? Are you reusing a single key or generating each time?

I'd love to, but I keep keys on my Yubikey - which only supports 1 auth key. Even using U2F for SSH keeps the same restrictions. And using a different yubikey for various services isn't ideal either. I have considered keeping encrypted keys in my password manager per-service, and decrypt+add them to my SSH agent when they're used to offer almost the same guarantees.

> Even using U2F for SSH keeps the same restrictions

Er, what? The SSH keys are being generated the same way keys for web sites are under FIDO, which is to say they're random - your physical device has no idea how many keys you have, it couldn't mandate that there's only one key if it tried. It only knows how to tell if these are keys it made (otherwise presumably a different FIDO authenticator made them) and if so use them to sign you in once somebody touches the contact.

Re: 1Password for SSH and Git (Beta)

#343

Post by [deleted] »

rcarmo wrote: post #99

I'd rather use Secretive ( https://github.com/maxgoedjen/secretive ), to be honest. I've stopped using 1Password everywhere I can due to their product "focus", and am working my way through a set of alternatives (currently using Secrets on the Mac and looking at the KeePass ecosystem, which keeps improving monthly): https://taoofmac.com/space/apps/1password Edit: It's been fun watching this get upvoted and downvoted…

[deleted]

Re: 1Password for SSH and Git (Beta)

#344

Post by brailsafe »

judge2020 wrote: post #190
trvr wrote: post #185

Earlier quoted context omitted.

Not looking for a fight here, but it seems like there is a disconnect between 1Password/AgileBits praising version 8 while also trying to bury the fact that it is an Electron app. It seems like you are proud of what you are building (and that's awesome), but the Releases page for beta [1] doesn't contain the word Electron. 1: https://releases.1password.com/mac/beta/

Electron is effectively a UI and code framework, much like SwiftUI or just Swift with AppKit; I don't see why either would need to be a marketing point or referenced in the changelog. 1Password 7[0] doesn't say what it's made in either. 0: https://support.1password.com/explore/whats-new-mac/

This is a specious argument imo. The beta does mention that some part of it is written in Rust, why exclude Swift/Objective-C to JavaScript if you're in the business of talking up implementation changes?

Re: 1Password for SSH and Git (Beta)

#345

Post by lnxg33k1 »

bityard wrote: post #134
Cthulhu_ wrote: post #109

Earlier quoted context omitted.

I started using it back when because it just worked and I could keep my passwords synced between devices (windows, iOS and Mac) via Dropbox. Before that I used KeePass, but its Linux and Android clients were terrible. I still have 1password 4 on Windows PC and (apparently) version 7 on Mac; they still work together, but I'm afraid at some point they will decide to drop support for dropbox and force you to use their s…

I have been using KeePassXC on Linux for years, it works great. On Android, you want KeePassDX which can be found on f-droid. I have multiple keepass databases and keep them in sync with a self-hosted Nextcloud instance.

The same, but with syncthing, I don't really see the utility of giving 1password or any company my ssh passwords or my passwords, like they're there for anyone to attack

Re: 1Password for SSH and Git (Beta)

#346

Post by tialaramex »

bombcar wrote: post #23
fredley wrote: post #8

Earlier quoted context omitted.

A mix. Typically I'll use one key per machine and add those keys in the places they need to be. This is good as you're reasonably well protected if that machine gets lost or stolen. The nature of public key cryptography means there's no risk associated with handing over your public key to many different places. However sometimes it's practical to use the same (private) key in multiple places. I do this for access to…

There is a slight risk - if someone has your public key they can setup a MITM server and pretend to be the one you’re expecting - and watch what you’re doing, or redirect test to production or similar. It’s really very minor and ssh itself should warn that the servers fingerprint changed.

Public keys are identity, so, a remote server can (and a famous one does: https://github.com/FiloSottile/whoami.filippo.io) tell you if e.g. you connect to it while offering to prove your identity with keys github knows about, because github provides a list of those keys. That's the extent of the interesting consequences of knowing your public keys.

You can't realistically MITM SSH because you will have a session mismatch. You may be able to convince a naive visitor (coming to some.machine.example with no prior contact, and not using either certificates, or secure DNS protected credentials to verify the identity of the machine) that you're some.machine.example but you can't successfully splice this to a connection with the real some.machine.example if they use public key login.

The reason is, during connection you persuaded the client that you are some.machine.example, but to do that you needed to make up keys since you don't know the real keys for some.machine.example. However the real some.machine.example does know its keys and they're different. The credentials the victim client gives you only work for your keys, they won't work for the real some.machine.example keys, and the client has no reason to present you with credentials that would work for the real some.machine.example, so you can't authenticate to the real some.machine.example as them.

Re: 1Password for SSH and Git (Beta)

#347

Post by roustem »

roustem wrote: post #320
DonHopkins wrote: post #186

Earlier quoted context omitted.

SSH keys have both a private and a public file. The private file is multi-line text. I don't like putting the private key in the notes field, because its name is still "notes" (but I'd prefer the label be the key's file name), it's actually markdown formatted text, not literal text, and what if I still want to write a note, but I've already used the notes field for the key? HTTPS certificates including multiple certi…

Thank you for the feedback! We spoke about it internally many times in the past but couldn't get the solution implemented because there was always something in the way. After reading your comments and I talked to the team and we just merged a change that should appear in the nightly build and make the handling of the multi-line fields better. Having a single core in 1Password 8 makes things so much easier when it com…

Just wanted to add that the nightly build 80600030 is now available. Would love if you could give it a try and see if the newly added textfields are working better for you?

Re: 1Password for SSH and Git (Beta)

#348

Post by soheil »

staticassertion wrote: post #176
soheil wrote: post #129

Earlier quoted context omitted.

Why can the compromised package not also access wherever 1p is storing the keys or access the part of memory they're loaded into?

A process can not dump the memory of another process if those processes are executing under different users, or the process performing the dump is root. On many OS's there are even more strict restrictions, where within a user a process can only dump the memory of processes that are its direct descendants.

1p runs as the logged in user so does a hypothetical malicious npm package.

Re: 1Password for SSH and Git (Beta)

#349

Post by zimmund »

barkerja wrote: post #248
Saint_Genet wrote: post #50

Earlier quoted context omitted.

Not really into replacing vetted, well tested open source software with a proprietary app with cloud storage.

They have a nice little tidbit on this: https://developer.1password.com/docs/ssh/agent/security > The standard OpenSSH agent (ssh-agent) that comes preinstalled on most systems requires you to add keys to the agent (ssh-add) every time it launches. After you've added your keys, any process can use any SSH key that the OpenSSH agent is managing. It is then up to you to remove those keys when they're not needed anymore…

> your private keys will never be used without your consent.

Unknown vulnerabilities won't need your consent.

Re: 1Password for SSH and Git (Beta)

#350

Post by noahtallen »

dsissitka wrote: post #49
skuzzie wrote: post #27

Earlier quoted context omitted.

From the article: "Our new 1Password apps are built in Rust..." Maybe give this version a try then?

Unfortunately that's deceptive. > This resultant application is hosted within Electron to ensure we have the exact same platform as our users. https://www.reddit.com/r/1Password/comments/o0f9cl/were_the_...

Is it? The Reddit comment mentions that most of the code is written in Rust — I assume business logic, encryption, etc — and the UI is in electron via React.

So this certainly seems quite a bit different from plain electron apps.

Post reply on HN