Slashdot Mirror

Rather than get all aggro, I will state that I have tried to find a concrete answer to this question ("is OpenSSH vulnerable/impacted by this?"), and I still cannot. So before someone say "shut the fuck up when you don't know what you're talking about" to me, I'll provide the data (and references) I do have:

* OpenSSH links to the libcrypto.so shared library which is absolutely OpenSSL on most systems: ldd /usr/sbin/sshd followed by strings /whatever/path/libcrypto.so.X (you'll find OpenSSL references in there). Truth: because OpenSSH links to a cryptographic library that's part of OpenSSL doesn't mean it's necessarily using the code that's bugged (see below poster's sig and note function names are DTLS-related (keep reading)), but it also doesn't mean it isn't. When was the last time you ran truss/strace with all flags (for children, all syscalls, fd I/O, etc.) and looked at it closely?

* SSH, as a protocol, is not SSL (but keep reading): http://www.comforte.com/solutions/tls-vs-ssh/ and http://stackoverflow.com/questions/723152/difference-between-ssh-and-ssl (see replies to primary thumbs-up'd answer)

* However, SSH does rely on at least some part of TLS, the one that's known is X.509 (a form of PKI) (but keep reading): http://www.snailbook.com/faq/ssl.auto.html

* ...but then things like this seem to imply the OpenSSH folks don't use X.509 at all and that you have to run a special OpenSSH build for this to work: http://security.stackexchange.com/questions/30396/how-to-set-up-openssh-to-use-x509-pki-for-authentication

* ...but then you find things like this which are open-ended and seem to imply otherwise (and the link mentioned on that blog, by the way, is also worth skimming/reading to see what's being done): http://trueg.wordpress.com/2012/09/06/use-an-x-509-certificate-for-ssh-login/

* The "heartbleed" bug, which refers to RFC 6520, pertains to TLS: http://www.snailbook.com/faq/ssl.auto.html (yes same link)

* There are repeated/continual news references to "use of X.509" (which could apply to either SSH or SSL from the above references) in every single news announcement. I shouldn't need to link them all.

There is nothing even remotely definitive on either the OpenSSL or OpenSSH mailing list, and that's a bit shocking if you ask me. Therefore, to me, the OP's question is quite valid.

Does the answer to his/her question change the severity of the situation? Yes it does. Yes you should still upgrade OpenSSL, but what some of us senior system administrators are trying to figure out is whether or not we need to inform every employee that they need to generate new SSH keys. I think everyone at this point is aware webservers (ex. nginx, Apache, etc.) doing SSL need to have OpenSSL upgraded + the daemons restarted + keys re-generated + re-signed, but the concern here is whether or not any part of OpenSSH's function calls into the OpenSSL crypto library rely on anything related to RFC 6520.

My opinion: the reason nobody has definitive answer with references (and I hope this Slashdot post induces such) is because there's a serious disconnect between using security-focused software (end-users, SAs, companies using security software, etc.), the writing of cryptographic algorithms (cryptologists), and ac

Rather than get all aggro, I will state that I have tried to find a concrete answer to this question ("is OpenSSH vulnerable/impacted by this?"), and I still cannot. So before someone say "shut the fuck up when you don't know what you're talking about" to me, I'll provide the data (and references) I do have:

* OpenSSH links to the libcrypto.so shared library which is absolutely OpenSSL on most systems: ldd /usr/sbin/sshd followed by strings /whatever/path/libcrypto.so.X (you'll find OpenSSL references in there). Truth: because OpenSSH links to a cryptographic library that's part of OpenSSL doesn't mean it's necessarily using the code that's bugged (see below poster's sig and note function names are DTLS-related (keep reading)), but it also doesn't mean it isn't. When was the last time you ran truss/strace with all flags (for children, all syscalls, fd I/O, etc.) and looked at it closely?

* SSH, as a protocol, is not SSL (but keep reading): http://www.comforte.com/solutions/tls-vs-ssh/ and http://stackoverflow.com/questions/723152/difference-between-ssh-and-ssl (see replies to primary thumbs-up'd answer)

* However, SSH does rely on at least some part of TLS, the one that's known is X.509 (a form of PKI) (but keep reading): http://www.snailbook.com/faq/ssl.auto.html

* ...but then things like this seem to imply the OpenSSH folks don't use X.509 at all and that you have to run a special OpenSSH build for this to work: http://security.stackexchange.com/questions/30396/how-to-set-up-openssh-to-use-x509-pki-for-authentication

* ...but then you find things like this which are open-ended and seem to imply otherwise (and the link mentioned on that blog, by the way, is also worth skimming/reading to see what's being done): http://trueg.wordpress.com/2012/09/06/use-an-x-509-certificate-for-ssh-login/

* The "heartbleed" bug, which refers to RFC 6520, pertains to TLS: http://www.snailbook.com/faq/ssl.auto.html (yes same link)

* There are repeated/continual news references to "use of X.509" (which could apply to either SSH or SSL from the above references) in every single news announcement. I shouldn't need to link them all.

There is nothing even remotely definitive on either the OpenSSL or OpenSSH mailing list, and that's a bit shocking if you ask me. Therefore, to me, the OP's question is quite valid.

Does the answer to his/her question change the severity of the situation? Yes it does. Yes you should still upgrade OpenSSL, but what some of us senior system administrators are trying to figure out is whether or not we need to inform every employee that they need to generate new SSH keys. I think everyone at this point is aware webservers (ex. nginx, Apache, etc.) doing SSL need to have OpenSSL upgraded + the daemons restarted + keys re-generated + re-signed, but the concern here is whether or not any part of OpenSSH's function calls into the OpenSSL crypto library rely on anything related to RFC 6520.

My opinion: the reason nobody has definitive answer with references (and I hope this Slashdot post induces such) is because there's a serious disconnect between using security-focused software (end-users, SAs, companies using security software, etc.), the writing of cryptographic algorithms (cryptologists), and ac

> There exists an extremely widely-used crypto protocol which uses no certificate validation and yet prevents almost all MITM attacks.

Nonsense. Ownership of the host private keys, stolen from the target SSH server, allows quite effective MITM: see http://www.gremwell.com/ssh-mi... and http://www.snailbook.com/docs/.... Moreover, there is no reliable ownership or timestamp on SSH private keys. And worse, there is no working signature authority _available_ for SSH host keys. This makes spoofing an SSH server for new users much simpler. And most envornmnets are not careful to tie the SSH private keys to a specific exposed server or service: they wind up resetting the host keys when they rebuild the host, and pay no attention to a client's confusion about changing keys.

This is, effectively, no different than enabling SSL keys without any signature whatsoever, which is the state of SSL in most environments because many private and public institutions do not bother to purchase signatures for their SSL keys.

SSH is not dependent on SSL/TLS - it's just that one particular implementation of SSH (OpenSSH) is dependant on the OpenSSL library for its cryptographic primitives.

More details

Why not use https?

Learn what sockets are. Learn (It extends past a single slashdot message.) Learn SSH uses them.

Then compare with the https protocol.

Doesn't matter how clever you get; an https connection isn't an ssh connection; you've already lost before any of your JS program's input has made it onto the wire (encrypted or otherwise).

While you're at it, use the "TCP wrappers" feature to limit connections by host, and most unwanted connections will fail at an even earlier stage.

More info.

It is better explained as "AllowUsers localAccount@remote_ip_address". It means: "Allow SSH connections from anybody at remote_ip_address to connect to localAccount." (Of course the remote user still must authenticate successfully.)

The syntax unfortunately looks like it specifies a remote user. It doesn't. It defines a relationship between a remote IP address and a local user.

Trust me, I wrote the book. :-)

Basically what the script does is clean the environment. The requested command is stored in SSH_ORIGINAL_COMMAND environmental variable. Its checked to make sure it is in fact the command you intend. The options are then checked. Finally the script exec()'s the hardcoded path to the command with arguments supplied.

Although it comes written for scp i've used it for securing an account so they can't log in, and they can only execute one or two commands of my choosing.

from what i understand sftp just exec's /usr/libexec/sftp-server. i don't see why you couldn't alter the script to only allow that command.

also you'll want to make sure the client's ~/.bash_profile, ~/.profile, etc.--all its login scripts--are empty and owned by root so that they don't upload their own "special" login script and undo all your work.

scp-wrapper can be found here

Phibz

Yes, in great detail. You can also find answers to this FAQ on the book's official website and FAQ.