33 ms·

Secure Secure Shell

478 points by padraic7a 12y ago

padraic7a 12y ago
Based on the Snowden documents and the fact[?] that the NSA can decrypt SSH at least some of the time the author advocates disabling some of the weak points of SSH. He also describes how to go about doing so.
- MichaelGG 12y ago
  Are there any facts on the NSA being able to decrypt SSH? All I saw was some Spiegel article where it showed the NSA had compromised some targets. But zero details, so it could have been as easy as a MITM and the user not verifying the public key. Or it could be an unknown exploit in the actual code. Everything I've heard so far points to the crypto being OK. That, so far, no special NSA crypto-defeating capabilities have come out. (Hence the NSA doodle with the smiley face on the links where Google removed TLS.) Of course the NSA might have magic powers, but nothing in the last few years suggests that possibility any more than we'd have thought before.
  - elsjaako 12y ago
    There was a powerpoint where they implied they could sometimes get around ssh protections. Most people assume it's not actually the protocol that's broken, but it seems like a good excuse to clean up ssh anyway.
akerl_ 12y ago
I'm a bit concerned at some of the leaps of logic made in this article. We're told to discount 1024 bit exchanges because of "unknown attacks". If they're unknown, why are we determining that 2048 bits is safe? How do we know the attacks aren't specifically against some other aspect? The guide talks about creating a newer stronger host key, but doesn't provide any information about preventing initial MITM there: ensuring you get the right host key on first connection is a major issue, and somebody trying to "make NSA analysts sad" ought to be explaining methods for ensuring that happens securely via host key CAs or similar tools. Likewise, the suggestion for "Preventing key theft" is "ven with forward secrecy the secret keys must be kept secret. The NSA has a database of stolen keys - you do not want your key there.". No insight is provided on how to actually accomplish that. This is certainly a way to turn off weaker ciphers and exchanges, but passing it off as a way to "make NSA analysts sad" is hyperbolic and runs the risk of people believing the hype.
- tptacek 12y ago
  We don't know exactly the design of a rig that would solve a 1024-bit discrete log or factoring problem, but we have a decent idea of what it would probably cost, and most VC firms could fund it. Costs don't scale linearly. No math projection puts 2048 bit keys in reach. The thing that breaks 2048 bit RSA may well put RSA completely out of action, a reason to prefer alternatives to RSA over 4096-bit keys.
  - akerl_ 12y ago
    Granted, but if that's the concern, that's what the article ought to be explaining: We are aware of the infrastructure to break 1024-bit discrete logs, and it's feasible; current projections put 2048 bit key safely out of reach for the time being, so we'll disable 1024 and leave 2048 enabled. My concern there is with the talk of 'unknown attacks' and then providing suggestions based on that statement.
  - mschuster91 12y ago
    > but we have a decent idea of what it would probably cost, and most VC firms could fund it. I'd wonder if a "CaaS" startup (Cracking as a service) would be feasible. Using amazon spot instances, it would require only as much funding as to serve the first ten users - and requiring each user to send the money to an escrow, e.g. a notary (in Germany, it's possible to deposit an amount at a notary, which gives the customer the assurance that without the private key, the company gets their money and the company has the assurance that the customer doesn't walk away with the keys and leaves the company with a 5-figure AWS bill).
- sarciszewski 12y ago
  Considering it's on github.io, you can make a pull request with recommended changes here: https://github.com/stribika/stribika.github.io https://github.com/stribika/stribika.github.io :P
- VLM 12y ago
  One interesting topic of semi-paranoia that hasn't been discussed is timing attacks. I'm not even implying its a realistic concern, but a timing attack could be imagined that works better with longer keys. So 1024 is run too fast to gather intel based on timing, but an imaginary 8192 bit key would run slowly enough to leak one random bit of key per session via timing analysis, as a physics-style thought experiment. Not trying to claim out that longer keys are weaker in reality, but am trying to make the point that being impervious to timing analysis attacks might be kinda important. Or another way to phrase it is there's more ways to break a key than pure math or torture.
Spooky23 12y ago
"Don't install what you don't need", but run Tor to connect to your servers via SSH. Huh? Hardening SSH makes a lot of sense and this article provoked a lot of thought. But there's too much political rant and leaps of faith for my taste. I'd like to hear some hardening guidance with more fact, less vitriol.
- drzaiusapelord 12y ago
  I can't imagine running a tor client on a production server and question its safety on my desktop (When I use it, I run up a disposable VM that gets wiped). So run software that connects you to the most hostile network out there and hope to god everything is secure on the client side of things? This is the problem with trying to fight the NSA or some other over-inflated bogeyman. If you focus on weird edge cases you lose sight of practical security. I'd be more worried about opening myself to tor than some theorized attack on ssh ciphers. Unfortunately, it seems network security has become fairly political, and if you don't make jabs at the NSA, while of course ignoring other state actors, then you won't be put on HN and reddit, which always welcomes politicized information at the cost of accuracy. I hope this hysteria is temporary and cooler heads will prevail and the Alex Jones listening crowd will stop holding the microphone.
  - resonantcore 12y ago
    > I'd be more worried about opening myself to tor than some theorized attack on ssh ciphers. Most of the attacks launched on Tor aren't in the "remote takeover of the tor server via memory corruption" category, they have (in recent history) mostly been in the form of: * Attack firefox.exe in Tor Browser Bundle * Control a lot of nodes, do something networky to discover the user's actual IP/location What is the threat you anticipate will result from "opening yourself to Tor"?
    - drzaiusapelord 12y ago
      Yes, these are the attacks we know of, and the first one only because the FBI told us so. I suspect Tor is a lot more targeted and dangerous than people assume and using it casually to administer servers is asinine.
