The official git client for windows support ssl, openssl, scp, ... , much more powerful than putty.
Do you have a workaround for having to run them in a `cmd` or `powershell` window? Those are worse than the old terminals in many cases.
PuTTY 0.64 released, fixing a security hole
21–30 of 43 posts
Re: PuTTY 0.64 released, fixing a security hole
#22Re: PuTTY 0.64 released, fixing a security hole
#23I used to be a huge PuTTY (or derative) user, but recently, I've switched to just using the normal OpenSSH command-line client within Cygwin and ConEmu. While PuTTY is nice, it lacks some features, like proxycommands and stuff which are standard in ~/.ssh/config. Things which can be taken along in a simple & portable fashion. No disrespect to PuTTY, but I just found myself not really needing it anymore.
You can also get many unix commands, including ssh, from the git packages. They work remarkably well, with the limit being you get to run them in `cmd` or `powershell` windows.
Re: PuTTY 0.64 released, fixing a security hole
#24I used to be a huge PuTTY (or derative) user, but recently, I've switched to just using the normal OpenSSH command-line client within Cygwin and ConEmu. While PuTTY is nice, it lacks some features, like proxycommands and stuff which are standard in ~/.ssh/config. Things which can be taken along in a simple & portable fashion. No disrespect to PuTTY, but I just found myself not really needing it anymore.
I prefer XShell5. http://www.netsarang.com/products/xsh_overview.html
Nice try, XShell employee.
I doubt that anyone is going to take $90/year closed source payware over well known FOSS like OpenSSH or PuTTY here at HN.
Re: PuTTY 0.64 released, fixing a security hole
#25Re: PuTTY 0.64 released, fixing a security hole
#26I used to be a huge PuTTY (or derative) user, but recently, I've switched to just using the normal OpenSSH command-line client within Cygwin and ConEmu. While PuTTY is nice, it lacks some features, like proxycommands and stuff which are standard in ~/.ssh/config. Things which can be taken along in a simple & portable fashion. No disrespect to PuTTY, but I just found myself not really needing it anymore.
I've been recommending MobaXterm [1] to people. My favourite feature is that it has an embedded and pre-configured X server for X forwarding.
Re: PuTTY 0.64 released, fixing a security hole
#27I used to be a huge PuTTY (or derative) user, but recently, I've switched to just using the normal OpenSSH command-line client within Cygwin and ConEmu. While PuTTY is nice, it lacks some features, like proxycommands and stuff which are standard in ~/.ssh/config. Things which can be taken along in a simple & portable fashion. No disrespect to PuTTY, but I just found myself not really needing it anymore.
Likewise. Moved to Mosh in a VM and now have continual access to several boxes with very little effort.
Putty allowed for more secure remote working when on untrusted networks, but not having to constantly enter credentials is much more preferable.
Re: PuTTY 0.64 released, fixing a security hole
#28Kind of off topic: Is there a secure way to download PuTTY? They are hosting on a http page. Though they provide RSA and DSA signatures how would I verify the signatures themselves? I'm kind of new to walking through trust paths. I don't even have any entry point too since nobody I know use public key encryption (I trust the Debian keys already though since I use their distro, maybe I can use that for a starting poin…
According to: https://news.ycombinator.com/item?id=7334269 - doesn't look like it's currently possible...
Re: PuTTY 0.64 released, fixing a security hole
#29Earlier quoted context omitted.
Not if they have been signed with PGP.
I have to ask: how are the PGP keys verified?
Through the Web of Trust:
https://en.wikipedia.org/wiki/Web_of_trust
http://www.pgpi.org/doc/pgpintro/
http://www.rubin.ch/pgp/weboftrust.en.html
Essentially: with cryptography, you aren't concerned about the transport, you're concerned about the crypto.
Signatures of the source or binaries will tell you if they've been changed.
Signatures on keys will tell you who trusts those keys. If someone you trust trusts a key, then you have a transitive trust of a key. This does mean, though, trusting people not to sign bogus keys.
In TLS/SSL, you have a hierarchical trust. Your session (and its contents) are encrypted and authenticated by the host key, which is signed by the CA's key. The theory is that we can trust CAs. Practice shows otherwise.
It's not cryptographically viable to fake a signature (of a key or data), though if someone manages to lose control of their private key, that's possible. PGP/GPG doesn't handle expired keys well.
But the upshot is that HTTP transport of PuTTY is fine from an integrity standpoint, so long as you verify the binary and signatures. And if you don't mind others being able to see what you're fetching as you're fetching it (the only real benefit to HTTPS in this case).
Even an MITM rewrite of data isn't a critical issue since you can catch that in PGP validation.
Re: PuTTY 0.64 released, fixing a security hole
#30Kind of off topic: Is there a secure way to download PuTTY? They are hosting on a http page. Though they provide RSA and DSA signatures how would I verify the signatures themselves? I'm kind of new to walking through trust paths. I don't even have any entry point too since nobody I know use public key encryption (I trust the Debian keys already though since I use their distro, maybe I can use that for a starting poin…
> Though they provide RSA and DSA signatures how would I verify the signatures themselves?
Ideally, it goes something like this --
1. Start with the master keys. Download them from their website & import them into your keyring.
2. Fetch signatures for those keys from some key servers. (E.g. gpg --recv-keys 6A93B34E).
3. Examine the signatures (E.g. gpg --list-sigs 6A93B34E). Do you trust anybody in that list to have verified the ownership of the keys?
If "yes", then import the release keys and verify that _they_ have been signed by the master keys. You can use the release keys to verify the downloaded binary.
If "no", then you might recurse down those keys to see if you know anyone who signed any of _them_. At this point, you'll need to consider very carefully what your trust policy is going to be.