Below is a patch that adds the ability to have a none cipher and mac for
protocol version 2. By default, sshd will not allow these to be used;
an admin will have to explicitly allow them in the Ciphers and MACs
section of sshd_config. Additionally, the client will not use these
unless explicitly instructed to by the user.
The actual name of the cipher is 'none2', to distinguish it from the
'none' cipher available for ssh v1. The name of the mac is hmac-none.
The reasoning for having these is that there are times when a user might
not want their session encrypted. For instance, when using ssh over an
already secured interface (IPsec), through another ssh tunnel, or when
doing port forwarding over the loopback interface. It can be worthwhile
to save on cpu usage in these and other cases.
Index: cipher.c
==================================================================RCS file:
/cvs/src/usr.bin/ssh/cipher.c,v
retrieving revision 1.71
diff -c -r1.71 cipher.c
*** cipher.c 2004/07/28 09:40:29 1.71
--- cipher.c 2004/11/11 01:07:02
***************
*** 65,70 ****
--- 65,71 ----
{ "3des", SSH_CIPHER_3DES, 8, 16, evp_ssh1_3des
},
{ "blowfish", SSH_CIPHER_BLOWFISH, 8, 32,
evp_ssh1_bf },
+ { "none2", 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 -c -r1.6 mac.c
*** mac.c 2003/09/18 13:02:21 1.6
--- mac.c 2004/11/11 01:07:03
***************
*** 45,50 ****
--- 45,51 ----
{ "hmac-md5-96", EVP_md5, 96 },
{ "hmac-ripemd160", EVP_ripemd160, 0 },
{ "hmac-ripemd160 at openssh.com", EVP_ripemd160, 0 },
+ { "hmac-none", EVP_md_null, 0 },
{ NULL, NULL, 0 }
};
J Raynor wrote:> Below is a patch that adds the ability to have a none cipher and mac for > protocol version 2. [..] > > The actual name of the cipher is 'none2', to distinguish it from the > 'none' cipher available for ssh v1. The name of the mac is hmac-none.Leaving aside whether or not this is a good idea (which has been done to death here and elsewhere many times before, check the archives) if you're going to do this then you ought to either stick with the specs[1] and call them "none" or make them local extensions[2], eg "none2 at your.domain.com". [1] http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-19.txt (section 6.3 & 6.4) [2] http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-17.txt (section 4.2 and 6) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
Douglas E. Engert wrote:
>So why do you need ssh without encryption? Won't telnet or rsh do
>just as well?
This is just a personal preference but I'd rather not use telnet or
rsh for anything. They are crusty. Much better to use ssh all the
time - only one daemon to run instead of two, only one command to run.
Anything that helps get rid of telnet and rsh is a good thing!
Those are my subjective feelings. A more rational explanation is to
say that the ssh and sshd code is of good quality and well audited for
security holes. You can't be so confident about rshd or telnetd. If
you want a remote connection without encryption, ssh is certainly a
more secure way to do the job than any of the old stuff.
Users who ask for ssh with 'none' encryption are paying the openssh
developers a compliment by showing that ssh is worth using for its
code quality and ease-of-use alone, even without the added security of
strong encryption.
--
Ed Avis <ed at membled.com>