I'm using an ssh 3.8.1p1 client on my home machine to connect to my an sshd 3.6.1p2 server on my office machine. Since I'm connecting over a VPN connection, I have no need for encryption. However, since my office machine does not run telnet/rlogin server, I can only connect to it using ssh. Thus, I need to turn off encryption while connecting. It seems I'm not able to do this with the '-c none' option. Here's the error I get when I run 'ssh -c none' to my office machine: No valid ciphers for protocol version 2 given, using defaults. The /etc/ssh/sshd_config file on my office machine does contain the following line: Ciphers aes128-cbc,blowfish-cbc,3des-cbc,cast128-cbc,none2 However, the ssh 3.8.1p1 client doesn't seem to recognize the cipher 'none2'. This is confirmed by looking at the openssh source in the file cipher.c. There is no cipher called "none2" in 3.8.1p1 source while it exists in 3.6.1p2 source. So I guess there are two problems: (1) ssh 3.8.1p1 client isn't able to disable encryption when talking to a 3.6.1p2 sshd which allows the none2 cipher. (2) The man page for ssh 3.8.1p1 doesn't indicate an option '-c none' while the man page for ssh 3.6.1p2 does. I hope the ability to open an unencrypted ssh channel hasn't been removed by the developers in the later version of ssh.
There is no "none2" cipher in 3.6.1p2, perhaps it was added by your vendor? $ cd openssh-cvs $ cvs up -dP -r V_3_6_1_P2 $ grep none2 * $
It indeed looks like my company's sysadmins added a way to support unencrypted ssh connections. Looking at the code in cipher.c, it seems it is relatively simple to support the "none" cipher even for SSH2. I'd strongly suggest that future versions of openssh support a method whereby encryption can be disabled. This bug gives an example of a situation where I don't encryption - I'm using a VPN connection that does the encryption for me.
it's unlikely that "none" will ever be supported. use "arcfour" instead.
My company went out of the way to add the "none" support to ssh. And I'm seeing postings on comp.security.ssh where several people have asked for this feature. So why is there a resistance to support the "none" cipher ? I've given a valid reason too - I don't want to increase overhead with encryption (specially over a VPN channel that itself does encryption) - I'm using ssh to compress the data being sent to the X server. Even so, the responsiveness of the X server is not too good. It'll help if openssh were to provide an unencrypted channel.
The whole point behind SSH protocol is not to leak sensitive information and to stop MITM attacks. Where the second may not be an issue with ssh2 protocol due to the HMAC usage, but I still have to ask why would one want to throw away the security around private information? Even if you encrypt authentification aspect of SSHv2 and left the sesson in clear text you still could leak information when you connect to other machines or using 'su' or 'sudo' to upgrade your security. I think it is better if you believe that your machines can't handle encryption is to test the preformance to find a lowest cpu power encryption or buy a few encryptor cards to put into heavily used machines. - Ben
*** Bug 878 has been marked as a duplicate of this bug. ***
My bug was marked a duplicate of this one - so I'm adding in my opinion. First, this is a matter of separation of policy and mechanism. Openssh should provide the mechanisms - in this case the "none" cipher - and the policy of whether or not to use it should be left to the user. This much is standard systems practice. Mohit has already given one situation where encryption is undesirable - the data is already being encrypted by the VPN. Over such a connection, Ben's concerns related to leaking data with unencrypted ssh channel doesn't apply. What openssh can do is to disable the "none" cipher in sshd by default. Let the sysadmins explicitly add "none" as one of the acceptable ciphers in /etc/ssh/sshd_config. That way the policy will be left to the administrators with reasonable defaults. Another safeguard might be to throw a warning message in the ssh client when the "none" cipher is being used. But I firmly believe the mechanism still needs to be supported. In the absence of the "none" cipher, companies are themselves hacking the openssh code to provide support for it. This is obviously undesirable as doing so might cause other unexpected bugs to creep in.
Here is a posting made by Richard Silverman on comp.security.ssh that makes several good points in support of this bug: BU> ??? What is the point of using ssh or scp without a cypher? Just BU> use ftp, or rcp or whatever. It is NOT secure. This point of view is much too simplistic; a connection is not just "secure" or "not secure" as if flipping a light switch. An SSH-2 connection using a null encryption cipher still has: - server authentication and man-in-the-middle attack protection (i.e. you know who you're talking to) - cryptographically assured integrity protection (i.e. you know the data is passed unchanged from one end to the other) - strong client authentication (assuming obvious mistakes aren't made, such as using password authentication over an unencrypted connection -- most implementations disallow this) So, if you don't care about privacy, but do care about these other properties, then using SSH with a null encryption cipher makes perfect sense. Similar motivations are behind the existence of AH mode in IPSec as well as ESP. In particular, it makes *no* sense to compare unencrypted SSH with "FTP, or rcp, or whatever;" these are entirely different.
> The whole point behind SSH protocol is not to leak sensitive information > and to stop MITM attacks. As my previous posting quoting Richard Silverman points out, these are not the only reasons for using ssh. Another reason (adding to the list by Richard) is to use compression. Very useful when forwarding X connections over the Internet. Again when done over VPN, the encryption from ssh is just an unnecessary overhead.
You aren't listening. The symmetric crypto is not the bottleneck: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes rc4 72846.67k 82979.15k 87698.53k 91231.05k 88004.03k hmac(md5) 2272.39k 8280.19k 28745.41k 71355.13k 120523.95k See: the per-packet MAC is an order of magnitude slower than the symmetric crypto. The MAC is always included, even with Cipher=none. There is no point in supporting Cipher=none if all you are doing is introducing new risks without improving performance.
The "none" cipher is listed in the draft protocol spec as "OPTIONAL/NOT RECOMMENDED". It's also worth noting that the "none" cipher has been the source of at least one security problem (in SSH 1.2.x): http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-1010
> The "none" cipher is listed in the draft protocol spec as "OPTIONAL/NOT > RECOMMENDED". The draft obviously doesn't consider situations where encryption is unnecessary (e.g. a VPN connection). The decision on whether to use or not use the none cipher should be left to the user (or the sysadmin who sets the policy on sshd) - currently its been forced on both. > It's also worth noting that the "none" cipher has been the source of at least > one security problem (in SSH 1.2.x): > http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-1010 If the sshd daemon allows the none cipher even when the sysadmin configures it not to, that's not the fault of the none cipher - that's a bug in the implementation.
> See: the per-packet MAC is an order of magnitude slower than the symmetric > crypto. The MAC is always included, even with Cipher=none. This is not true. A look in the data integrity section in: http://www.openssh.com/txt/draft-ietf-secsh-transport-14.txt shows that the MAC is also optional. If one is using ssh on a VPN connection, it is quite reasonable to get rid of the ovhds of both the encryption as well as the MAC. An example again is when one is forwarding X connections using ssh over a VPN connection.
> If the sshd daemon allows the none cipher even when the sysadmin configures > it not to, that's not the fault of the none cipher - that's a bug in the > implementation. Precisely! You do not have implementation bugs in features you do not implement. > draft-ietf-secsh-transport-14.txt shows that the MAC is also optional. ... and that the "none" MAC is "NOT RECOMMENDED". Also: you mention that you're using a VPN: are you sure there are no sniffers between the VPN concentrator and the SSH server? A significant portion of attacks are "inside jobs". Anyway, have you *measured* a difference? I get wire speed on my long-obsolete 170MHz SparcStation on its 10Mbit/s segment: $ scp -o MACs=hmac-md5-96 -o Ciphers=arcfour linux-2.5.0.tar.bz2 platypus:/tmp/ linux-2.5.0.tar.bz2 100% 23MB 1.0MB/s 00:23 The CPU is not saturated (and more CPU is spent on network IO than crypto: CPU states: 22.3% idle, 38.4% user, 39.4% kernel, 0.0% iowait, 0.0% swap)
Running ssh protocol 2 without a MAC renders sessions vulnerable to active as well as passive attacks. Therefore, the chances of us implementing the "none" MAC are even less than that of the "none" cipher. Feel free to patch your own OpenSSH distribution, but don't say we didn't warn you.
> Precisely! You do not have implementation bugs in features you do not > implement. But you can always also have bugs in features that you do implement and that compromise security. Not implementing a feature for fear of bugs is hardly an argument. > Also: you mention that you're using a VPN: are you sure there are no sniffers > between the VPN concentrator and the SSH server? A significant portion of > attacks are "inside jobs". There might be. By choosing the none cipher, the user has explicitly indicated that privacy is not of concern here - e.g. he might be simply doing an scp of some huge binary log from his home to his office machine. Doesn't matter if anyone is able to sniff out the data on the inside. Leave the choice to the user - don't force it on him. > Anyway, have you *measured* a difference? I get wire speed on my > long-obsolete 170MHz SparcStation on its 10Mbit/s segment: > > $ scp -o MACs=hmac-md5-96 -o Ciphers=arcfour linux-2.5.0.tar.bz2 platypus:/tmp/ > linux-2.5.0.tar.bz2 100% 23MB 1.0MB/s 00:23 > > The CPU is not saturated (and more CPU is spent on network IO than crypto: > CPU states: 22.3% idle, 38.4% user, 39.4% kernel, 0.0% iowait, 0.0% swap) 10 Mbps networks hardly imposed any ovhd on the CPUs - my company is starting to use 1 Gbps networks - there the ovhd can be significant. Also Solaris has a high ovhd network stack - even though you're doing considerable work at user level, the kernel still comes out having high ovhd. Try a Linux/BSD stack instead.
> Running ssh protocol 2 without a MAC renders sessions vulnerable to active as > well as passive attacks. > > Therefore, the chances of us implementing the "none" MAC are even less than that > of the "none" cipher. Feel free to patch your own OpenSSH distribution, but > don't say we didn't warn you. I cannot force your hand of course. But I again feel that these are policy decisions that should be left to the user. If a user chooses Mac=none, he obviously should be aware of the security risks. If his environment permits those (e.g. over VPN and transferring public data), openssh should allow him to turn off the cipher/mac and get higher performance. These days ssh seems to have completely replaced rsh/telnet - why run rsh/telnet when you have ssh that gives you many more features such as compression, port forwarding, security etc. Unfortunately, it seems there's no way for the user to achieve higher performance when security is not required. People are ending up patching their ssh distributions - which is very risky compared to the developers themselves providing the option. If people are really opposed to providng cipher=none and mac=none options, is it possible to provide an option to the "configure" command so that these options can be put in when the build is appropriately configured ? E.g. a build made after running "./configure --support-plain-text" should make appropriate ssh/sshd binaries where the cipher/mac can be turned off. That way people like me can at least make builds appropriately without the need to start hacking into the code.
> I cannot force your hand of course. But I again feel that these are policy > decisions that should be left to the user. If a user chooses Mac=none, he > obviously should be aware of the security risks. Problem is most don't understand. Just like most kids that find guns don't always understand that pulling the trigger causes it to fire. Why would we want to endanger our users any more than we have to? And like aways it is "never the user's fault".. It has to be the software and programmer. Even if they are abusing the software in a way it was never designed to be used in. <shrug> My view is if a company wants to hack mac=none, ciphers=none into their SSH code. That's fine. Not as if it is that hard or complex. However, if they are now taking that risk into their hands, and can't blame us for not thinking through how they use the feature. > If people are really opposed to providng cipher=none and mac=none options, > is it possible to provide an option to the "configure" command so that these > options can be put in when the build is appropriately configured ? Which I strongly object to. Either code should be used or not be included. Having additional code paths that are not compiled by default only adds more complexity to testing and platform verification. Plus it litters the source code with #ifdef/#endif garbage that makes it harder to read and understand. It's bad enough we have to test compile for PAM, KRB, and other oddball platform security configurations that affect how the code acts and reacts to configuration files and other user input. > 10 Mbps networks hardly imposed any ovhd on the CPUs - my company is starting > to use 1 Gbps networks - there the ovhd can be significant. Sounds like you really want to invest in encryption hardware. Sokeris group sells a nice PCI/PCMCIA solution that runs under BSD/Linux for a very nice price. I've seen a few gigabit cards with encryption chips right on it. Which would be another good path to look at. That would make more pratical sense than gutting security from an application.
> Problem is most don't understand. Just like most kids that find guns don't > always understand that pulling the trigger causes it to fire. Why would we > want to endanger our users any more than we have to? And like aways it is > "never the user's fault".. It has to be the software and programmer. Even > if they are abusing the software in a way it was never designed to be used in. A naive user can be protected in the following ways: (1) having the command line options "-o Cipher=none" and "-o Mac=none" are arcane enough that most ordinary users won't know about them - finding them out would require reading documentation which would give then sufficient warnings, (2) these options would only work if the sshd allows them - thus a naive user won't be able to shoot oneself unless the system administrator explicitly permits these. > My view is if a company wants to hack mac=none, ciphers=none into their > SSH code. That's fine. Not as if it is that hard or complex. However, if they > are now taking that risk into their hands, and can't blame us for not thinking > through how they use the feature. Why would someone ever blame the developers if they're providing sufficient warnings both in the code and documentation and if the defaults do not allow this unsecure mode. And I've seen the changes that our own administrators have made to support Cipher=none - they are easy once you know where to put them. Learning where to put them is what takes the time. If one does it incorrectly, there is always the danger of introducing bugs - e.g. even making initial user authentication unsecure. If a feature is being widely requested (and this one I believe is), its the developers who're most qualified to provide the appropriate changes to the code. > > If people are really opposed to providng cipher=none and mac=none options, > > is it possible to provide an option to the "configure" command so that these > > options can be put in when the build is appropriately configured ? > > Which I strongly object to. Either code should be used or not be included. > Having additional code paths that are not compiled by default only adds more > complexity to testing and platform verification. By eliminating all ways of having a ssh channel without encryption, you're hurting seasoned users who know what they're doing. And a seasoned user may not be competent enough to actually go change the openssh code to remove encryption. > Plus it litters the source code with #ifdef/#endif garbage that makes it > harder to read and understand. It doesn't have to be done using #ifdef/#endif. Even when used, they can be restricted to some header file. Anyways, code complexity is hardly a reason to justify not providing a widely requested feature.
> My view is if a company wants to hack mac=none, ciphers=none into their > SSH code. That's fine. Not as if it is that hard or complex. I took a look at the way my own sysadmins have added the "-c none". Seems like they've had to add a "none2" for SSH2 (as I mentioned in my initial posting) to get around the fact that "ciphers" in "cipher.c" already contains a "none" for SSH1. Looks pretty arcane to me. The sysadmins probably wanted to minimize code changes. Had the developers supported a "none" in SSH2, that would have been a much better job. In addition, I don't see support for a "hmac=none" in our code - possibly they didn't realize that hmac also eats away the performance. So having users do these code changes is certainly far from optimal. > > 10 Mbps networks hardly imposed any ovhd on the CPUs - my company is > > starting to use 1 Gbps networks - there the ovhd can be significant. > > Sounds like you really want to invest in encryption hardware. Sokeris group > sells a nice PCI/PCMCIA solution that runs under BSD/Linux for a very nice > price. I've seen a few gigabit cards with encryption chips right on it. > Which would be another good path to look at. That would make more pratical > sense than gutting security from an application. I thought ssh encryption works at user-level - how would having encryption in the network cards help ? It might help for VPNs where the IPsec resides in the kernel. Anyhow, with tight IT budgets these days, a solution that requires expensive hardware for hundreds of machines is not viable.
> 10 Mbps networks hardly imposed any ovhd on the CPUs - my company is starting > to use 1 Gbps networks - there the ovhd can be significant. The overhead also is dependant on how you've setup your GigE network. Most OSes and network devices are pretty configurable and you can really mitigate the effects of the NIC overhead in your boxes. GigE flow-control is also a must in any higher-traffic GigE network. I'm pushing 990mbps in testing with very low CPU overhead on Linux through a variety of tuning practices. However the added bulk of encryption traffic on the network is going to be negligible and realistically the encryption overhead in the CPU shouldn't be that much of a resource starvation to your machines. If it is, then you're in a business-case ROI for upgrading or replacing H/W based on your needs. Or changing your usage on the boxes (i.e. use something unencrypted like telnet).
1) how much faster is "none" compared to "arcfour"? 2) not having "none" makes it harder for people to send plaintext by accident 3) you still have to use integrity protection 4) it's too easy to screw up the ipsec setup 5) sshd cannot tell whether the connection is protected by ipsec.
> The overhead also is dependant on how you've setup your GigE network. Most > OSes and network devices are pretty configurable and you can really mitigate > the effects of the NIC overhead in your boxes. GigE flow-control is also a > must in any higher-traffic GigE network. I'm pushing 990mbps in testing with > very low CPU overhead on Linux through a variety of tuning practices. Darren Tucker was trying to make the point that kernel ovhd was higher than encryption based ovhds at user-level. All I'm trying to say is that he should try on recent hardware/software. One reason why earlier kernels had higher ovhd in the network stacks was because the tcp checksumming was done in software. These days Gigabit cards offload it to the NIC. Today it is highly unlikely that ssh over Gigabit would show higher ovhd in the kernel than at user-level if the encryption is done in user-level software. It is possible to offload this user-level software encryption to a special hardware device, but such hardware devices are not the norm.
> 1) how much faster is "none" compared to "arcfour"? You guys have the numbers - as long as its faster I want to use it. Like I said its painful forwarding X over the Internet, I'd like to get as much performance as I can. > 2) not having "none" makes it harder for people to send plaintext by accident Not having "none" makes it impossible for everyone to send plaintext - this hurts people who know what they are doing. > 3) you still have to use integrity protection Not in situations where its not needed. If I'm transferring a data file containing a public domain rpm, I'm happy with the integrity that tcp checksumming offers. > 4) it's too easy to screw up the ipsec setup Are you saying its too easy to compromise IPsec security ? As long as I trust the security offered by my VPN, I want to use plaintext ssh channels over it. > 5) sshd cannot tell whether the connection is protected by ipsec. So should sshd enforce security even when connection IS protected by ipsec ? I think not - that decision should be left to the user.
How can the user tell that the traffic is still IPsec protected? IPsec is per packet, and after flushing SAs the connection might be unprotected. How can SSH tell? Please show me how much faster none is. here's a patch: folly% cat dontuse.dif Index: cipher.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/cipher.c,v retrieving revision 1.66 diff -u -r1.66 cipher.c --- cipher.c 10 Nov 2003 16:23:41 -0000 1.66 +++ cipher.c 19 Nov 2003 18:01:04 -0000 @@ -60,11 +60,12 @@ u_int key_len; const EVP_CIPHER *(*evptype)(void); } ciphers[] = { - { "none", SSH_CIPHER_NONE, 8, 0, EVP_enc_null }, + { "none1", SSH_CIPHER_NONE, 8, 0, EVP_enc_null }, { "des", SSH_CIPHER_DES, 8, 8, EVP_des_cbc }, { "3des", SSH_CIPHER_3DES, 8, 16, evp_ssh1_3des }, { "blowfish", SSH_CIPHER_BLOWFISH, 8, 32, evp_ssh1_bf }, + { "none", SSH_CIPHER_SSH2, 8, 0, EVP_enc_null }, { "3des-cbc", SSH_CIPHER_SSH2, 8, 24, EVP_des_ede3_cbc }, { "blowfish-cbc", SSH_CIPHER_SSH2, 8, 16, EVP_bf_cbc }, { "cast128-cbc", SSH_CIPHER_SSH2, 8, 16, EVP_cast5_cbc }, Index: mac.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/mac.c,v retrieving revision 1.6 diff -u -r1.6 mac.c --- mac.c 18 Sep 2003 13:02:21 -0000 1.6 +++ mac.c 19 Nov 2003 18:01:04 -0000 @@ -45,6 +45,7 @@ { "hmac-md5-96", EVP_md5, 96 }, { "hmac-ripemd160", EVP_ripemd160, 0 }, { "hmac-ripemd160@openssh.com", EVP_ripemd160, 0 }, + { "none", EVP_md_null, 0 }, { NULL, NULL, 0 } }; folly%
The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 23000.94k 86595.78k 261084.63k 500813.38k 696327.46k BTW, this is what you'll get with a cheap Via C3 CPU (the CPU does AES).
> How can the user tell that the traffic is still IPsec protected? > IPsec is per packet, and after flushing SAs the connection > might be unprotected. How can SSH tell? (1) In some cases, e.g. transferring a large file available publically, it is always ok to do the transfer in plaintext. (2) If security beyond the VPN concentrators is of concern, the sysadmins can refrain from allowing the "none" cipher on sshd. (3) Ultimately, the judgement should lie with the user. When he uses "-c none" he understands the associated security risks. Users should control the policy. A seasoned user can then effectively use it to his/her advantage. (4) Naive users would be protected if the defaults are reasonable and the option to do "none" is arcane and possibly not listed in the manpage. (Even the cipher arcfour is not listed in the manpage for ssh). I'll try getting the performance results you asked for later today.
no, with IPsec the user _cannot_ tell if the data is actually protected. however, with SSH he can. (and there is no standard API, so SSH cannot figure out if the TCP session is IPsec protected).
arcfour is documented in the manpage. and we won't add undocumented things.
> arcfour is documented in the manpage. > > and we won't add undocumented things. Arcfour is - but Aes isn't (at least not in the man page for ssh). Neither is rijndael.
ssh_config.5 is very clear: > Ciphers > Specifies the ciphers allowed for protocol version 2 in order of > preference. Multiple ciphers must be comma-separated. The de- > fault is > > ``aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, > aes192-cbc,aes256-cbc''
In addition to DJM'scomment... Rijndael it is the same as aes. It's there for historical reason and sometime down the road it will go away. - Ben
> ssh_config.5 is very clear: How is it clear ? Should one assume that the default implies these are all the ciphers ssh supports ? ssh.1 doesn't talk about aes at all. In fact the ciphers available with the "-c" option are simply blowfish, 3des, and des.
> Rijndael it is the same as aes. It's there for historical reason and sometime > down the road it will go away. My point is that it has been added and is undocumented. So is aes.
> no, with IPsec the user _cannot_ tell if the data is actually protected. > however, with SSH he can. The application cannot. The user can - if I've setup a VPN connection between my home and office, I know the data is protected when its going to be sent over it. For this reason, it is the user who is best suited for decided whether he needs an unencrypted connection with ssh. And then there are situations where one can use unencrypted ssh even over vanilla Internet - e.g. when transferring public domain software.
> (2) If security beyond the VPN concentrators is of concern, the sysadmins > can refrain from allowing the "none" cipher on sshd. How do you know when you are beyond a VPN perimeter? How do you know some routing screwup isn't exposing your traffic? How do you know some malicious insider isn't sniffing? How do you know that the user won't forget that the channel is not encrypted and accidentally type a root password into "su"? > (3) Ultimately, the judgement should lie with the user. When he uses "-c none" > he understands the associated security risks. Users should control the > policy. A seasoned user can then effectively use it to his/her advantage. > > (4) Naive users would be protected if the defaults are reasonable and > the option to do "none" is arcane and possibly not listed in the manpage. > (Even the cipher arcfour is not listed in the manpage for ssh). A non-naive user can patch their OpenSSH installation. I believe that is a much more appropriate demonstration of their competence and their acceptance of the consequent risk.
> How do you know when you are beyond a VPN perimeter? How do you know some > routing screwup isn't exposing your traffic? How do you know some malicious > insider isn't sniffing? How do you know that the user won't forget that the > channel is not encrypted and accidentally type a root password into "su"? How do you know the user won't forget he's logged in using 'telnet' and then type a root password into "su" ? The idea is to make it difficult for anyone to use the unsecure mode, but at least permit it for people who really want to.
> A non-naive user can patch their OpenSSH installation. I believe that is a much > more appropriate demonstration of their competence and their acceptance of the > consequent risk. That is not easy - and it requires one to learn the code. The developers should consider including the relevant code and only enabling it when something like "./configure --support-plain-text" is used while doing the build.
> That is not easy That is the point
> That is the point What's your objection with providing a means to allow this via "configure" at build time ? Letting people unfamiliar with the code mess with it is too risky.
> What's your objection with providing a means to allow this via "configure" at > build time ? configure options are bad. More choices = more conditional code = more paths to test = more bugs = more work for us > Letting people unfamiliar with the code mess with it is too risky. Then they shouldn't do it, that is the point. We don't want users to use "none" because we think it is an unacceptable tradeoff. Others may disagree, but it is up to them to enable it if they are congnisant of the risks.
Based on the crap most Linux distros do to packages. I can almost assure you that they would enabled it by default if there was a configure option. Thus the end users have access to it without having to think, and thus people using a feature without understanding what drawbacks. Don't believe me? Start digging through some of the *.src.rpm for most distros and you'll get sick pretty quick by all the stuff they do because they feel it is "required". When in fact it is not. - Ben
Based on the patch that Markus had posted for implementing the "none" cipher and mac, here is some data I've collected. I did a transfer of 4 MB from my office machine to my home machine. The transfer was done using scp over a VPN connection established between my home and office machine. I did several transfers, varying the cipher and mac for each one. Each transfer was able to saturate the bandwidth available to me at the time (by my Comcast broadband connection) of about 110 KBps. Thus, what's relevant is the CPU ovhd. My home machine is a 800 MHz IBM T21 thinkpad running cygwin over Windows 2000, while my office machine is a fancy 2.7 GHz machine running Redhat 9. Here is the data from my home machine when the transfers were done (CPU was consistently 82% idle when no transfer is being done): Cipher MAC CPU idle default default 55% arcfour default 60% arcfour none 60% none default 65% none none 65% So it appears that disabling the MAC isn't giving me any benefits - or else the patch doesn't quite disable the MAC.
QED
Another experiment I did measured the latency. Basically I wrote a tcp client and server program that sent a packet to each other in a ping-pong fashion. I did 1000 of these ping pongs, and then computed the avg time for a ping pong. The ping-pong was done over a channel forwarded using ssh. By choosing different cipher/macs, I was able to compute the additional latency due to these options. The setup is the same as that I posted above, with my laptop at home as the client. Each packet that was sent was 128 bytes. Cipher Mac Avg ping-pong latency (msec) default default 44.90 arcfour default 43.68 arcfour none 42.71 none default 41.87 none none 41.08 Based on these results, I see a 10% improvement in latency - can be significant if X is getting forwarded over an ssh connection.
> QED Notice that it doesn't appear that MACs=none is working with this patch. A previous posting mentioned that that is a substantial cause of ovhd.
> Based on these results, I see a 10% improvement in latency - can be > significant if X is getting forwarded over an ssh connection. If would be if the absolute difference wasn't only 3ms - that well below the threshold of perception. > Notice that it doesn't appear that MACs=none is working with this patch. A > previous posting mentioned that that is a substantial cause of ovhd. No, it just demonstrates that the bottleneck for most practical applications isn't the crypto (which is what we have been saying all along) BTW you are measuring the absolute wrong thing anyway - the only case where removal of crypto would have a benefit is high-throughput, low-latency, private LANs.
You can use ssh -v to verify the cipher, MAC and compression negotiated. Look for a line like: debug1: kex: server->client aes128-cbc hmac-md5 zlib debug1: kex: client->server aes128-cbc hmac-md5 zlib
Mohit Aron wrote: > > Rijndael it is the same as aes. It's there for historical reason and > > sometime down the road it will go away. > My point is that it has been added and is undocumented. So is aes. Your point about AES is a good one, and the man pages (ssh_config and sshd_config) have now been updated. Rijndael is not listed because it's a non-standard vendor extension that's equivalent to aes256-cbc and is retained for config file backwards compatibility only. (If you put it in your config file then you ought to already know what it is :-) Ciphers Specifies the ciphers allowed for protocol version 2 in order of preference. Multiple ciphers must be comma-separated. The sup- ported ciphers are ``3des-cbc'', ``aes128-cbc'', ``aes192-cbc'', ``aes256-cbc'', ``aes128-ctr'', ``aes192-ctr'', ``aes256-ctr'', ``arcfour'', ``blowfish-cbc'', and ``cast128-cbc''. The default is ``aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, aes192-cbc,aes256-cbc''
So, like we said: this won't be changing for the forseeable future.