tptacek 12y ago
It's possible that NSA can recover keys from 1024-bit RSA/DH/DSA handshakes, but it's extraordinarily unlikely that they can do so scalably; that would be an ability that currently qualifies as space-alien technology. RC4 is terribly broken and should be disabled. But the practical attack on RC4 requires many repetitions of the same plaintext --- "many" in the millions. This is a real threat to HTTPS/TLS, but not as much to RC4. Even hypothetical improvements to Fluhrer/McGrew would still require lots of repetitions. Disable RC4, but if you're playing along at home, this probably isn't it. No serious cryptographer seems to believe that the NIST curves are backdoored. Avoid them if you can; they suck for other reasons. MD5 is survivable in the HMAC construction.
- conformal 12y ago
  space-alien technology speculation aside, i've been aware of openssh's less-than-reassuring default selection order for Ciphers, HostKeyAlgorithms, KexAlgorithms and MACs for a few years. for most modern computers and cpus, using these stronger algos amounts to, at most, a 10% speed loss when scp'ing and a 10% increase in cpu usage. even machines with weaker cpus will barely show any signs of fatigue with these stronger algos. despite this, at least 2 of the openssh devs have rebuked my suggestion to change the default algorithm selection order. it's not exactly clear (to me) why anyone who runs a project that so many ppl depend on for security would stick to such old and crufty algos. since openssh and openbsd are intertwined, it does make me wonder if this is being done so that openssh can run on the latest vax, etc (omg! but it will take a week for it to generate the right sized keys!). EDIT: openssh in 2nd paragraph changed from openbsd, a typo.
  - jonawesomegreen 12y ago
    I feel like most of this is just because OpenSSH has been under development for 15 years rather than any conspiracy. Cryptography moves forward, new algorithms get added, but yet defaults don't get changed.
  - tedunangst 12y ago
    What's wrong with the current selection order?
zokier 12y ago
Instead of storing keys on a pendrive, consider using smart cards or some other crypto devices for that purpose. There are some tradeoffs involved, so research before acting.
jonawesomegreen 12y ago
I'm a little surprised that SSH authentication methods can't be easily disabled using the sshd_config file. Almost all the other security algorithms can be easily tweaked. I thought this article had just made a mistake, but I read over the man page and it appears there is indeed no way to modify this using the config file. This isn't a protocol weakness. Reading over the SSH RFCs, the server is allowed to specify which algorithms it supports, so this could easily be a OpenSSH configuration option.
- deleted 12y ago
  [deleted]
- deleted 12y ago
  [deleted]
- ZoFreX 12y ago
  I found this extremely concerning too. It should be possible to modify these options without resorting to hacks (that may break when OpenSSH is upgraded) _if_ these modifications are indeed necessary. From some of the comments here it's clear that this article is a mixture of good, bad, and silly advice - do those other authentication methods actually need disabling?
- jamoes 12y ago
  It looks like he's found a way to avoid using the broken symlinks hack. The blog has been updated and now advises how to make changes to the sshd_config file to disable old authentication methods.
dtech 12y ago
Unfortunately it seems that the latest version of PuTTY (0.63) does not support any of the advised MAC's.
- tedunangst 12y ago
  Putty supports hmac-sha1, which is more than fine.
- vacri 12y ago
  Unfortunately PuTTY still isn't served over https, even after all these years...
- vacri 12y ago
  Unfortunately PuTTY still isn't served over https, even after all these years. If you're concerned about esoteric MITM attacks, this is worth remembering...
  - rb12345 12y ago
    Considering that PuTTY has GPG signatures, there is no need for downloading it over HTTPS. Of course, this does leave the issue of how to obtain and confirm the right GPG key for verifying the download.
schizoidboy 12y ago
In the Symmetric ciphers section, it ends with "This leaves 5-9 and 15" but why are 2-4 bad (aes128-cbc, aes192-cbc, aes256-cbc)? It seems the argument is that GCM is better than CBC, and CTR is okay. My general impression is that CBC is preferred (for example, Rails uses AES-256-CBC by default in its MessageEncryptor class).
- desdiv 12y ago
  I think he eliminated them out of performance considerations. CBC is unparallelizeable by nature.
- wolf550e 12y ago
  CBC in TLS is bad and deprecated in (not yet released) TLS 1.3. AFAIK, CBC in general is not broken if you pad it properly and authenticate it properly, especially if you authenticate before decryption (which TLS does not do).
- sarciszewski 12y ago
  My understanding is that, in general, AEAD (such as GCM) > CTR >= CBC > [ a lot of modes ] > ECB CBC requires unpredictable IVs. CTR works with an integer starting at 0, so long as you never repeat. The author's motive for not eliminating CTR was stated as compatibility. If you ask me, just use chacha20-poly1305 if you can. If you can't, there are probably more important problems for you to deal with (i.e. upgrading your legacy systems).
  - dfox 12y ago
    When you are reusing symmetric keys, both CBC and CTR require unique IV (as do all reasonable block cipher modes).
    - sarciszewski 12y ago
      When you are reusing symmetric keys, both CBC and CTR require unique IV (as do all reasonable block cipher modes). Contrast to: CBC requires unpredictable IVs. and CTR works with an integer starting at 0, so long as you never repeat. http://dictionary.reference.com/browse/unique?s=t&path=/ http://dictionary.reference.com/browse/unique?s=t&path=/ http://dictionary.reference.com/browse/unpredictable?s=t&path=/ http://dictionary.reference.com/browse/unpredictable?s=t&pat... At no point did my statement make an error that was addressed by your reply.
mschuster91 12y ago
One thing bothers me: > Unfortunately, you can’t encrypt your server key and it must be always available, or else sshd won’t start. The only thing protecting it is OS access controls. That should be solvable with systemd and fuse - create an encrypting filesystem with a fixed key obtained from an USB pendrive, which is then ejected (so it would need a reboot to be enumerated again), and have the filesystem limit open() calls to the key file. It should not need more than one read call when openssh starts.
- mhurron 12y ago
  That actually makes setting up SELinux seem like the simpler route.
  - mschuster91 12y ago
    iirc SELinux can only restrict the process groups that are able to read the file, which doesn't help you in a remote code execution exploit inside openssh. The question is, is is possible to use the keys without having them in RAM any more?
    - falcolas 12y ago
      > which doesn't help you in a remote code execution exploit inside openssh To be fair, If it gets to the point where they are executing arbitrary code in the openssh process, your key is already compromised. SELinux would help with most other causes of key leaks, however. > The question is, is is possible to use the keys without having them in RAM any more? In my (albeit limited) experience, no. Even if only because context switching would push the key out of the CPU registers and into RAM if it occurred at the wrong time.
      - jamiesonbecker 12y ago
        > To be fair, If it gets to the point where they are executing arbitrary code in the openssh process, your key is already compromised. This. Exactly.
peterwwillis 12y ago
"Unfortunately, you can’t encrypt your server key and it must be always available, or else sshd won’t start. The only thing protecting it is OS access controls." You can encrypt the server key and only decrypt it into a loopback mount when you want to start sshd or accept a connection (I don't remember offhand if sshd reads it only once or at each connection), then unmount it. You get the same functionality as typing in your keystore password when you start apache or netscape or whatever web server (because you encrypt your https private keys too, right?). An untested poc: # making the image mkdir TMPFS mount -t tmpfs -o size=4m tmpfs TMPFS cd TMPFS dd if=/dev/zero of=servkeys.img bs=1m count=2 mkfs.ext2 -F -m 0 -t ext2 servkeys.img mkdir MOUNT mount -t ext2 -o loop servkeys.img MOUNT cp /etc/ssh/sshd_config MOUNT/ ssh-keygen -t rsa -b 4096 -f MOUNT/ssh_host_key umount MOUNT gpg -se servkeys.img mv servkeys.img.gpg .. cd .. umount TMPFS # running sshd mount -t tmpfs -o size=4m tmpfs TMPFS cd TMPFS gpg -d ../servkeys.img.gpg > servkeys.img mkdir MOUNT mount -t ext2 -o loop servkeys.img MOUNT sshd -f MOUNT/sshd_config -h MOUNT/ssh_host_key umount MOUNT cd .. umount TMPFS
- jamiesonbecker 12y ago
  By definition, it still has to be loaded in RAM, so this strategy is unfortunately moot.
  - peterwwillis 12y ago
    How is it any more moot than the private key loaded into RAM by your https server? It's still not on disk, and it's still more difficult to extract from memory than from the disk.
    - jamiesonbecker 12y ago
      Agreed, sshd is not any different from the key being loaded into RAM by your http server. But it's even easier and faster to grab a key from RAM. Could just use a debugger or a handy tool like aeskeyfinder or... https://github.com/mmozeiko/aes-finder https://github.com/mmozeiko/aes-finder (or another handy tool like heartbleed ;))
BlackFingolfin 12y ago
Looking at which key exchange protocols, HMACs etc. various other SSH implementations out there support, it seems that many of them would be barred from accessing a server hardened like that :/. In fact, it almost seems like the intersection of mutually supported protocols is empty resp. only contains known-to-be-unsafe ones... :(. Which makes me wonder: Is there anywhere a comprehensive comparison with tables that show which SSH clients (and servers) support which algorithms for key exchange, HMAC, etc.? That would help determining whom one is going to shut out by disabling which protocol, and thus help in making an informed decision on that. Of course, to be really useful, such a table would also need to take into account which version of each listed software added support for which protocol -- as it is, the OpenSSH shipped in e.g. Mac OS X 10.8 (5.9p1) does not support curve25519-sha256@libssh.org which the OP recommends... Sources: http://www.libssh2.org/ http://www.libssh2.org/ http://api.libssh.org/stable/ http://api.libssh.org/stable/ https://support.ssh.com/manuals/server-admin/44/Ciphers_and_MACs.html https://support.ssh.com/manuals/server-admin/44/Ciphers_and_... http://www.lysator.liu.se/~nisse/lsh/lsh.html http://www.lysator.liu.se/~nisse/lsh/lsh.html
- jamiesonbecker 12y ago
  This is a good idea. I'm thinking about adding functionality to the next version of Userify that will provide customization of ciphersuites (etc) on the sshd_config side. It'd be even cooler if it used just this sort of table.
  - BlackFingolfin 12y ago
    For fun, I started work on this. It's still rather crude, and the code is hackish, but anyway: Comparison page: http://ssh-comparison.quendi.de/comparison.html http://ssh-comparison.quendi.de/comparison.html Git repository: https://github.com/fingolfin/ssh-comparison https://github.com/fingolfin/ssh-comparison Improvements are highly welcome; not just adding more clients, but also on refactoring the code, improving the UI (I suck at HTML), adding features... The TODO already lists some ideas.
    - jamiesonbecker 12y ago
tedunangst 12y ago
> Some of the supported algorithms are not so great and should be disabled completely. If you leave them enabled but prefer secure algorithms, then a man in the middle might downgrade you to bad ones. How does that work? The algo exchange is authenticated too.
- lmm 12y ago
  How can it be? What algorithm could you possibly use to authenticate the part where you negotiate which authentication algorithm to use?
  - tedunangst 12y ago
    Itself. :) You could possibly force a weaker DH kex I think, but there's no way to force e.g., rc4 with hmac-md5. Disabling group1 is a pretty big interop hit, though.
bananaboydean 12y ago
Would'nt NSA attempts at cracking encryption systems basically be free audits on those encryption systems. (providing the public some how figures out how it was broken.)
- kej 12y ago
  If the public ever got to see the results, sure.
- orclev 12y ago
  Assuming they bothered to share the results of those attempts sure. The problem of course is that the NSA is both attempting, and in some cases succeeding in cracking encryption systems but keeping it all locked away behind security clearances. In the past we've learned quite a bit about the weaknesses of various crypto systems via post-mortems of NSA exploits, but it always comes well after the fact that the encryption is weak and broken has already become if not common knowledge than at least largely assumed. E.G. it's probably a safe bet that 1024 bit encryption is either broken by the NSA currently, or is likely to be broken soon, but it will probably be many years (barring another Snowden like event) before the public knows anything about exactly HOW the NSA has/will break it.
  - cnvogel 12y ago
    An extreme example for this kind of approach might be found in the history of the Enigma cipher and the British/Allied successful attempts in decryping German communications during the war. If it would have been obvious that information about an impeding attack could only have been gathered from intercepted and decrypted communications, the British would rather let boats be sunken and people die than give away the fact that the code had been broken. Because if the fact would be known, the adversary will immediately cease to use this method of encryption, rendering the advantage of breaking the cipher void.
    - TOMDM 12y ago
      As a small aside, for anyone interested in this, The Imitation game was in my opinion fantastic, though I assume anyone here would already have seen it, or have plans to.
minikites 12y ago
> Use free software: As in speech. You want to use code that’s actually reviewed or that you can review yourself. There is no way to achieve that without source code. Someone may have reviewed proprietary crap but who knows. Maybe this person forgot about Heartbleed? Or that Debian bug that was around for years? Or Shellshock, dating back to 1989? Stop pretending and assuming that just because software is open source that it is automatically reviewed.
- psycr 12y ago
  His claim is that it's necessary - not that it's sufficient.
- orclev 12y ago
  Open source doesn't mean it HAS been reviewed, it just means it CAN be reviewed. The same can not be said of closed source products. I rather trust the product that at least has the option of being reviewed by an independent source over one that you have no choice but to trust the creator of.
- snowwrestler 12y ago
  The reason you are able to use those as examples is because they were caught and mitigated. Open source doesn't magically prevent bugs. But it does ensure that when a bug is found, you'll hear about it and get a well-vetted fix pretty quickly.
exabrial 12y ago
It's possible the NSA doesn't give a shit about your shit too.
- jamiesonbecker 12y ago
  That sentiment is possibly wrong, too. The NSA's stated goal: Collect it all. http://www.theguardian.com/commentisfree/2013/jul/15/crux-nsa-collect-it-all http://www.theguardian.com/commentisfree/2013/jul/15/crux-ns...
  - exabrial 12y ago
    Yes, if it's on the gaurdian and snowden said it then it's got to be some sort of biblical truth. Or, there's the simpler explanation, like you're really fkin irrelevant in the grand scheme of things. Chances are, if they want your shit, they could just stop you for a traffic stop, incarcerate you, waterboard the shit out of you until you cried and gave up your 4096 bit RSA key so they could read your private journal about your sad paranoid life. These fkin ERMMGH NSA TAKIN YER SHIT articles are really stupid.
    - jamiesonbecker 12y ago
      http://www.washingtonpost.com/world/national-security/for-nsa-chief-terrorist-threat-drives-passion-to-collect-it-all/2013/07/14/3d26ef80-ea49-11e2-a301-ea5a8116d211_story.html http://www.washingtonpost.com/world/national-security/for-ns...
    - exo762 12y ago
      Yeah, my shit is irrelevant. My machine is not though. When attacking other, relevant systems, agency will always use infested low-key systems as a hop. Is this a valid reason to harden security of your machines? Yes, it is.
- Nanzikambe 12y ago
  From the slides leaked at 31c3 and by Der Spiegel that's not the case. They want everything. Even if you're not a target you're of interest -- either as a vector to a target.(someone you know, regardless how many "hops") some thing you have (information, or equipment/infrastructure as a proxy or platform for attack) Think of this example: you've ssh access coincidentally to a VPS on the same metal that coincidentally runs another VPS that belongs to a guy, who as a favour runs a totally separate server that hosts a "bad dude"(tm). Everybody in that chain and everybody connected to every one involved with the hardware are direct targets, all of their work colleagues are for the same reason. Now extend that up and down every technological stack and industry and you'll see how capricious the notion is. And if you're not a US citizen, you've no rights so who gives a shit? If you happen to be a US citizen, you've still no rights because the people targetting you will just be members of another Five Eyes organisation.
ouaibe 12y ago
FWIW, I have submitted a somewhat similar configuration as a pull request for ioerror's duraconf project at https://github.com/ioerror/duraconf/pull/52 https://github.com/ioerror/duraconf/pull/52. This project also hosts secure ciphersuite configurations for postfix, nginx, apache, GPG, etc.
deleted 12y ago
[deleted]
jamielinux 12y ago
The article states that host key authentication methods cannot be disabled. Instead of creating broken symlinks, you can actually specify this server-side in sshd_config (at least on CentOS 7): HostKey /etc/ssh/ssh_host_rsa_key You can also force this on the client-side in ~/.ssh/config: HostKeyAlgorithms ssh-rsa See man pages for defaults.
mightybyte 12y ago
This seems like a great idea. Unfortunately most of the recommendations seem to not be supported on my MacOS machine. Also, when I paired it down to the ones that are supported I wasn't able to connect to github. :( Very annoying.
- newman314 12y ago
  Agreed. And to add to it, even though Yosemite has OpenSSH 6.2p2, it has most of the newer features disabled. FWIW, this is what I have in my config file on Mac. Ciphers aes256-ctr,aes128-ctr MACs hmac-sha2-512,hmac-sha2-256,hmac-sha1
  - alwillis 12y ago
    See https://news.ycombinator.com/item?id=8849392 https://news.ycombinator.com/item?id=8849392 for how to safely upgrade Yosemite’s OpenSSH to 6.6p1.
- alwillis 12y ago
  OS X 10.10 Yosemite ships with OpenSSH_6.2p2. Use Homebrew [1] to install 6.6p1 with its bug fixes and enhancements: brew install openssh --with-brewed-openssl --with-keychain-support [1]http://brew.sh http://brew.sh Reference: How to Update OpenSSH on Mac OS X at http://www.dctrwatson.com/2013/07/how-to-update-openssh-on-mac-os-x/ http://www.dctrwatson.com/2013/07/how-to-update-openssh-on-m...
hrjet 12y ago
For the MAC, the article suggests an exception to github.com. But it looks like an exception is required for the Kex protocol as well. I see this error: Unable to negotiate a key exchange method If I understand correctly the response from ssh -v -v, github.com only supports the following Kex protocols: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss Edit: By trial and error, I find that this works for github.com: KexAlgorithms diffie-hellman-group1-sha1
- sadgit 12y ago
  Thanks!
- emilianoheyns 12y ago
  Doesn't the article suggest a KexAlgorithms exception rather than a MACs exception? I get the same error, but adding the above KexAlgorithms doesn't help
  - hrjet 12y ago
    The article seems to have been updated pretty heavily. We might have been looking at different versions. Here's the complete change log: https://github.com/stribika/stribika.github.io/commits/master/_posts/2015-01-04-secure-secure-shell.md https://github.com/stribika/stribika.github.io/commits/maste...
monokrome 12y ago
To say the least, the number of recommended options here which are not supported on the version of openssh which comes with OS X is disappointing.
- alwillis 12y ago
  https://news.ycombinator.com/item?id=8849392 https://news.ycombinator.com/item?id=8849392
dgulino 12y ago
"ssh-keygen -G /tmp/moduli -b 4096 ssh-keygen -T /etc/ssh/moduli -f /tmp/moduli This will take a while so continue while it’s running." First line has taken 6 hours on an ec2 t1.micro.
- alwillis 12y ago
  The second line took a little over 3 hours on my 5 year old MacBook Pro.
osxuserhere 12y ago
Hey All, OSX user here, i'm having trouble trying to replicate the config on my machine. Thusfar i've found, If you using a mac, things are slightly different, ie, /etc/ssh/ssh_config Is actually /etc/ssh_config /etc/ssh/sshd_config Is actually /etc/sshd_config /etc/ssh/moduli Is actually /private/etc/moduli That's as far as i can tell anyway. I'm not sure what to do when it comes to authentication however. I'm assuming that your supposed to be editing /etc/ssh_config/ however i don't know if i'm supposed to remote the '#' from any lines i'm editing? I also dont appear to have any files that i can find called ssh_host_rsa_key nor is there a 'HostKey' line in the ssh_config file. Any help would be most appreciated!
- richardwhiuk 12y ago
  ftr /etc on Mac and /private/etc are the same. It looks like the contents of /etc/ssh is in /etc on Mac OS X's SSH
destructaball 12y ago
Every now and again I step back and think of the absurdity of us having to take all of these precautions to stay safe from the people employed to represent our interests

478 points by padraic7a 12y ago

Based on the Snowden documents and the fact[?] that the NSA can decrypt SSH at least some of the time the author advocates disabling some of the weak points of SSH. He also describes how to go about doing so.

MichaelGG 12y ago
Are there any facts on the NSA being able to decrypt SSH? All I saw was some Spiegel article where it showed the NSA had compromised some targets. But zero details, so it could have been as easy as a MITM and the user not verifying the public key. Or it could be an unknown exploit in the actual code. Everything I've heard so far points to the crypto being OK. That, so far, no special NSA crypto-defeating capabilities have come out. (Hence the NSA doodle with the smiley face on the links where Google removed TLS.) Of course the NSA might have magic powers, but nothing in the last few years suggests that possibility any more than we'd have thought before.
- elsjaako 12y ago
  There was a powerpoint where they implied they could sometimes get around ssh protections. Most people assume it's not actually the protocol that's broken, but it seems like a good excuse to clean up ssh anyway.

akerl_ 12y ago

I'm a bit concerned at some of the leaps of logic made in this article. We're told to discount 1024 bit exchanges because of "unknown attacks". If they're unknown, why are we determining that 2048 bits is safe? How do we know the attacks aren't specifically against some other aspect? The guide talks about creating a newer stronger host key, but doesn't provide any information about preventing initial MITM there: ensuring you get the right host key on first connection is a major issue, and somebody trying to "make NSA analysts sad" ought to be explaining methods for ensuring that happens securely via host key CAs or similar tools. Likewise, the suggestion for "Preventing key theft" is "ven with forward secrecy the secret keys must be kept secret. The NSA has a database of stolen keys - you do not want your key there.". No insight is provided on how to actually accomplish that. This is certainly a way to turn off weaker ciphers and exchanges, but passing it off as a way to "make NSA analysts sad" is hyperbolic and runs the risk of people believing the hype.

tptacek 12y ago
We don't know exactly the design of a rig that would solve a 1024-bit discrete log or factoring problem, but we have a decent idea of what it would probably cost, and most VC firms could fund it. Costs don't scale linearly. No math projection puts 2048 bit keys in reach. The thing that breaks 2048 bit RSA may well put RSA completely out of action, a reason to prefer alternatives to RSA over 4096-bit keys.
- akerl_ 12y ago
  Granted, but if that's the concern, that's what the article ought to be explaining: We are aware of the infrastructure to break 1024-bit discrete logs, and it's feasible; current projections put 2048 bit key safely out of reach for the time being, so we'll disable 1024 and leave 2048 enabled. My concern there is with the talk of 'unknown attacks' and then providing suggestions based on that statement.
- mschuster91 12y ago
  > but we have a decent idea of what it would probably cost, and most VC firms could fund it. I'd wonder if a "CaaS" startup (Cracking as a service) would be feasible. Using amazon spot instances, it would require only as much funding as to serve the first ten users - and requiring each user to send the money to an escrow, e.g. a notary (in Germany, it's possible to deposit an amount at a notary, which gives the customer the assurance that without the private key, the company gets their money and the company has the assurance that the customer doesn't walk away with the keys and leaves the company with a 5-figure AWS bill).
sarciszewski 12y ago
Considering it's on github.io, you can make a pull request with recommended changes here: https://github.com/stribika/stribika.github.io https://github.com/stribika/stribika.github.io :P
VLM 12y ago
One interesting topic of semi-paranoia that hasn't been discussed is timing attacks. I'm not even implying its a realistic concern, but a timing attack could be imagined that works better with longer keys. So 1024 is run too fast to gather intel based on timing, but an imaginary 8192 bit key would run slowly enough to leak one random bit of key per session via timing analysis, as a physics-style thought experiment. Not trying to claim out that longer keys are weaker in reality, but am trying to make the point that being impervious to timing analysis attacks might be kinda important. Or another way to phrase it is there's more ways to break a key than pure math or torture.

Spooky23 12y ago

"Don't install what you don't need", but run Tor to connect to your servers via SSH. Huh? Hardening SSH makes a lot of sense and this article provoked a lot of thought. But there's too much political rant and leaps of faith for my taste. I'd like to hear some hardening guidance with more fact, less vitriol.

drzaiusapelord 12y ago
I can't imagine running a tor client on a production server and question its safety on my desktop (When I use it, I run up a disposable VM that gets wiped). So run software that connects you to the most hostile network out there and hope to god everything is secure on the client side of things? This is the problem with trying to fight the NSA or some other over-inflated bogeyman. If you focus on weird edge cases you lose sight of practical security. I'd be more worried about opening myself to tor than some theorized attack on ssh ciphers. Unfortunately, it seems network security has become fairly political, and if you don't make jabs at the NSA, while of course ignoring other state actors, then you won't be put on HN and reddit, which always welcomes politicized information at the cost of accuracy. I hope this hysteria is temporary and cooler heads will prevail and the Alex Jones listening crowd will stop holding the microphone.
- resonantcore 12y ago
  > I'd be more worried about opening myself to tor than some theorized attack on ssh ciphers. Most of the attacks launched on Tor aren't in the "remote takeover of the tor server via memory corruption" category, they have (in recent history) mostly been in the form of: * Attack firefox.exe in Tor Browser Bundle * Control a lot of nodes, do something networky to discover the user's actual IP/location What is the threat you anticipate will result from "opening yourself to Tor"?
  - drzaiusapelord 12y ago
    Yes, these are the attacks we know of, and the first one only because the FBI told us so. I suspect Tor is a lot more targeted and dangerous than people assume and using it casually to administer servers is asinine.

tptacek 12y ago

It's possible that NSA can recover keys from 1024-bit RSA/DH/DSA handshakes, but it's extraordinarily unlikely that they can do so scalably; that would be an ability that currently qualifies as space-alien technology. RC4 is terribly broken and should be disabled. But the practical attack on RC4 requires many repetitions of the same plaintext --- "many" in the millions. This is a real threat to HTTPS/TLS, but not as much to RC4. Even hypothetical improvements to Fluhrer/McGrew would still require lots of repetitions. Disable RC4, but if you're playing along at home, this probably isn't it. No serious cryptographer seems to believe that the NIST curves are backdoored. Avoid them if you can; they suck for other reasons. MD5 is survivable in the HMAC construction.

conformal 12y ago
space-alien technology speculation aside, i've been aware of openssh's less-than-reassuring default selection order for Ciphers, HostKeyAlgorithms, KexAlgorithms and MACs for a few years. for most modern computers and cpus, using these stronger algos amounts to, at most, a 10% speed loss when scp'ing and a 10% increase in cpu usage. even machines with weaker cpus will barely show any signs of fatigue with these stronger algos. despite this, at least 2 of the openssh devs have rebuked my suggestion to change the default algorithm selection order. it's not exactly clear (to me) why anyone who runs a project that so many ppl depend on for security would stick to such old and crufty algos. since openssh and openbsd are intertwined, it does make me wonder if this is being done so that openssh can run on the latest vax, etc (omg! but it will take a week for it to generate the right sized keys!). EDIT: openssh in 2nd paragraph changed from openbsd, a typo.
- jonawesomegreen 12y ago
  I feel like most of this is just because OpenSSH has been under development for 15 years rather than any conspiracy. Cryptography moves forward, new algorithms get added, but yet defaults don't get changed.
- tedunangst 12y ago
  What's wrong with the current selection order?

zokier 12y ago

Instead of storing keys on a pendrive, consider using smart cards or some other crypto devices for that purpose. There are some tradeoffs involved, so research before acting.

jonawesomegreen 12y ago

I'm a little surprised that SSH authentication methods can't be easily disabled using the sshd_config file. Almost all the other security algorithms can be easily tweaked. I thought this article had just made a mistake, but I read over the man page and it appears there is indeed no way to modify this using the config file. This isn't a protocol weakness. Reading over the SSH RFCs, the server is allowed to specify which algorithms it supports, so this could easily be a OpenSSH configuration option.

deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
ZoFreX 12y ago
I found this extremely concerning too. It should be possible to modify these options without resorting to hacks (that may break when OpenSSH is upgraded) _if_ these modifications are indeed necessary. From some of the comments here it's clear that this article is a mixture of good, bad, and silly advice - do those other authentication methods actually need disabling?
jamoes 12y ago
It looks like he's found a way to avoid using the broken symlinks hack. The blog has been updated and now advises how to make changes to the sshd_config file to disable old authentication methods.

dtech 12y ago

Unfortunately it seems that the latest version of PuTTY (0.63) does not support any of the advised MAC's.

tedunangst 12y ago
Putty supports hmac-sha1, which is more than fine.
vacri 12y ago
Unfortunately PuTTY still isn't served over https, even after all these years...
vacri 12y ago
Unfortunately PuTTY still isn't served over https, even after all these years. If you're concerned about esoteric MITM attacks, this is worth remembering...
- rb12345 12y ago
  Considering that PuTTY has GPG signatures, there is no need for downloading it over HTTPS. Of course, this does leave the issue of how to obtain and confirm the right GPG key for verifying the download.

schizoidboy 12y ago

In the Symmetric ciphers section, it ends with "This leaves 5-9 and 15" but why are 2-4 bad (aes128-cbc, aes192-cbc, aes256-cbc)? It seems the argument is that GCM is better than CBC, and CTR is okay. My general impression is that CBC is preferred (for example, Rails uses AES-256-CBC by default in its MessageEncryptor class).

desdiv 12y ago
I think he eliminated them out of performance considerations. CBC is unparallelizeable by nature.
wolf550e 12y ago
CBC in TLS is bad and deprecated in (not yet released) TLS 1.3. AFAIK, CBC in general is not broken if you pad it properly and authenticate it properly, especially if you authenticate before decryption (which TLS does not do).
sarciszewski 12y ago
My understanding is that, in general, AEAD (such as GCM) > CTR >= CBC > [ a lot of modes ] > ECB CBC requires unpredictable IVs. CTR works with an integer starting at 0, so long as you never repeat. The author's motive for not eliminating CTR was stated as compatibility. If you ask me, just use chacha20-poly1305 if you can. If you can't, there are probably more important problems for you to deal with (i.e. upgrading your legacy systems).
- dfox 12y ago
  When you are reusing symmetric keys, both CBC and CTR require unique IV (as do all reasonable block cipher modes).
  - sarciszewski 12y ago
    When you are reusing symmetric keys, both CBC and CTR require unique IV (as do all reasonable block cipher modes). Contrast to: CBC requires unpredictable IVs. and CTR works with an integer starting at 0, so long as you never repeat. http://dictionary.reference.com/browse/unique?s=t&path=/ http://dictionary.reference.com/browse/unique?s=t&path=/ http://dictionary.reference.com/browse/unpredictable?s=t&path=/ http://dictionary.reference.com/browse/unpredictable?s=t&pat... At no point did my statement make an error that was addressed by your reply.

mschuster91 12y ago

One thing bothers me: > Unfortunately, you can’t encrypt your server key and it must be always available, or else sshd won’t start. The only thing protecting it is OS access controls. That should be solvable with systemd and fuse - create an encrypting filesystem with a fixed key obtained from an USB pendrive, which is then ejected (so it would need a reboot to be enumerated again), and have the filesystem limit open() calls to the key file. It should not need more than one read call when openssh starts.

mhurron 12y ago
That actually makes setting up SELinux seem like the simpler route.
- mschuster91 12y ago
  iirc SELinux can only restrict the process groups that are able to read the file, which doesn't help you in a remote code execution exploit inside openssh. The question is, is is possible to use the keys without having them in RAM any more?
  - falcolas 12y ago
    > which doesn't help you in a remote code execution exploit inside openssh To be fair, If it gets to the point where they are executing arbitrary code in the openssh process, your key is already compromised. SELinux would help with most other causes of key leaks, however. > The question is, is is possible to use the keys without having them in RAM any more? In my (albeit limited) experience, no. Even if only because context switching would push the key out of the CPU registers and into RAM if it occurred at the wrong time.
    - jamiesonbecker 12y ago
      > To be fair, If it gets to the point where they are executing arbitrary code in the openssh process, your key is already compromised. This. Exactly.

peterwwillis 12y ago

"Unfortunately, you can’t encrypt your server key and it must be always available, or else sshd won’t start. The only thing protecting it is OS access controls." You can encrypt the server key and only decrypt it into a loopback mount when you want to start sshd or accept a connection (I don't remember offhand if sshd reads it only once or at each connection), then unmount it. You get the same functionality as typing in your keystore password when you start apache or netscape or whatever web server (because you encrypt your https private keys too, right?). An untested poc: # making the image mkdir TMPFS mount -t tmpfs -o size=4m tmpfs TMPFS cd TMPFS dd if=/dev/zero of=servkeys.img bs=1m count=2 mkfs.ext2 -F -m 0 -t ext2 servkeys.img mkdir MOUNT mount -t ext2 -o loop servkeys.img MOUNT cp /etc/ssh/sshd_config MOUNT/ ssh-keygen -t rsa -b 4096 -f MOUNT/ssh_host_key umount MOUNT gpg -se servkeys.img mv servkeys.img.gpg .. cd .. umount TMPFS # running sshd mount -t tmpfs -o size=4m tmpfs TMPFS cd TMPFS gpg -d ../servkeys.img.gpg > servkeys.img mkdir MOUNT mount -t ext2 -o loop servkeys.img MOUNT sshd -f MOUNT/sshd_config -h MOUNT/ssh_host_key umount MOUNT cd .. umount TMPFS

jamiesonbecker 12y ago
By definition, it still has to be loaded in RAM, so this strategy is unfortunately moot.
- peterwwillis 12y ago
  How is it any more moot than the private key loaded into RAM by your https server? It's still not on disk, and it's still more difficult to extract from memory than from the disk.
  - jamiesonbecker 12y ago
    Agreed, sshd is not any different from the key being loaded into RAM by your http server. But it's even easier and faster to grab a key from RAM. Could just use a debugger or a handy tool like aeskeyfinder or... https://github.com/mmozeiko/aes-finder https://github.com/mmozeiko/aes-finder (or another handy tool like heartbleed ;))

BlackFingolfin 12y ago

Looking at which key exchange protocols, HMACs etc. various other SSH implementations out there support, it seems that many of them would be barred from accessing a server hardened like that :/. In fact, it almost seems like the intersection of mutually supported protocols is empty resp. only contains known-to-be-unsafe ones... :(. Which makes me wonder: Is there anywhere a comprehensive comparison with tables that show which SSH clients (and servers) support which algorithms for key exchange, HMAC, etc.? That would help determining whom one is going to shut out by disabling which protocol, and thus help in making an informed decision on that. Of course, to be really useful, such a table would also need to take into account which version of each listed software added support for which protocol -- as it is, the OpenSSH shipped in e.g. Mac OS X 10.8 (5.9p1) does not support curve25519-sha256@libssh.org which the OP recommends... Sources: http://www.libssh2.org/ http://www.libssh2.org/ http://api.libssh.org/stable/ http://api.libssh.org/stable/ https://support.ssh.com/manuals/server-admin/44/Ciphers_and_MACs.html https://support.ssh.com/manuals/server-admin/44/Ciphers_and_... http://www.lysator.liu.se/~nisse/lsh/lsh.html http://www.lysator.liu.se/~nisse/lsh/lsh.html

jamiesonbecker 12y ago
This is a good idea. I'm thinking about adding functionality to the next version of Userify that will provide customization of ciphersuites (etc) on the sshd_config side. It'd be even cooler if it used just this sort of table.
- BlackFingolfin 12y ago
  For fun, I started work on this. It's still rather crude, and the code is hackish, but anyway: Comparison page: http://ssh-comparison.quendi.de/comparison.html http://ssh-comparison.quendi.de/comparison.html Git repository: https://github.com/fingolfin/ssh-comparison https://github.com/fingolfin/ssh-comparison Improvements are highly welcome; not just adding more clients, but also on refactoring the code, improving the UI (I suck at HTML), adding features... The TODO already lists some ideas.
  - jamiesonbecker 12y ago

tedunangst 12y ago

> Some of the supported algorithms are not so great and should be disabled completely. If you leave them enabled but prefer secure algorithms, then a man in the middle might downgrade you to bad ones. How does that work? The algo exchange is authenticated too.

lmm 12y ago
How can it be? What algorithm could you possibly use to authenticate the part where you negotiate which authentication algorithm to use?
- tedunangst 12y ago
  Itself. :) You could possibly force a weaker DH kex I think, but there's no way to force e.g., rc4 with hmac-md5. Disabling group1 is a pretty big interop hit, though.

bananaboydean 12y ago

Would'nt NSA attempts at cracking encryption systems basically be free audits on those encryption systems. (providing the public some how figures out how it was broken.)

kej 12y ago
If the public ever got to see the results, sure.
orclev 12y ago
Assuming they bothered to share the results of those attempts sure. The problem of course is that the NSA is both attempting, and in some cases succeeding in cracking encryption systems but keeping it all locked away behind security clearances. In the past we've learned quite a bit about the weaknesses of various crypto systems via post-mortems of NSA exploits, but it always comes well after the fact that the encryption is weak and broken has already become if not common knowledge than at least largely assumed. E.G. it's probably a safe bet that 1024 bit encryption is either broken by the NSA currently, or is likely to be broken soon, but it will probably be many years (barring another Snowden like event) before the public knows anything about exactly HOW the NSA has/will break it.
- cnvogel 12y ago
  An extreme example for this kind of approach might be found in the history of the Enigma cipher and the British/Allied successful attempts in decryping German communications during the war. If it would have been obvious that information about an impeding attack could only have been gathered from intercepted and decrypted communications, the British would rather let boats be sunken and people die than give away the fact that the code had been broken. Because if the fact would be known, the adversary will immediately cease to use this method of encryption, rendering the advantage of breaking the cipher void.
  - TOMDM 12y ago
    As a small aside, for anyone interested in this, The Imitation game was in my opinion fantastic, though I assume anyone here would already have seen it, or have plans to.

minikites 12y ago

> Use free software: As in speech. You want to use code that’s actually reviewed or that you can review yourself. There is no way to achieve that without source code. Someone may have reviewed proprietary crap but who knows. Maybe this person forgot about Heartbleed? Or that Debian bug that was around for years? Or Shellshock, dating back to 1989? Stop pretending and assuming that just because software is open source that it is automatically reviewed.

psycr 12y ago
His claim is that it's necessary - not that it's sufficient.
orclev 12y ago
Open source doesn't mean it HAS been reviewed, it just means it CAN be reviewed. The same can not be said of closed source products. I rather trust the product that at least has the option of being reviewed by an independent source over one that you have no choice but to trust the creator of.
snowwrestler 12y ago
The reason you are able to use those as examples is because they were caught and mitigated. Open source doesn't magically prevent bugs. But it does ensure that when a bug is found, you'll hear about it and get a well-vetted fix pretty quickly.

exabrial 12y ago

It's possible the NSA doesn't give a shit about your shit too.

jamiesonbecker 12y ago
That sentiment is possibly wrong, too. The NSA's stated goal: Collect it all. http://www.theguardian.com/commentisfree/2013/jul/15/crux-nsa-collect-it-all http://www.theguardian.com/commentisfree/2013/jul/15/crux-ns...
- exabrial 12y ago
  Yes, if it's on the gaurdian and snowden said it then it's got to be some sort of biblical truth. Or, there's the simpler explanation, like you're really fkin irrelevant in the grand scheme of things. Chances are, if they want your shit, they could just stop you for a traffic stop, incarcerate you, waterboard the shit out of you until you cried and gave up your 4096 bit RSA key so they could read your private journal about your sad paranoid life. These fkin ERMMGH NSA TAKIN YER SHIT articles are really stupid.
  - jamiesonbecker 12y ago
    http://www.washingtonpost.com/world/national-security/for-nsa-chief-terrorist-threat-drives-passion-to-collect-it-all/2013/07/14/3d26ef80-ea49-11e2-a301-ea5a8116d211_story.html http://www.washingtonpost.com/world/national-security/for-ns...
  - exo762 12y ago
    Yeah, my shit is irrelevant. My machine is not though. When attacking other, relevant systems, agency will always use infested low-key systems as a hop. Is this a valid reason to harden security of your machines? Yes, it is.
Nanzikambe 12y ago
From the slides leaked at 31c3 and by Der Spiegel that's not the case. They want everything. Even if you're not a target you're of interest -- either as a vector to a target.(someone you know, regardless how many "hops") some thing you have (information, or equipment/infrastructure as a proxy or platform for attack) Think of this example: you've ssh access coincidentally to a VPS on the same metal that coincidentally runs another VPS that belongs to a guy, who as a favour runs a totally separate server that hosts a "bad dude"(tm). Everybody in that chain and everybody connected to every one involved with the hardware are direct targets, all of their work colleagues are for the same reason. Now extend that up and down every technological stack and industry and you'll see how capricious the notion is. And if you're not a US citizen, you've no rights so who gives a shit? If you happen to be a US citizen, you've still no rights because the people targetting you will just be members of another Five Eyes organisation.

ouaibe 12y ago

FWIW, I have submitted a somewhat similar configuration as a pull request for ioerror's duraconf project at https://github.com/ioerror/duraconf/pull/52 https://github.com/ioerror/duraconf/pull/52. This project also hosts secure ciphersuite configurations for postfix, nginx, apache, GPG, etc.

deleted 12y ago

[deleted]

jamielinux 12y ago

The article states that host key authentication methods cannot be disabled. Instead of creating broken symlinks, you can actually specify this server-side in sshd_config (at least on CentOS 7): HostKey /etc/ssh/ssh_host_rsa_key You can also force this on the client-side in ~/.ssh/config: HostKeyAlgorithms ssh-rsa See man pages for defaults.

mightybyte 12y ago

This seems like a great idea. Unfortunately most of the recommendations seem to not be supported on my MacOS machine. Also, when I paired it down to the ones that are supported I wasn't able to connect to github. :( Very annoying.

newman314 12y ago
Agreed. And to add to it, even though Yosemite has OpenSSH 6.2p2, it has most of the newer features disabled. FWIW, this is what I have in my config file on Mac. Ciphers aes256-ctr,aes128-ctr MACs hmac-sha2-512,hmac-sha2-256,hmac-sha1
- alwillis 12y ago
  See https://news.ycombinator.com/item?id=8849392 https://news.ycombinator.com/item?id=8849392 for how to safely upgrade Yosemite’s OpenSSH to 6.6p1.
alwillis 12y ago
OS X 10.10 Yosemite ships with OpenSSH_6.2p2. Use Homebrew [1] to install 6.6p1 with its bug fixes and enhancements: brew install openssh --with-brewed-openssl --with-keychain-support [1]http://brew.sh http://brew.sh Reference: How to Update OpenSSH on Mac OS X at http://www.dctrwatson.com/2013/07/how-to-update-openssh-on-mac-os-x/ http://www.dctrwatson.com/2013/07/how-to-update-openssh-on-m...

hrjet 12y ago

For the MAC, the article suggests an exception to github.com. But it looks like an exception is required for the Kex protocol as well. I see this error: Unable to negotiate a key exchange method If I understand correctly the response from ssh -v -v, github.com only supports the following Kex protocols: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss Edit: By trial and error, I find that this works for github.com: KexAlgorithms diffie-hellman-group1-sha1

sadgit 12y ago
Thanks!
emilianoheyns 12y ago
Doesn't the article suggest a KexAlgorithms exception rather than a MACs exception? I get the same error, but adding the above KexAlgorithms doesn't help
- hrjet 12y ago
  The article seems to have been updated pretty heavily. We might have been looking at different versions. Here's the complete change log: https://github.com/stribika/stribika.github.io/commits/master/_posts/2015-01-04-secure-secure-shell.md https://github.com/stribika/stribika.github.io/commits/maste...

monokrome 12y ago

To say the least, the number of recommended options here which are not supported on the version of openssh which comes with OS X is disappointing.

alwillis 12y ago
https://news.ycombinator.com/item?id=8849392 https://news.ycombinator.com/item?id=8849392

dgulino 12y ago

"ssh-keygen -G /tmp/moduli -b 4096 ssh-keygen -T /etc/ssh/moduli -f /tmp/moduli This will take a while so continue while it’s running." First line has taken 6 hours on an ec2 t1.micro.

alwillis 12y ago
The second line took a little over 3 hours on my 5 year old MacBook Pro.

osxuserhere 12y ago

Hey All, OSX user here, i'm having trouble trying to replicate the config on my machine. Thusfar i've found, If you using a mac, things are slightly different, ie, /etc/ssh/ssh_config Is actually /etc/ssh_config /etc/ssh/sshd_config Is actually /etc/sshd_config /etc/ssh/moduli Is actually /private/etc/moduli That's as far as i can tell anyway. I'm not sure what to do when it comes to authentication however. I'm assuming that your supposed to be editing /etc/ssh_config/ however i don't know if i'm supposed to remote the '#' from any lines i'm editing? I also dont appear to have any files that i can find called ssh_host_rsa_key nor is there a 'HostKey' line in the ssh_config file. Any help would be most appreciated!

richardwhiuk 12y ago
ftr /etc on Mac and /private/etc are the same. It looks like the contents of /etc/ssh is in /etc on Mac OS X's SSH

destructaball 12y ago

Every now and again I step back and think of the absurdity of us having to take all of these precautions to stay safe from the people employed to represent our interests