What is Reddit's opinion of OpenSSH?

From 3.5 billion Reddit comments

Ed25519 is preferred for a variety of reasons. You should use it, and no, keygen hasn't been updated to set it as default (likely to avoid breaking backwards compatibility for people scripting it).

RSA is entirely acceptable and has no known security flaws. 2048 bits might be starting to become a bit weak and while the default key size was bumped to 3072 a few years ago, some older distros still default to 2048; you might want to manually specify -b 3072 or 4096 if you want to use RSA.

There was some kerfuffle about "ssh-rsa" having some issues a while ago. "Stop using rsa keys" spread around in a few places. But this is misleading; it's because the original use of RSA in SSH was to combine it with SHA1, which is broken. This is not related to your RSA keys and when using OpenSSH you typically use rsa-sha2-256/512. The nuance is detailed in recent OpenSSH 8.6 release notes.

This isn't so much an Apple thing as it is an OpenSSH thing. High Sierra's opens has been updated to OpenSSH_7.6p1, which deprecates a bunch of older configs.

Release notes are here.

This release includes a number of changes that may affect existing configurations:

* ssh(1): delete SSH protocol version 1 support, associated configuration options and documentation.

* ssh(1)/sshd(8): remove support for the hmac-ripemd160 MAC.

* ssh(1)/sshd(8): remove support for the arcfour, blowfish and CAST ciphers.

* Refuse RSA keys <1024 bits in length and improve reporting for keys that do not meet this requirement.

* ssh(1): do not offer CBC ciphers by default.

Don't downvote this guy, it's a legit question.

Some of the most secure software on the planet is open source. OpenSSH is a great example, or the linux kernel itself of course.

It turns out that hiding your software from others is just another form of 'security through obscurity' - the hopes that because your attackers can't easily see how you built something, they won't be able to break it.

Turns out, surprise surprise, all forms of security through obscurity turn out to be crap when it comes to actual security - because while hackers have virtually unlimited time and resources to try to crack and reverse engineer software, the defenders are limited to their internal budgets.

Open sourcing your projects allows the attackers and defenders to have a fair playing field. And since only things that improve security will actually be merged and accepted into these public projects, they trend towards stronger security as time goes on.

I think it's that it seems harder to pivot from an insecure blockchain, in addition to that a lot of money is riding on it.

Just look at the lifetimes of cryptographic hashes... or OpenSSH

With that said, there might be something about blockchains and their implementations that make them more resistant to insecure implementations. But also maybe their usage is too new for methods to break blockchains to really develop.

Edit: Not trying to be a naysayer, and I really want to see Ethereum succeed, but right now these are my own realities of things that could happen down the road.

openSSH vulnerabilities:

• https://www.openssh.com/security.html
• https://www.cvedetails.com/vulnerability-list/vendor_id-97/product_id-585/Openbsd-Openssh.html

> January 14, 2016 OpenSSH clients between versions 5.4 and 7.1 are vulnerable to information disclosure that may allow a malicious server to retrieve information including under some circumstances, user's private keys. This may be mitigated by adding the undocumented config option UseRoaming no to ssh_config. For more information see CVE-2016-0777 and CVE-2016-0778.

Also, you are not getting my point: If you have a complex system, with multiple dependencies and multiple vendors that you can't fully control, and a couple of thousand people working on those systems, it is too hard or too expensive to reach full 100% security. Someone who promises either a) 100% uptime or b) 100% security obviously doesn't know what he/she is talking about.

It's not quite that simple.

Traditionally on Unix systems ports <1024 could only be bound by processes running as root. Since then, some systems including Linux gained some finer grained "capabilities", one of which (CAP_NET_BIND_SERVICE) allows binding to low ports.

In parallel, prior to privsep the sshd handling a user's session ran as root, and ssh could also run setuid. Because both could run with privileges, they check that the user running it is root before it allows that user to bind to ports lower than 1024.

In OpenSSH 7.5, PrivilegeSeparation was made mandatory and in OpenSSH 7.8 the ability to run ssh(1) setuid was removed, and with both of those gone the explicit check in OpenSSH was also removed.

So, if the server is OpenSSH 7.7 or earlier on the server, only root can will be allowed to bind to a port <1024. If the server is OpenSSH 7.8 or later, if the user is root or has CAP_NET_BIND_SERVICE then it can bind to a low port. If neither of those are true, you won't be able to bind to a low port.

TL;DR: In this context `ssh-rsa` means RSA with SHA-1. Make sure both your client and server support SHA-2 (support `rsa-sha2-256/512`). You are fine if both client and server use OpenSSH 7.2 (released in 2016) or newer.

There is a lot of important info in OpenSSH 8.2 release notes, including how to test your server and client.

From here: https://www.openssh.com/txt/release-7.2 > ssh(1): Add an AddKeysToAgent client option which can be set to > 'yes', 'no', 'ask', or 'confirm', and defaults to 'no'. When > enabled, a private key that is used during authentication will be > added to ssh-agent if it is running (with confirmation enabled if > set to 'confirm').

Mh, I feel you are the one lacking some understanding about some technical issues here.

Do you know why the OpenSSH package you use is called "portable OpenSSH"?

Was more on about the phasing out of ssh-rsa hashing algorithm.

TBH, if your SSH is public serving, both your client and server should already be using rsa-sha2. But, I do not know if AutoTools has been added with support.

A native SSH client may not be viable; one is the constant changes happening to the protocol (AutoRemote is using an even older libssh than AutoTools, for example) and the potential issues of US Export/Import laws for encryption (he's EU).

You are connecting to an old server, or using and old key created with a now insecure method.

https://www.openssh.com/txt/release-8.2 In short

It is now possible[1] to perform chosen-prefix attacks against the SHA-1 hash algorithm for less than USD$50K. For this reason, we will be disabling the "ssh-rsa" public key signature algorithm that depends on SHA-1 by default in a near-future release.

And so they suggest to start using either elliptic curve or simply SHA2

OpenSSH devs have this to say about scp

>The scp protocol is outdated, inflexible and not readily fixed. We recommend the use of more modern protocols like sftp and rsync for file transfer instead.

https://www.openssh.com/txt/release-8.0

A couple highlights:

Support has been added to iwm for the Intel 9260 and 9560

Support has been fixed in iwm for the Intel 3168

Newer firmware for the 3160, 7260, 7265, 8260 and 8265

A fix for backlight brightness on the Pinebook Pro has been included

Lots of improvements in support for the i.MX8M and RK3399 ARM64 SoCs

Fixes for the azalia HD audio driver

Speculative execution security vulnerabilities mitigation for ARM64

ARM64 support added to LLDB (LLVM debugger)

Work on support for newer generations of Intel CPUs

"Released LibreSSL 3.1.0"

" Fixed brightness keys on the x395 and other thinkpads with AMD graphics "

" Released OpenSMTPD 6.6.0. "

" Released OpenSSH 8.2. "

It's an indication that the cipher value in question is a vendor extension cipher. These ciphers may not be supported by other clients/servers (though, if I understand correctly, others are free to implement those ciphers as well). Other ciphers are defined in RFCs, vendor extensions need not be defined in an RFC at all. (In fact they can be private and the vendor could choose not to disclose them at all.) OpenSSH submits informational drafts with their vendor extensions, but does not always generate an RFC. See the standards here: https://www.openssh.com/specs.html

Correct me if I am wrong , but isn't PPTP ( partitailly ) broken since the early 2000's ? Not that it would matter in your secenario , but there is a better solution for your problem . So you don't wan't to get your traffic monitored . That is very understandable . The first thing you need is a second connection . Like one of your parents / firends / relatives has . The you buy a raspberry pi ( It's a one time 30$ investment ) . Then you ask the owner of the second connection if you can place the raspberry pi in their network . If the say yes you can port forward it and tunnel all you stuff through Openssh or PiVPN . You will have unlimited bandwith and they are much more secure then PPTP . Hope that helped .

> changing log formats

This is exactly what's going to happen with OpenSSH 7.5. Fail2Ban is going to Fail2Fail2Ban

https://www.openssh.com/txt/release-7.5

> The format of several log messages emitted by the packet code has changed to include additional information about the user and their authentication state. Software that monitors ssh/sshd logs may need to account for these changes

The OpenSSH project recommended SFTP over SCP on the release of OpenSSH 8.0.

>The scp protocol is outdated, inflexible and not readily fixed. We

recommend the use of more modern protocols like sftp and rsync for

file transfer instead.

However, it is expected that soon scp will use sftp's protocol, so you've got to ask yourself, why not use sftp anyway.

Keep in mind scp and sftp don't just simply ride ssh as that's kind of a simplication but ssh components are actually compiled with them in the libopenssh project and are all built together.

Saying all of that though, I agree with /u/othugmuffin and I use rsync via ssh instead of scp and sftp any time rsync is available anyway, which is almost always the case.

Fortunately, there is a new agent security feature that allows you to specify which hosts are permitted to use a specific key in the agent, and for what purposes. https://www.openssh.com/agent-restrict.html

the standard one from openSSH ---- https://www.openssh.com/

It ships by default with Solaris and all the Solaris based distro's.

OP - are you needing something more than the standard client software?

i am saying there is already support for post quantum algos in openssh since release 8.0

https://www.openssh.com/txt/release-8.0

> * ssh(1), sshd(8): Add experimental quantum-computing resistant key exchange method, based on a combination of Streamlined NTRU Prime 4591^761 and X25519.

In TFS 2017.3, the more secure CTR variants (aes128-ctr and aes256-ctr) are also enabled on the server. TFS kept support for CBC on the server for compat reasons, but in practice, most clients will not use CBC anyway.

CBC ciphers are already disabled by default in OpenSSH 6.7 clients https://www.openssh.com/txt/release-6.7.

Older versions of the OpenSSH client generally prefer CTR if CTR and CBC are both advertised by the server. If you want, you can also explicitly disable CBC in your SSH client config file if you want. See https://man.openbsd.org/ssh_config#Ciphers.

In addition, you cannot disable CBC on the TFS server for all clients without a patch update. The newer Azure DevOps Server should disable weak SSH algorithms by default

> Where do you see that 5.7 is unsupported?

It is unsupported by the OpenBSD project itself.

As for OpenSSH, looking at the OpenSSH release page for OpenBSD, you can clearly see patches have historically been provided for at most the last two releases, e.g: OpenSSH 8.4 had build patches for 6.6, while 8.6 had only patches for 6.7.

For comparison these were released in 2019/2020. Meanwhile, you're attempting to build modern of version of OpenSSH for an operating system version released back in 2015, meaning it has been unsupported for a long time.

And lost, his claims were bogus. SSH was a generic term long before he attempted to make a business out of it. The trademark was on a particular stylizing, which OpenSSH did not use.

More details of this ancient history here.

Completely agree. For a few files Finder could be OK, but when there are a lot more, better to use rsync or scp (or better sftp) to move files around. Note that scp is getting insecure (example: see https://www.openssh.com/txt/release-8.0). sftp is similar in functionality as scp but technically more secure.

> I use my PGP/SSH key

If you have users relying on PGP for your software then you are not a consumer in the traditional sense.

Also, OpenSSH supports FIDO2 based key types now. PGP will be obsolete for signing/authentication once all software down the chain adds support for FIDO2 ECC keys.

> also to send encrypted emails,

Most consumer PGP based email services don't allow hardware PGP cards and rely on encryption/key derivation instead.

S/MIME is a lot more popular going by usage. But non-enterprise users are switching to Signal/Element entirely because email is too much of a hassle

OpenSSH 7.4 is quite old - that's from December 2016, so you can definitely count on many bugs that have been fixed between Dec 2016 and May 2020. That's TEN releases behind!!

Read the release notes: https://www.openssh.com/releasenotes.html

Just because things have been fixed doesn't mean openSSH is bug free, or even that bugs were not introduced into the code.

It was only added in openssh 7.3 in 2016. Yes, that is 4 years ago nw, but compared to the length of time openssh has been around and in wide use, that's not a lot. Lots of people learnt ssh loooong before it was a thing.

> ssh(1): Add a ProxyJump option and corresponding -J command-line flag to allow simplified indirection through a one or more SSH bastions or "jump hosts".

I personally was actually vaguely aware they'd added it, but really only barely: I technically still use ssh a hell of a lot, but a lot less visibly so since I tend to favor automated and repeatable config with higher-level tools like ansible (despite dislike of yaml and ansible's wildly overstretched use of it). Of course ansible is still using ssh underneath but I manually ssh a lot less than I used to.

I think the point the guy above was trying to make, is that if it is using that old key exchange algorithms, then it might not make a difference if you use telnet except for obfuscation purposes. The algorithm is inherently weak. The OpenBSD guys(who make OpenSSH) writes "OpenSSH supports this method, but does not enable it by default because is weak and within theoretical range of the so-called Logjam attack."

&#x200B;

https://www.openssh.com/legacy.html

OP is using rsync. You can't segment transfers with rsync so there are better choices.

>The scp protocol is outdated, inflexible and not readily fixed. We recommend the use of more modern protocols like sftp and rsync for file transfer instead.

https://www.openssh.com/txt/release-8.0

"ssh-rsa" is only the name for the algorithm with sha1 hashes. The rsa algorithms with sha256 and sha512 are still good as well as ecdsa and ed25519.

https://www.openssh.com/txt/release-8.3 > The better alternatives include: > > * The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These algorithms have the advantage of using the same key type as "ssh-rsa" but use the safe SHA-2 hash algorithms. These have been supported since OpenSSH 7.2 and are already used by default if the client and server support them. > * The ssh-ed25519 signature algorithm. It has been supported in OpenSSH since release 6.5. > * The RFC5656 ECDSA algorithms: ecdsa-sha2-nistp256/384/521. These have been supported by OpenSSH since release 5.7.

So ECDSA should have the best compatibility with older openssh servers.

OpenSSH is disabling the ssh-rsa host key algorithm by default. Run this:

$ ssh -G yourserver | grep -w hostkeyalgorithms
hostkeyalgorithms [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],ssh-ed25519,[email protected],rsa-sha2-512,rsa-sha2-256,ssh-rsa

Note that ssh-rsa is on the end of the list. I presume with 8.3, it won't be on the list at all. If you had some ancient, awful piece of legacy enterprise kit that absolutely does not support any of the other algorithms then you can re-enable it with -o hostkeyalgorithms=+ssh-rsa on the command line, or by putting this into ~/.ssh/config:

Host legacy-crap-that-should-be-in-the-bin
HostKeyAlgorithms +ssh-rsa

See https://www.openssh.com/legacy.html for more details.

https://www.openssh.com/txt/release-8.0

You are clearly an advanced user so you should know, openssh team recommends against scp in favor of sftp and rsync. Modern implementations of ssh client/server can use sftp by default and sftp can be used to non-interactively get and put files.

The auto restart thing is just for the ssh daemon that shouldn't be involved. I did, however, (by looking at the release notes) find out that diffie-hellman-group14-sha1 is now removed from the defaults and group1-sha1 has been disabled for a while. So that should be the reason why sshfs with kdeconnect doesn't work any more.

The SSH client in Cisco IOS does not support DSS keys:

https://www.cisco.com/c/en/us/support/docs/security-vpn/secure-shell-ssh/19143-ssh-faq.html#anc5

I believe it is a legacy key algorithm as OpenSSH disabled it by default in 2015 with version 7.0:

https://www.openssh.com/legacy.html

are you remoting into something that may be running older software (specifically its SSH server application)?

As per my response to yours making the same point:

From the OpenSSH Homepage:

> The OpenSSH suite consists of the following tools:

> Remote operations are done using ssh, scp, and sftp.

I am aware that they use the same authentication, encryption and protocols, I often use ssh -X for instance. They are separate tools however and I generally find that the more detail the better with reporting issues.

Dude, jump (relay) server does not need any keys to be able redirect connection to another machine. Nothing is stored in RAM.

Since data transmitted through "jump" server is unchanged, a configuration from ~/.ssh/config on "initial" machine will be used.

If you have some doubts about OpenSSH security, then write your thoughts to the OpenSSH mailing lists. Pick an appropriate one from https://www.openssh.com/list.html.

I'm deleting post since it has nothing to do with Termux.

I'm not a putty user, but the wording of your reply reminded me of a common issue. You might have putty configured to use a legacy algorithm or cipher.

As you mention the server is not responding, perhaps the server sshd package was updated, which would deprecate those legacy options.

> The scp protocol is outdated, inflexible and not readily fixed. We recommend the use of more modern protocols like sftp and rsync for file transfer instead.

https://www.openssh.com/releasenotes.html

Well make sure you have port 22 open on server 2 for SSH, if not make sure you have an SSH client on server 2. If not install OpenSSH. I'm not familiar with the setup for NodeJS but am for Python, so I'm going to assume it's the same. The username is the username that will be used to logon to server 2, if the IP for server 2 is 10.0.0.288 then for the host you'll put 10.0.0.288. Then put the port that MongoDB runs on which is 27017. I'm not sure on the private key as I don't see my connection up that way. The password is the password tied to the username to logon to server 2.

&#x200B;

Hopefully someone more familiar with NodeJS setup can correct me on a couple of the parts.

Hmm, okay, a bit of an update. I first tried the weak encryption scp. It turns out that Ubuntu actually disabled the weak ones in at least the latest version (and maybe sooner). The only ones left are slower/more secure, I think. Someone in that SE thread mentioned the "blazingly fast" [email protected] cipher, which is still enabled, but didn't seem to be at all faster than normal (so maybe my PC doesn't support it). It seems like there might be ways to use legacy ciphers but to be honest it gets squirrely pretty quick.

I also tried using rcp, which should have *no* encryption, but to be honest it also wasn't very fast... for example, I'm testing it right now by sending the same ~100 kB text file 10 times from one PC to another. With all these options (typical scp, scp with aes128-gcm, rcp), they report my transfer speed to be ~1.5 MB/s, but all of them seem to have ~0.5 s of overhead. A 100 kB file at 1 MB/s should take ~0.1 s, and they seem to be taking 0.6-0.8 s.

Hmmm. Any idea what could be causing it? I'd love to use a single linux command as opposed to having to patch something together myself.

OpenSSH is a really important backbone of security on the internet, and they could use some love. They accept donations via the OpenBSD foundation.

https://www.openssh.com/

Mais ça ne fonctionne pas (bien) sous Windows je crois. Par contre, tous les autres systèmes l'utilisent (Linux, mac, BSD, matériel militaire, drones, mainframes, équipements réseau)

C'est quoi comme CG ?