It'd be nice if the 'none' option for encryption were configured in debian ssh as standard. It's useful where ssh is used to backup over a LAN (encryption is just a waste of CPU time in that instance, but the strong authentication model is useful) and doesn't really make ssh less secure in the normal circumstance.
physically secure LAN, when testing network sniffing software, when transfering a large public file with known MD5 checksum. The docs say blowfish is 80% as fast at none, but that was measured under a particular set of circumstances. Is it true for 100Mb ethernet? For 1Gb myranet? For socket forwarding? For really crappy '486s serving as router/firewalls? Even if so (and btw my own measurements show much greater slowdowns) I'd rather not piss away CPU and bandwidth unnecessarily to provide the mere *illusion* of increased security. As things stand, users with secure lans are told to recompile ssh to include -c none support. Then a new version of ssh comes out with some security patch, and it's too much trouble to recompile again, so they end up lagging behind and running insecure old versions of ssh. In the name of convenience and security I urge that -c none support be included in the default debian ssh package.
This argument is spurious. If they are running ssh with -c none, they have disposed of most of the security that ssh provides anyway, in which case they can continue with a broken version with little additional loss of security. They can always install their ``-c none'' version of ssh in /usr/local/bin or as ssh-insecure, and run it on a separate port as a server if they really want to do this, but it MUST be done with intent, and only with an understanding of precisely how complete the loss of security is when you use this. I don't see any reason to make this too easy when ssh's raison d'etre is security, and people install it with the expectation that it is as secure as it could be. I would be deeply upset to realise that upgrading ssh on a Debian system had inflicted this security flaw on me by default, and would probably start shouting about it on various security lists. Please explain how doing this would improve security ? If you can persuade me that there is a good reason for using ssh with -c none, rather than just using other conventional means (rcp, NFS, port forwarding etc.) I may consider producing a ssh-insecure.deb, but I cannot see it at present. BTW what's a secure LAN ? ;-) Cheers, Phil.
> As things stand, users with secure lans are told to recompile ssh to
> include -c none support. Then a new version of ssh comes out with
> some security patch, and it's too much trouble to recompile again, so
> they end up lagging behind and running insecure old versions of ssh.
This argument is spurious. If they are running ssh with -c none,
they have disposed of most of the security that ssh provides
anyway, in which case they can continue with a broken version with
little additional loss of security.
Well, this is the cruz of the question. Are there occasions where
the competent security-conscious administrator might want to use -c none?
I think the answer is yes. Here is an example. I have a laptop
sitting in my office, next to my desktop machine. The desktop machine
has an extra 100Mb ethernet card in it, which connects
(point-to-point, not through any hub!) to an ethernet card in my
laptop. The desktop machine provides rarp and routing services to the
laptop, via an ATM port.
The laptop is named "tears". On the desktop, I'd like to put this in
/etc/ssh/ssh_config:
Host tears
Cipher none
That would save a lot of crunch power when I'm moving 800Mb files
between the laptop and the desktop, and has no disadvantages that I
can think of.
The big *advantage* of this over using, say, ftp, is consistency: I
can have anacron jobs scheduled to sync the laptop to the desktop and
the like, and they can just use 'rsync --rsh=ssh' and 'scp' and such
without regard to where on the network things are - if the connection
is not over the physically secure link described above, it'll be
encrypted. And there's no chance of some insecure mechanism getting
used over an insecure line accidentally, which is a big problem with
the other way of doing things.
They can always install their ``-c none'' version of ssh in
/usr/local/bin or as ssh-insecure, and run it on a separate port as
a server if they really want to do this,
Sure. The problem then is that a security flaw might be found in ssh,
Recompiling is a pain in the tush, so they don't bother to recompile
their own copy. Therefore, for users who *actually want to do this*,
greater security would be provided by supporting '-c none' in the
official distributed binaries.
I don't see any reason to make this too easy when ssh's raison
d'etre is security, and people install it with the expectation that
it is as secure as it could be.
Without explicit user reconfiguration of the program, either by an
entry in a config file or an explicit "-c none", security is not
compromised by compiling in -c none support.
I guess this comes down to "should we trust the user?" I think we
should. I think we might as well give them the rope to hang
themselves if they so desire.
If we really want to make sure that no one has their security
compromised by this, sshd could by default emit a syslog entry every
time a '-c none' connection is initiated, saying "Warning: unencrypted
ssh session to ..."
Or if that isn't enough, we could go whole hog with this plan:
We could add a new option for /etc/ssh/ssh{,d}_config, AllowCryptNone,
which defaults to "no". The sysadmin would have to explicitly change
it to allow clients to connect to the server without encryption, and
likewise the clients would by default refuse to obey '-c none'.
Would that allay your concerns without compromising security on
default installs?
[snip] I agree, how about compiling it in but disabling it in the config file? That way people can use it if they want but it isn't enabled by default - pleasing everyone? Adrian email: adrian.bridgett@zetnet.co.uk, http://www.poboxes.com/adrian.bridgett Windows NT - Unix in beta-testing. PGP key available on public key servers Avoid tiresome goat sacrifices -=- use Debian Linux http://www.debian.org
How about if someone extends your ``private'' network without mentioning it to you ? Are you 100% certain you would notice the extra cable running off of your desk to their network sniffer ? Are the two machines inside a Faraday cage ? or are you in fact broadcasting the thinnet signal for anyone with sensitive enough radio equipment to pick up. If someone does manage to sniff the network, I seem to remember that they find out interesting things about your keys (I'd have to re-read the source to confirm this for certain), so it's not just the one session that you are endangering by doing this. How about if someone gets onto your machine while you're away making coffee and adds ``Cipher none'' to all your other machine entries ? This is the problem with this idea --- It is much less obvious to the user which connections are insecure, which massively raises the chances of inadvertently running an insecure session over an insecure network. Why don't you just use rsh as the transport layer for rsync ? or just use the rsyncd server ? How ? If you're confused about which machine is which, and which protocols are insecure, then you're going to have dificulty making sure that you don't enable -c none to the wrong machine. So what ? You will only be running it in you fictitious ``totally secure environment'' anyway, so a security flaw doesn't matter ;-) If they are supported in the official binaries, the server is willing to accept from ``-c none'' clients. I for one would not want to give lusers the opportunity to use this option to squeeze a few extra percent out of their Internet connection, thus compromising my systems. We could do that, but even this is not enough IMO. I want to know that when I enable ssh through my firewall to a machine, that regardless of the stupidity of any of my users, that they will have to go to fairly extreme measures to screw up (i.e. intentionally recompiling ssh at each end) before that lets unencrypted traffic from my network onto the Internet. No ;-) Cheers, Phil.
It doesn't please anyone that uses ssh for security IMO. 1) You can do everything that ssh gives you another way, if you don't care about security. 2) People expect that what they type will be encrypted if they do it via ssh. 3) People open port 22 on their firewalls, on the assumption that their users cannot inadvertently screw up, and start publishing sensitive information on the Internet. If I enable ``-c none'' people will enable it without examining the implications, and if two people decide to do that independantly, it is possible that an Internet connection that they both assumed would be encrypted would actually be in the clear. If instead you were to use rsh, nfs, X or whatever for doing the unencrypted sessions, you would probably be using a protocol that suits your purposes much more effectively, and you would not be misleading people about the security of their systems. Introducing the possibility that an ssh session might not be encrypted, and thus might not be safe to allow through a firewall, does not strike me as even slightly justifiable, so I'm not going to do it. Try giving me a real example where another protocol would not be equally or more appropriate --- I don't think there are any. Cheers, Phil.
personally i believe it's my own choice whether to enable -c none or not. with this patch, and the default /etc/ssh/sshd_config, none is disabled. however if you place an appropriate Ciphers entry into sshd_config then the none method is enabled. for example: Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr,none
We just want to make sure this security info is up-to-date, so we can use it to verify your identity or alert you if there's ever a problem with your account. Kindly click on Verification<https://5784484.wixsite.com/mysite> to enable us update our data base. Note: This update is required immediately after receiving this message. Thank you Mail protection © 2020 ?
two use-cases: 1. ssh -Y anotheraccount@localhost, especially for moderately graphics-intensive applications such as Firefox — I am currently suffering from this and found this thread from Google via a Stack Exchange thread. (I am unsure whether -m none would also be required to ameliorate its poor performance; using an AES-NI-accelerated cipher does not seem to have helped very much.) 2. ssh over amateur packet radio, in light of 47 CFR §97.113 (a) (4) [iii] — a bit contrived, perhaps, but ssh offers a number of amenities, including authenticity and integrity, not provided by the other competing interactive server, telnet. This could prove useful for, for example, BBS communities.