enabling "none" cipher

[hvjunk]

Have a look at https://github.com/rapier1/hpn-ssh 

For those stating the secret etc. etc. …<snip-zip>… the issue is this: there are dta that needs to move, and the encryption part adds undue latency and slowdown. The idea is to first properly authenticate (that being done through crypto security) and then you just mac “sign” the data to prevent/detect in transit modifications. The data is typically either already pre-encrypted from something else or aren’t valuable enough to bother, ie. you are moving already “open” data, or you are in a network where you are in control of the intermediary links, thus no exposure issues, but you still need to ensure/trust the initial authentication and want to make sure that the traffic was transferred without interference…. though rsync would be doing that for you too.

from https://www.psc.edu/hpn-ssh-home/hpn-ssh-faq/

Q: What is the NONE Cipher Switch?
A: The NONE cipher switch disables data encryption AFTER you have been authenticated or logged into the remote host. This can significantly reduce the load on the CPUs of both machines and may improve performance even more. It's important to remember that the initial authentication process is still fully encrypted. Additionally, while the data is no longer encrypted each packet is still digitally signed and protected against in transit manipulation of the information. Anytime the NONE cipher is used a warning will be printed to screen saying "WARNING: NONE CIPHER ENABLED". If you do not see that warning then the None cipher is not in use.
Q: Is it dangerous to use the NONE Cipher Switch?
A: That depends entirely on what you are trying to do. First off, you can't use the NONE Cipher Switch in an interactive session and is designed to be only used in the transfer of bulk data - like with scp. Second, you should be aware of what kind of data you are transferring. If you are copying financial or medical data then you would not want to use the NONE cipher. However, if you are copying non-sensitive data like MP3s, archives, images, and so forth it may make sense to use the NONE Cipher Switch. You will have to make that determination yourself. Lastly, since the authentication process is still encrypted hackers and eavesdroppers will not be able to steal your password.
Q: I have '-oNoneSwitch=yes' on the command line. Why doesn't it work?
A: You must use both '-oNoneSwitch=yes and '-oNoneEnabled=yes' on the client command line. Only using one or the other will not work. Additionally, the None cipher must be enabled on the server with NoneEnabled=yes in the sshd_config file or on the command line. Anytime the None cipher is used a warning will be printed to screen saying "WARNING: NONE CIPHER ENABLED". If you do not see that warning then the NONE cipher is not in use.
Q: I want the speed but I can't use the NONE cipher. Do I have any options?
A: Yes. As of HPN13v1 we've introduced a multi-threaded AES-CTR (MT-AES-CTR) patch that will allow SSH to make use of multiple cores. This can significantly improve throughput performance. In our test environments we commonly see near GigE line rate speeds - more than a 100% improvement over the default AES-CTR mode cipher.

> On 19 Dec 2025, at 09:07, Nacho via openssh-unix-dev <openssh-unix-dev at mindrot.org> wrote:
> 
> Hello,
> 
> I'm trying to enable the "none" cipher in OpenSSH 10.2 compiled for FreeBSD with
> no success so far.
> 
> Is it possible that there is no native support for "none" cipher in OpenSSH and
> this is just implemented by third party patches? 
> 
> This is my impression after looking at the FreeBSD patches for OpenSSH and
> OpenSSH source code and docs, but just wanted to confirm it before trying to fix
> it.
> 
> Maybe there has been some change in 10.x OpenSSH that breaks the "none" cipher
> patch that used to work for 9.x?
> 
> This patch is called "extra-patch-hpn" in FreeBSD, still applies cleanly, but
> after compiling it doesn't seem to work, the cipher "none" is not recognized no
> matter what.
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev