We are planning to use Apache Mina SSHd - ssh client in our product. I need to identify if it supports ssh2 protocol.
I checked various resources thoroughly but couldn't able to find information around it. Could you please confirm if it supports ssh2 and how to use/ configure it.
Apache MINA SSHD implements version 2 of the SSH protocol. Version 1 is obsolete and no longer considered secure, and almost nobody uses it anymore. The RFCs it links to in the README on GitHub all cover version 2 of the protocol.
Note that because the library supports a large number of cryptographic algorithms, many of which are no longer secure, you should be careful if you are using settings other than the defaults (which, except for the use of the ssh-rsa signature algorithm, should be secure).
If you're looking for some basic setup documentation for a simple client, the README has a link to some documentation for that as well.
Related
I have a bunch of linux servers configured to push logs to another fluentd server using the fluent-secure-output plugin. Now I'd like to configure our windows servers using nxlogs.
I read a bit on the om_ssl nxlogs module, but I am puzzled about the shared key. Basically, fluentd's secure-output plugin requires a shared key to be identical everywhere for authentication (this is not tied to the certificates at all). But I can't see how I could specify this key in nxlog's om_ssl configuration.
Is this even supported at all? Is it possible to use nxlogs to forward to an ssl fluentd server?
It looks like they have their own authentication protocol over TLS that uses shared_keys (i.e. passphrase) on the client side instead of using private keys. I don't know why that is needed but NXLog and most other log aggregator solutions (rsyslog, syslog-ng, logstash, etc) use plain TLS which can provide proper authentication for both the client and the server.
The protocol is described in their GitHub README and I doubt it will work with NXLog's om_ssl or anything else other than Fluentd's out_secure_forward.
The Fluentd input/output plugin to forward fluentd messages over SSL with authentication, works only between the two plugin (which is actually the same one) using authentication by shared_key check from both of client(out_secure_forward) and server(in_secure_forward).
So unfortunately you can't sent it through your nxlog only through out_secure_forward.
Quite often I have to access old sites using Sslv3 or other old, deprecated, SSL protocols.
Most of them are appliance that are not easy to update (storage controllers, tape controllers...).
Unluckily latest browsers on Linux (chrome and firefox) refuse to connect to this kind of sites, even with advanced options (SSLv3 support has been totally removed from Firefox).
What I need is a tool that can do such a thing:
tool --listen HTTPS:9050 --connect HTTPS://oldsite:443/
Obviously the "connect" part should accept any SSL version and the "listen" part should expose commonly accepted SSL versions.
I saw mitmtool and polipo but I could not configure them properly.
The key here is that the target site is not a proxy, but a simple https site.
Is it possible?
I have a request to setup "mutual SSL Authentication" using SFTP. They want to have a ProFTPd SFTP server authenticate the client by certificate. Is this even possible using SFTP? I assume because SFTP is key based SSH rather than cert based, it is not easily done. I suspect what they really want would be FTPS but they insist SFTP. Is anyone doing anything like this? Thanks!
As already mentioned, the question does not make sense in several points:
SFTP is file transfer protocol over SSH, which does not support any "SSL authentication" (unless you use X.509 patch, thought it might be your target)
ProFTPd might support SFTP (not natively as mentioned in comments) and certainly not with different authentication than the one supported by SSH.
You can set up openssh with sftp-server and set up CA for signing host keys and client keys (not X.509, but openssh), which might suit your needs, except it is not "SSL".
Or the other way around, use ProFTPd, use real SSL, but give up SFTP in favour of FTPS.
Both solutions are valid and reasonable, but making some mutant between them does not seem like a good future-proof solution.
I don't really know much about IT and have been working in software development for 3 years. I have used version control with Github and Bitbucket, but I really don't know how SSH, SSL, HTTPS works. Can anyone explain them in the context of version control with a cloud service like Github? Why is TLS not used? A user case example would be most helpful. High-level is fine.
Firstly, while a number of people think SSH relies on SSL, it doesn't: it's an entirely different protocol. The fact OpenSSH relies on OpenSSL might be one of the causes of this confusion (whereas in fact OpenSSL can do much more than SSL).
Secondly, TLS is essentially a newer version of SSL, and HTTPS is HTTP over SSL/TLS. You can read more about this in "What's the difference between SSL, TLS, and HTTPS?" on Security.SE, for example.
One of the major differences (in the context of GitHub and Bitbucket) has to do with the authentication mechanisms. Technically, both password and public-key authentication can be used with or on top of SSL/TLS and SSH, but this is done rather differently. Existing libraries and tool support also matters.
GitHub (with Git) relies on an SSH public key for authentication (so that you don't have to store or use a password every time).
Public key authentication in SSH uses "bare keys", whereas you'd need a certificate for SSL/TLS (and in 99.9% cases that's going to be an X.509 certificate). (A certificate binds an identity to a public key by signing them together.) GitHub would have to use or set up a CA, or perhaps use various tricks to accept self-signed client certificates. All of this might be technically possible, but this would add to the learning curve (and may also be difficult to implement cleanly, especially if self-signed cert tricks were used).
At the moment, GitHub simply lets you register your SSH public key in your account and uses this for authentication. A number of developers (at least coming from the Git side) would have been familiar with SSH public keys anyway.
Historically, Git over SSH has always worked, whereas support for HTTP came later.
In contrast, Mercurial was mainly an HTTP-based protocol initially. Hence, it was more natural to use what's available on HTTPS (which would rule out using X.509 certificates if they're deemed too complicated). AFAIK, SSH access for Mercurial is also possible.
In both cases (Git and Hg), the SSH public key presented during the connection is what lets the system authenticate the user. On GitHub or Gitlab, you always connect as SSH user git, but which key you use is actually what determines the user in the system. (Same with Hg on Bitbucket: ssh://hg#bitbucket.org/....)
I doubt if it is a good question for StackOverflow, however.
All these protocols are used as (secured) channel for Git data exchange. And, when you see 'SSL' most likely SSL/TLS is meant - just to not type both abbreviations. TLS is a further development of SSL protocol.
I have a web-server, that serves different domain-names, but has only one IP-address assigned. That works fine with virtual hosts in Apache. Now I want SSL-encrypted connections for the websites. How can I set different SSL-certificates for the different vhosts?
Using different IP's for the different hostnames would be an solution - not very elegant but possible. But I want to know, how I can use different SSL-certificates for different vhosts. So I look for a solution with only one IP-address.
UPDATE: 2013
It appears that SNI is finally beginning take hold as older browsers are falling away. Here are the docs for Apache SNI and here is a wikipedia article on SNI that includes a chart on browsers that support it. In short, all the major browsers support it in supported versions; if supporting older browsers is important, you may have to take that into consideration.
------ previous answer ------------
SSL Hosts must be tied to a unique IP address/port combination, thus you cannot use virtual hosting (Or at least, it can only have one ssl host per IP address). This is due to the fact that https begins encryption before the Host: parameter is sent in http, and thus it cannot determine which cipher to use from the hostname - all it has is the IP address.
This would be silly easy to fix if HTTP had a TLS command so it could start SSL after asking for the hostname, but no one asked me.
For the definitive answer, see http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts2
After hints in the answers given and comments to it (especially by Martin v. Löwis) I did some googling and found this website about RFC 2817 and RFC 3546. RFC 3546 seems to be a good solution.
AFAIK it's not possible to set up different SSL certificates for name-based virtual hosts using mod_ssl. You can read the detailed reason here. An alternative would be using IP based virtual hosts (Which is probably not possible / not a very satisfying solution) - just insert different SSLCertificateFile directives, or you could try this method using mod_gnutls.
You will need a separate IP:port combination for each vhost.
RFC 3546 is not feasible yet. IE only supports it when running under Vista, and last I checked Safari doesn't manage it either.
While everything DGM mentioned is true, there have been some attempts to get around the requirement for a unique IP address for every certificate including mod_gnutls and using TLS extensions. There are some drawbacks but they may be acceptable to you.
Finally it's possible! You need both server and client to support Server Name Indication (SNI)
Browsers, that support SNI:
Mozilla Firefox 2.0 or later
Opera 8.0 or later (with TLS 1.1 enabled)
Internet Explorer 7.0 or later (on Vista, not XP)
Google Chrome
Safari 3.2.1 on Mac OS X 10.5.6
This doc shows hoe to configure your server: SSL with Virtual Hosts Using SNI