We Keep Coding

SHA2 server SFTP fingerprints using Renci.SshNet

I'm using Renci.SSHNet to establish a connection to SFTP servers. I've done so without any problems but I've recently ran into a server to which I can´t establish a connection through my code.
I keep getting the following error:
No suitable authentication method found to complete authentication
(publickey,keyboard-interactive).
The thing is, I know the host, user and password are correct as I can establish a connection using FileZilla. I've noticed while connecting to other servers using FileZilla that the fingerprints for the ones I can also connect to with my code are generated through RSA as opposed to the one that is giving me trouble, which is SHA2.
TL/DR: What I'm wondering is: is the Renci.SshNet.SFTP library compatible with sha-2 generated fingerprints or will I have to use another library for this?

The SSH.NET library does not support ECDSA key exchange algorithms (ecdh-sha2-*) yet (as of 2014.4.6-beta2 release).
It supports these:
diffie-hellman-group-exchange-sha256
diffie-hellman-group-exchange-sha1
diffie-hellman-group14-sha1
diffie-hellman-group1-sha1
The ecdh-sha2-*'s are commented-out, probably because the implementation is not complete/tested.
Though note that the server can support multiple algorithms and can agree on a different algorithm with different clients.
So the fact that you see an unsupported key type in the FileZilla, does not mean that the server necessarily insists on this key type.
It is clear that the server does not require ECDSA key exchange from the fact that the connection fail in the authentication phase. The authentication happens only after a successful key exchange. So your root problem is not the key exchange, but authentication.
If you need a help resolving your authentication problem, start a new question, include relevant source code, FileZilla log file and explain us what you did to setup the authentication on the server-side. A server-side log file might be helpful too.

Self-signed certificate security for private server/client

I've read a lot that self-signed certificates should never be used in production because of the lack of security but I wonder if it's still a security risk if I'm the only one who're supposed to connect to the server? Is it for some reason easier to crack a self-signed certificate? I'm creating both the server and client application and the only way for someone else to connect is to create their own client. That means that every time I install the client I also have the possibility to add the certificate to the trusted root certificates.
Or is it safer to continue to use my own encryption implementation using RSA/AES on the message level? The reason I want to use SSL instead is that it's much easier to work with, especially when I want to stream media since I don't have to send it in chunks.

I've read a lot that self-signed certificates should never be used in production because of the lack of security ....
Self-signed certificates by itself are not bad and can also used in production if done properly.
A certificates is safe to use if the peer is able to verify it properly. The usual validation is done based on some trusted root CA contained in the browser or operating system. But that a self-signed certificate can not be validated this way does not mean that it cannot be validated at all because:
You can explicitly add it as trusted to the certificate store of the browser/OS.
You can make an exception on first use after you've verified that the certificate you get in the browser is actually the one which you know (by comparing the fingerprint, not just the subject).
If you have your own application you could ship the application so that it (only) trusts this certificate.
Of course explicitly importing the certificate as trusted or making in exception in the browser does not scale well, because it has do be done for each user. And that's the main point of CA-signed certificates: that the certificate gets implicitly trusted because it is signed by someone trusted instead of that each user has to validate and trust the certificate manually. And this is also the only reason you want to use a CA-signed certificate in production. As long as the certificate is properly validated it does not matter if it was self-signed or not.
Or is it safer to continue to use my own encryption implementation using RSA/AES on the message level?
Never run your own crypto unless you really understand what you are doing.
In this case SSL provides everything you need but you have to know how to use it properly.

Configured SSL on Apache Tomcat 7.0.47

Have implemented SSL with self-signed certificate On Apache Tomcat 7.0.47 using Java keytool.exe.It's working fine in Browser.
Issues are:
1) while invoking the API's in java/dot net client am getting exception as "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel"
Solutions i got through online are:
1) Need to ignore invalid certificates then what's the use of SSL implementation.
2) Need to import cert into client truststore.
Could anyone suggest me how to solve this problem,is anyother ways to implement SSL and invoke those API's in client application. don't want to ignore the Cert
It's working fine in java client using InstallerCert.java class but need to invoke HTTPs API's in dot net client,any help would be really appreciated
Thanks in Advance

You need to establish trust relationship between client and server, in order to call server APIs. For java you can follow these steps to achieve your goal -
Generate certificate for server (You can do this by using installCert.java)
Once this certificate is generated usually it will be keystore file and/or .cert file
You copy this file(s) into your JAVA_HOME/lib directory
Then restart your server and this should be done
More info can be found from these sources -
security-ssl-certificate-error-use-your-trusted-certificate and http://miteff.com/install-cert
Hope this helps. There are other ways also, to generate certificate but this way is easiest as per my understanding. :-)

Encrypted comunication between C# and PHP without SSL - certificate?

I need an encrypted communication between C# and PHP to send HttpWebRequest's and download files from the server. Is that possible without buying a certificate for https? I think a certificate should'nt be needed in my case, isn't it? What do you recommend to use?

If you control both ends, you can generate your own certificate and manually check that the server is using the expected one. It's in the case where the client wants to verify that the server is using the correct certificate that you need the functionality provided by a certificate authority.
Normally, the certificate is loaded into the web server and the encryption/decryption is invisible to any code running on the server. I would be very surprised if you could do it with just "php stuff".

Driving a Certificate Authority programatically (C# or C++)

I'm writing a client/server application that requires the server needs to be able to authenticate the client and also requires all comms to be encrypted.
The mechanism to provide this needs to be self contained within the server and client application and also to be fully automated (no human interaction required). SSL seems to be the best way to do this and is also something I am familiar with using.
For each client that needs the client software deploying to it, I planned to create (on the fly) an MSI installer with the application, the clients certificate (signed by the server) and private key and the servers public certificate (so the clients can authenticate the server - the server certificate could be self signed).
I can generate the key for the client and make a CSR, but don't seem to be able to find a way of actually signing the CSR and generating a certificate for the client thou. I have looked into the Win32 Crypto API, but haven't managed to find any examples of how to actually sign a CSR and get a client certificate.
I know how to do all of this from the command line with the openssl tool, but am not sure of how to do it from within an application.
Please note that making system calls out to the openssl tool and passing in the parameters I know to work is not an option as it's a huge security risk to rely on the openssl tool not being compromised in any way. Doing it this way wouldn't for fill the self contained requirement.
I am going about this the right way, or is there a better way to achieve the same thing - basically authentication of the clients connecting to the server and a way of the connecting client to authenticate the server they connect to, all encrypted.
I cannot make any assumptions about the server (or clients) having a static IP or hostname (DNS can be broken anyways), nor can I make any assumptions about any existing PKI infrastructure.
I am writing this primarily in C#.Net, but would consider writing a C++ extension to this if it gives me this functionality.
Finally this is my first post here, so if I've missed out something obvious or have been short on any details, please ask and I'll fill in the gaps :)
Thanks,
James

In C# you can use PKIBlackbox package of our SecureBlackbox product which provides all the functionality you are looking for in .NET. Maybe BouncyCastle library also includes this functionality.

You need to rethink at least part of this. What you are doing is radically insecure. The client's private key needs to be generated at the client. Otherwise it isn't private, so it cannot possibly satisfy any of the tenets of PKI,. including the purpose for which you are issuing it. You lose uniqueness and you also lose non-repudiability. These are both fatal flaws.