This occurs when there is a version mismatch between the client and server of SSH. When it occurs, the client will give the list of available methods provided by the server, e.g.:
$ ssh firstname.lastname@example.org
Unable to negotiate with 184.108.40.206 port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
You’ll have to choose one. Here’s how:
ssh -oKexAlgorithms=diffie-hellman-group14-sha1 email@example.com
This is easily done in Local Group Policy, on the machine with the RDS licensing server:
Remote Desktop Services/
Remote Desktop Session Host/
In most supported versions of Windows to date, we browse here in the registry:
SecurityLayer to zero (0), and we’re done. In Server 2016, we have to change DWORD
UserAuthentication to zero.
Remote Web Workplace. Certificates are verified AOK, and yet at the point of RDP, you receive a popup reading “Your computer can’t connect to the remote computer because no certificate was configured to use at the Remote Desktop Gateway server. Contact your network administrator for assistance.”
To fix this, you’ll need the Remote Desktop Gateway Manager. If you have it, it’s in Start, Administrative Tools, Remote Desktop Services. If you don’t have it, install it:
dism /online /Enable-Feature:Gateway-UI
- Open the RDGM.
- Right-click the server object, open properties.
- Open the SSL Certificate tab.
- Click Import Certificate.
- Choose the correct certificate — it’s the Exchange list, if this is SBS — and click OK.
Definitions and items:
- VPN stands for Virtual Private Network. A true VPN connects two different networks, using an encrypted “tunnel” through Internet or other non-private connectivity.
- SSL VPN as defined by OpenVPN (and its wrappers like Watchguard SSL VPN), is not a true VPN. It is an SSL-encryption agreement between devices, building either a TCP tunnel or a UDP dataflow, over which tightly controlled network redirection traffic is distributed.
- This means that the source and destination subnets, though not IPs, can be the same.
So let’s say that we need to give a PC which is sitting on someone else’s 192.168.1.0/24 network, an encryption-protected connection for RDP and file sharing, to the office Windows machine at 192.168.1.20. If SSL VPN were true VPN, this would require a subnet change at either the remote side or the home LAN, no further option. But it’s not, so we can do this:
- Restrict the SSL VPN capability on the office side, to just the domain controller (e.g., 192.168.1.250) and the RDP destination (192.168.1.20).
- Make sure that the IP of the device on the remote side, is not a duplicate of either the domain controller or the RDP destination on the office side. So it can’t be either 192.168.1.250 or 192.168.1.20.
- We can do this by setting a static IP on the remote device; alternatively, we can change the DHCP subnet of the remote site. Either of these are vastly easier than changing subnets!
- The only loose end left, may be network printing on the remote side. Just make sure that the printer’s IP is not any of the vitals at the office, and is IPv4, and it will work just fine. Some printers (generally consumer-grade) are defaulting to semi-proprietary IPv6 modes in their Windows configurations, and at least some SSL VPN configurations will not play ball; in this scenario you’ll want to convert the PC setup(s) to use v4.
This tool appears to be made for this, among several other things:
Some firsthand reports:
There are a few others options on that page also.
If you’ve ever wanted an easier interface, here’s SmarTTY:
Best information is now here for Windows and other software firewalls:
There is a link in the above for “whitelisting information” which really has the skinny for hardware firewalls: