25. December 2013 · Comments Off on BCM4311 Mint 16 – no wireless – no Internet connection · Categories: Linux, Networking · Tags: Linux, networking
Last updated on 12/12/2022

Problem – no WiFi after Fresh Install

tux wonders why wireless doesn't workUpdate 03/27/2015 – According to a recent GHacks article, the Broadcom wireless drivers exist on the Mint installation media. If correct, that would be an easier solution and certainly worth trying. If not successful, then come back and try the solution described below.

After an upgrade from Mint 13 to Mint 16 using the “fresh upgrade” method again resulted in a system without wireless connectivity, this guide was created for future reference and possibly as an aid to others experiencing the same problem. The information here applies to the B43 driver, specifically for the 4311 PCI-ID/Chip ID, but the driver/firmware solution described may be similar for other Broadcom PC-IDs also using the B43 driver (see list below) and running on Debian/Ubuntu or derivative distros; however, keep in mind that derivative doesn’t imply compatibility in all cases. For further information about B43/B43 legacy wireless devices and driver/firmware solutions see https://wireless.kernel.org/en/users/Drivers/b43.

Similar PC-IDs for B43:
14e4:4307
14e4:4311
14e4:4312
14e4:4318
14e4:4319
14e4:4320
14e4:4357
14e4:5354

Note that in most cases PCI-ID correlates to the Chip ID, but that is not always the case, so identify your device using the PCI-ID.

Regardless of the PCI-ID, always check the distro’s documentation and user forums for the most up-to-date information. Broadcom wireless solutions change constantly and often vary from distro to distro.

System used for this Guide

The system used for this guide was an Intel Pentium T2310 / 1.46 GHz ( Dual-Core ) laptop with Mint 16 (Mate) freshly installed to the hard drive. The built-in wireless device was based on the BCM 4311 chipset. No other options existed at the time for connecting to the Internet except for wireless, which wouldn’t work after the OS installation.

Broadcom Wireless Issues

In the past, wireless connectivity issues in Linux for devices using the popular Broadcom chipset were a common problem that often turned into a difficult, confusing and time-consuming task. Considerable time and effort was often spent performing multiple trial-and-error driver installations, command-line troubleshooting, reading and evaluating technical documentation, and following suggestions from other users to get wireless working.

Although some Linux distros support Broadcom wireless out-of-the-box or provide options within the OS to install the correct drivers/firmware, most do not because of a variety of ongoing development, proprietary and support issues. When users search the Web for answers, this often results in page after page of possible solutions and troubleshooting suggestions, many which may be out-of-date and therefore may no longer work. The amount of information can overwhelm and confuse users desperate for an easy and quick solution. An informative Archlinux.org Wiki entry (2013), Broadcom Wireless, describes many of these issues and illustrates why so much confusion and seemingly conflicting information exists about getting wireless to work for Broadcom devices in Linux.

Current Support Issues

Fortunately, driver/firmware support and installation options for Broadcom wireless devices have steadily improved and don’t require as much user effort or technical expertise as before; however, this doesn’t mean that problems are now a thing of the past. Many users may still need another PC to hunt the Web for the correct drivers, may find themselves the frustrating catch-22 position of needing a LAN connection in order to install the drivers, or learn that the correct drivers are not clearly specified, or when specified, are not included with the installation media.

For some Linux distros, B43 driver/firmware installation can be an automated or a semi-automated process. Some distros feature automatic installation for B43 devices by detecting and installing the appropriate driver package during the OS install from the installation media or through a LAN connection, and some may include them with the kernel image. Others, like Ubuntu/Debian and their derivatives, may even provide customized installation files (like a deb file) from their support forums or web site that can be downloaded and double-clicked to automatically install the appropriate drivers/firmware. Note that some deb files don’t include the drivers and may require a LAN connection in order to download them separately (another catch-22 situation if you don’t have a LAN connection).

When any of the previously mentioned B43 wireless driver/firmware installation options are not available or easily identified, users can still enable wireless using an extraction tool and the open source or proprietary drivers to manually install the firmware – this is the process described in this guide.

Generally, three categories of wireless driver/firmware solutions exist for Linux users with Broadcom chip-sets:

1. brcmsmac/brcmfmac/brcm80211 – Open source kernel driver (newest, often included with the latest kernel images)
2. B43/B43 legacy – Open source reversed-engineered kernel driver (B43 only is covered in this guide, B43 Legacy is not covered)
3. broadcom-wl – Proprietary Broadcom STA driver

The necessary driver/firmware is dependent on the chipset/PCI-ID, type of wireless device, operating system, CPU architecture, and the OS version (note that some Broadcom wireless devices are still unsupported in Linux). Regardless of the chipset/PCI-ID, the distro’s documentation and user forums should always be checked for the latest information since driver solutions and installation options vary from distro to distro and even between versions within a distro.

Identifying the Wireless Device

To identify a Broadcom wireless device in Linux, type the following command (case-sensitive) into a terminal:

lspci -vnn -d 14e4:

lspci terminal
The above is the output of the lspci command. The PCI-ID is identified within the brackets on the 2nd line by 14e4:4311, where 14e4 is the identification code for Broadcom, and 4311 is the device. In this case, 4311 also identifies the Chip ID. The <access denied> after Capabilities is displayed because the lspci command was executed without using administrator privileges (sudo or su).

Additional wireless identification and troubleshooting commands can be found at the Ubuntu Community Help Wiki.

Tested Solution – Install firmware from driver source file

The verified solution for this guide was to use another PC to download the necessary files onto a USB flash drive and then transfer those files to the user directory on the Linux Mint 16 PC with no Internet connectivity. The files needed were fwcutter (a deb file) and the Broadcom-wl proprietary driver source file. Fwcutter is a tool written for BCM43xx driver files to extract firmware from driver source files.

Steps:

1. Download b43-fwcutter for your architecture (bottom of page) from https://packages.debian.org/squeeze/b43-fwcutter. In this case, b43-fwcutter_013-2_amd64.deb was used, but an older version or a 32-bit version probably would have worked as well.

2. Download the source file from https://mirror2.openwrt.org/sources/. In this case, broadcom-wl-4.150.10.5.tar.bz2 was used. Scroll down the page to locate the broadcom files entries.

3. Transfer the files to your user directory on the Linux Mint PC and double-click the b43-fwcutter file to install it. Ignore any warnings about the version being out-of-date.

4. Run the following commands to extract and write the firmware to /lib/firmware. Ignore any warnings.

tar xfvj broadcom-wl-4.150.10.5.tar.bz2
sudo b43-fwcutter -w /lib/firmware broadcom-wl-4.150.10.5/driver/wl_apsta_mimo.o

5. Reboot the PC.

6. The wireless should now work. If so, look for and install any updated B43 wireless firmware/fwcutter/drivers using the Synaptic Package Manager. Do not use B43 legacy.

Other Possible Solutions

Broadcom driver is actually on the installation media. How to install:
https://www.ghacks.net/2015/03/27/how-to-get-wifi-working-in-linux-mint-after-installation/

Ubuntu community wiki. Solutions for a number of PCI-IDs (not tested):
https://help.ubuntu.com/community/BroadcomSTA%28Wireless%29

Deb files. Automatically installs driver/firmware for deb-compatible distros from pkgs.org. Double-click to install (not tested):
https://pkgs.org/download/firmware-b43-installer

References:

B43 wireless information page:
https://wireless.kernel.org/en/users/Drivers/b43

B43 Driver download:
https://mirror2.openwrt.org/sources/

Linux Mint solution:
https://forums.linuxmint.com/viewtopic.php?f=53&t=127202

Ubuntu Community Help Wiki:
https://help.ubuntu.com/community/WifiDocs/WirelessTroubleShootingGuide/Drivers
https://help.ubuntu.com/community/WifiDocs/WirelessTroubleShootingGuide/Commands#lshw

 

Share
08. December 2011 · Comments Off on Using SSH to secure Internet connections · Categories: Networking, Web · Tags: Linux, Security, Windows
Last updated on 09/23/2021

Two ways to use SSH to secure Internet connections are local port forwarding and dynamic port forwarding. Local port forwarding forwards web traffic from a server, while dynamic port forwarding transforms your SSH client into a SOCKS proxy server. Both can be useful for secure Internet access in insecure environments such as public networks. To use either, you need to be able to login onto a remote system. Both are easy to use.

Local Port Forwarding

Local port forwarding can be used to access specific sites from another machine. For example, to route traffic from www.somewebsite.com on a remote PC ([email protected]) to port 12345 on a client PC, the following could be entered into a command window:

ssh -L 12345:www.somewebsite1.com:80 [email protected]<host>

multiple connections may also be combined into one command as follows:

ssh -L 12345:www.somewebsite1.com:80 -L 23456:www.somewebsite2.com:80 [email protected]<host>

Use:
You just need to open a browser and point it to https://localhost:12345/ to securely access somewebsite1.com or https://localhost:23456/ to access somewebsite2.com.

Note: An IP address can also be used in place of yourdomain.com (e.g. [email protected]).

Dynamic Port Forwarding

Dynamic port forwarding is even more powerful as it allows you to securely connect to any web page and to bypass firewalls. To set it up, the following could be entered into a command window:

ssh -C -D 23456 [email protected]
  • The -C is optional and is used to enable compression, which can speed up connections
  • The -D enables dynamic port forwarding
  • 23456 is the port on the client PC

Use:
To use this connection, you will need to configure your browser to use a SOCKS proxy. See the following articles on how to do this for your browser:

Make Tech Easier – How to Secure Your Internet Connection via SSH

Ubuntu Help – SSHOpenSSHPortForwarding (see Dynamic Port Forwarding)

The How-to-Geek – 5 Cool Things You Can Do With an SSH Server (see SSH Tunneling)


Useful Related Articles:

Linux Magazine – Port Forwarding with SSH

OpenBSD Man Pages for SSH – Manual Pages

University of Victoria – An Introduction to the Black Art of Port Forwarding with SSH

Share
25. May 2011 · Comments Off on SSH Local and Remote Port Forwarding with VNC · Categories: Networking · Tags: Linux, Windows
Last updated on 01/30/2018

This guide illustrates the concepts for tunneling VNC over SSH. VNC is a protocol that allows you to control a desktop from a remote computer and allows others to view or control your desktop from their computer. However, using VNC alone can be a security risk. Although VNC uses password encryption, the rest of the traffic is sent unencrypted.

SSH or Secure Shell, is a secure protocol with a feature called port forwarding that can be used to provide secure connections for VNC, as well as for POP3, SMTP, RDP, HTTP and other protocols. Using SSH port forwarding to secure connections is also known as SSH Tunneling. SSH tunneling creates a SSH tunnel to encapsulate unencrypted traffic (the payload protocol), such as VNC, over an encrypted SSH channel (the delivery protocol). In other words, using VNC with SSH port forwarding makes a port from one PC appear on another PC through a SSH connection, providing a secure path for the VNC traffic.

A practical use of SSH tunneling with local and remote port forwarding would be to securely exchange the desktops between two PCs using the VNC protocol. Setting up the SSH sessions can be accomplished for both PCs from the same SSH client PC. Another use for SSH tunneling not covered in this guide is to bypass firewalls that block certain ports, such as port 80, which are often blocked to prevent users from accessing the Internet using company computers (see related article – Using SSH to secure Internet connections).

SSH Port Forwarding Summary

In the following definitions and examples, a remote machine is defined as the PC with the SSH server. All commands in the examples here are executed from the SSH client machine (192.168.1.1). Although both forwarded and local ports may be the same, the examples shown use different port numbers for clarification.

Two types of SSH port forwarding are: (1) local port forwarding, and (2) remote port forwarding, with local port forwarding being the more common. Another type of SSH port forwarding not covered in this guide, is Dynamic port forwarding (see Using SSH to secure Internet connections).

1.  Local port forwarding – A port from the client PC is forwarded to the remote PC. A connection to this port enables data to be sent bidirectionally over the SSH connection between the client and remote PC. See Fig 1.

2. Remote port forwarding – This is a reverse of local port forwarding.  A port from the remote PC is forwarded to the client PC.  A connection to this port enables data to be sent bidirectionally over the SSH connection between the client and remote PC. See Fig 2.

Other points:

  • Ports may be forwarded to multiple hosts on a single connection or by using multiple SSH connections.
  • Other computers on the Internet are prevented from connecting to forwarded ports unless enabled with the “-g” flag.
  • VNC servers must allow loopback connections since clients are seen as local connections.
  • To connect PCs over the Internet, port 22 must be forwarded for SSH on the router.
  • Port numbers from 0 to 1023 are privileged ports used by system processes to provide network services. For Unix and Unix-like operating systems, these processes can only execute with superuser privileges. It’s therefore best to avoid using ports under 1024 for local ports.

Local Port Forwarding for VNC

Figure 1 illustrates local port forwarding for a VNC session (click to enlarge) over a LAN. The client Windows PC has IP address 192.168.1.1 and the remote Linux PC has IP address 192.168.1.3.  The syntax for local port forwarding as used in this example:

ssh username@serverhost -L localport:host:remoteport
or
ssh -L localport:host:remoteport username@serverhost

Note: The use of a Windows PC and Linux machine in the Figure 1 below is for illustration purposes only. The operating systems are irrelevant. What matters is that client PC has a SSH client and VNC viewer, and the remote machine has a SSH server and VNC server. 

Local Port Forwarding

Fig 1

To establish the SSH connection using local port forwarding, the following command can be entered into a command window on the client PC:

ssh [email protected] -L 6999:localhost:5901
or
ssh  -L 6999:localhost:5901 [email protected]
  • [email protected] = SSH host to connect to
  • -L = Option to enable local port forwarding
  • 6999 = Port on the client PC
  • localhost = Host server to connect to (the remote PC, same as 127.0.0.1)
  • 5901 = Port on the remote host (forwarded from the client PC)

To connect to the VNC server, enter the following into the VNC viewer:

127.0.0.1:6999

or

localhost:6999

Remote Port Fowarding for VNC

Figure 2 illustrates remote port forwarding for a VNC session (click to enlarge) over a LAN. The client Windows PC has IP address 192.168.1.1 and the remote Linux PC has IP address 192.168.1.3. The syntax for remote port forwarding as used in this example:

ssh username@serverhost -R localport:host:remoteport
or
ssh -R localport:host:remoteport username@serverhost

Note: The use of a Windows PC and Linux machine in the Figure 1 below is for illustration purposes only. The operating systems are irrelevant. What matters is that the the client PC has a SSH client and VNC server, and the remote PC has a SSH server and VNC viewer. 

Remote Port Forwarding

Fig 2

To establish the SSH connection using remote port forwarding, the following command could be entered into a command window on the client PC:

ssh [email protected] -R 6999:localhost:5901
or
ssh -R 6999:localhost:5901 [email protected]
  • [email protected] = SSH host to connect to
  • -R = Option to enable remote port forwarding
  • 6999 =Port on the remote host
  • localhost = Host server to connect to (the client PC, same as 127.0.0.1)
  • 5901 = Port on client PC (forwarded from the remote PC)

(Add the “-v” option at the end of the command above to view debugging messages about SSH’s connection progress)

To connect to the VNC server, enter the following into the VNC viewer:

127.0.0.1:6999

or

localhost:6999
Share
11. May 2011 · Comments Off on OpenSSH RSA Authentication for Windows and Linux · Categories: Networking · Tags: Linux, Windows
Last updated on 08/27/2020

This guide demonstrates how to setup automatic OpenSSH RSA public-key authentication for Windows (using OpenSSH v3.8.1p1-1) and Linux (using OpenSSH v5.3p1) PCs currently working with password authentication on a local network. The information for this guide was tested on PCs with WinXP and Lubuntu and may be applicable to other versions of Linux and Windows. You will need physical access to both PCs.

rsakeys

Public-key Cryptography

Public-key cryptography uses of a pair of matching keys, a public key and a private key, which are created at the same time using a key generation utility (ssh-keygen.exe is the key generation utility used in OpenSSH). A public key can be known to anyone and is used to encrypt data. The only way to decrypt data encrypted with the public key is with the matching private key. Although the two keys are related, a private key can’t be created from its matching public key. Public-key cryptography is widely used for public-key authentication to enable secure logins to servers without passwords and for digital or electronic signatures, and for certifying the authenticity of data signed by the private key.

The importance for using pubic key authentication can be summed up in this statement from the Ubuntu help pages: “If your SSH server is visible over the Internet, you should use public key authentication instead of passwords if at all possible. If you don’t think it’s important, try logging all of the malicious login attempts you get for the next week. My computer – a perfectly ordinary desktop PC – had over 4,000 attempts to guess my password and almost 2,500 break-in attempts in the last week alone.”

OpenSSH Public-key Authentication

OpenSSH can use either the RSA or DSA algorithms for public-key authentication. RSA stands for Rivest, Shamir and Adleman, the last names of the MIT team members who developed it. DSA stands for Digital Signature Algorithm, a US Government standard proposed by the National Institute of Standards and Technology. Although there are arguments for and against using one or the other, RSA is often the preferred choice because of its verification speed and key strength. See What is better for GPG keys – RSA or DSA? for a discussion on on this topic.

Steps for RSA Public-key Authentication

The following steps will setup RSA public-key authentication keys without a passphrase to enable automatic logins between Linux to Windows PCs on a local network. The instructions will be similar to setting up public-key authentication on remote hosts, except that SSH port 22 (if using the default port) must be forwarded to access remote servers from behind a router. When creating keys without a passphrase, as in this guide, make sure to place the public key on trusted hosts as it’s possible to compromise the remote computer should your private key fall into the wrong hands.

From the Windows PC

Step 1 – Generate Public Keys for the Windows PC

On the Windows PC, open a CMD window and type in the following command and hit ENTER to create a RSA key of 2048-bits (the default). The -t option specifies the type of key:

ssh-keygen -t rsa

Note: If you get a command is not recognized error, your path is incorrect. In this case, change to the bin folder where OpenSHH is installed to run the command.

When the command is executed, you will be prompted for a location to save the keys, and then for a passphrase as shown below. Hit ENTER to accept the default locations and to set NO passphrase.

Output:

Generating public/private rsa key pair
Enter file in which to save the key (/home/username/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/username/.ssh/id_rsa
Your public key has been saved in /home/username/.ssh/id_rsa.pub

The public key will be saved as .ssh/id_rsa.pub and your private key saved as .ssh/id_rsa in your home folder. The home directory was setup for the user(s) when OpenSSH was installed and configured.

Step 2 – Transfer Public Key to Linux PC

For the public key to be usable, it must be appended to the .ssh/authorized_keys file on the Linux computer and/or on other hosts you log into. If an authorized_keys file does not exist in your Linux computer’s home .ssh directory, create it. Also create a directory named “otherkeys“. The public key (ending in .pub) should be copied to “/home/username/.ssh/otherkeys” on the Linux computer using a USB drive, another medium, or remotely through Windows file sharing, SCP, or with SSH if it’s already working. Make sure to only copy the key and not move it.

After transferring the public key, at the Linux PC, open a terminal window or remotely connect to it and navigate to the .ssh folder in your home directory, and append the public key using the command below:

cat otherkeys/id_rsa.pub >> authorized_keys

Note: the key can also be cut and pasted into the authorized_keys file using a text editor

OR – remotely copying and appending the key with SCP and SSH

To remotely copy the public key to the Linux PC using SCP, enter the following in a command window. Note that there is no command for appending to a file using SCP. You will be asked for your password to use SCP remotely from the Windows PC:

scp ~/.ssh/id_rsa.pub [email protected]:/.ssh/otherkeys/

log in to the Linux PC with SSH, cd to the .ssh folder and execute the following command to append the key:

cat ~/.ssh/otherkeys/id_rsa.pub >> authorized_keys

Step 3 – Edit sshd_config

Open a command window and try to authenticate automatically to the Linux PC from the Windows PC using SSH. Make sure the SSH server was started on the Linux PC. It should work. If not, continue with the rest of this step and then recheck.

To troubleshoot the SSH public-key cryptography authentication processes, you can use the verbose option switch (-v) in the ssh command when logging in:

ssh -v [email protected]

If authentication didn’t work, goto the Linux PC and check that the permissions of the .ssh directory are set to octal 700. If not, use the following command from the Linux PC to change it:

# chmod 700 ~/.ssh/authorized_keys

If error messages were observed relating to the known_hosts file, find and delete the entries in the known_hosts file in the user .ssh directory of the Windows PC.  The entries causing the errors will be numbered in the error message. After deleting the offending entry in the known_hosts file, test again to determine whether you can log onto the Linux PC without using a password.

After verifying you can log into the Linux PC without using a password, password authentication will still work should RSA not work for any reason, which is a security vulnerability. Password authentication can be turned off completely by changing the following entries in the etc/ssh/sshd_config file on the Linux PC. To use RSA authentication exclusively, make the following changes to the sshd_config to force public-key authentication and disable password authentication:

PasswordAuthentication no
PubkeyAuthentication yes
RSAAuthentication yes

After saving the file, restart the Linux PC SSH server using sudo /etc/init.d/ssh restart from a terminal on the Linux PC before logging in.

____________________________________________________________________________________

From the Linux PC

The steps are essentially the same as the previous steps with a few minor differences from the previous instructions

Step 1 – Generate Public Keys for the Linux Computer

From the Linux PC, open a terminal and type in the following command and hit ENTER to create a RSA key of 2048-bits (the default). The -t option specifies the type of key:

ssh-keygen -t rsa

When the command is executed, you will be prompted for a location to save the keys, and then for a passphrase as shown below. Hit ENTER to accept the default locations and to set NO passphrase.

Output:

Generating public/private rsa key pair
Enter file in which to save the key (/home/username/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/username/.ssh/id_rsa
Your public key has been saved in /home/username/.ssh/id_rsa.pub

The public key will be saved as .ssh/id_rsa.pub and your private key saved as .ssh/id_rsa in your home folder.

Step 2 – Transfer Public Key to Windows PC

For the public key to be usable, it must be appended to the .ssh/authorized_keys file on the Windows computer, other Linux PCs, and/or other hosts you log into. If the authorized_keys file does not exist in the user’s Windows .ssh directory, create it. Also create a directory named “otherkeys“. The public key (ending in .pub) should be copied to “\home\username\.ssh\otherkeys” on the Windows computer using a USB drive, another medium, or remotely with file sharing, SCP, or with SSH if it’s already working. Make sure to only copy the key and not move it.

After transferring the public key, at the Windows PC, navigate to the .ssh folder in your home directory, and append the public key to the authorized_keys file using the command below:

copy /b authorized_keys + otherkeys\id_rsa.pub authorized_keys

Note: the key can also be cut and pasted into the authorized_keys file using a text editor

OR – remotely copy the key using SCP and append it locally

To remotely copy the public key from the Linux PC to the Windows PC with SCP, enter the following in a terminal window. Note that there is no command for appending to a file using SCP. You will be asked for your password to use SCP remotely from the Linux PC. (Note that Windows doesn’t provide a way to easily append the public key remotely to the authorized_key file from the command-line)

scp ~/.ssh/id_rsa.pub [email protected]:.ssh/otherkeys/

This copies the public key to the otherkeys folder.

Physically log into the Windows PC and use an editor such as notepad or another app to append the key into the authorized_keys file.

OR – remotely copy the key using SCP to overwrite the authorized_keys file (caution: this overwrites the authorized_keys file. Use only if the authorized_keys file is empty or if it doesn’t matter if previous content is lost!)

execute the following to overwrite the authorized_keys file with your public key:

scp ~/.ssh/id_rsa.pub [email protected]:.ssh/authorized_keys

Step 3 – Edit sshd_config

In a terminal window try to log into the Windows PC with public-key authentication using SSH. Make sure the SSH server was started on the Windows PC. It should work. If not, continue with the rest of this step and then recheck.

To troubleshoot the SSH public-key cryptography authentication processes, you can use the verbose option switch (-v) in the ssh command as follows when logging in:

ssh -v [email protected]

If error messages errors were observed relating to the known_hosts file, find and delete those entries in the known_hosts file in the user .ssh directory in the Linux PC before continuing. The entries causing the errors will be numbered in the error message.

After deleting the offending entry in the known_hosts file, test again to determine whether you can log onto the Windows PC without using a password.

After verifying you can log into the Windows PC without using a password, password authentication will still work should RSA not work for any reason, which is also a security vulnerability. Password authentication can be turned off completely by changing the following entries in the OpenSSH\etc\sshd_config file on the Windows PC. To use RSA authentication exclusively, make the following changes to the sshd_config file to force public-key authentication and disable password authentication:

Note: If you still are unable to log in with pubic-key authentication at this point, do not make the following changes to the sshd_config file to force public-key authentication since you may need to login locally using your password with tools such as WinSCP. See below troubleshooting procedures:

StrictModes no
PasswordAuthentication no
PubkeyAuthentication yes
RSAAuthentication yes

After saving the sshd_config file, restart the Windows PC SSH server first by stopping it using net stop opensshd and then restarting it using net start opensshd in a command window on the Windows PC to allow the config file to take effect before logging in.

If public-key authentication still doesn’t work, the most likely cause is that that the read/write/access permissions for the .ssh directory or for OpenSSH for the Windows PC are incorrect. See the below troubleshooting procedures below for further information.

Troubleshooting Windows OpenSSH server issues:

File permissions issues are a notorious problem for getting public-key authentication to work for OpenSSH on Windows. It’s probably the most confusing and most difficult issue to resolve. After much research and troubleshooting, I got it to work following this source from osdir.com. However, it’s uncertain whether it was one, all, or a combination of the suggestions that fixed the problem. In any case, below is a summary of the suggestions and how they were followed.

The tool used to change file permissions for the instructions below was WinSCP, with 127.0.0.1 as the host name and SFTP as the protocol (see screenshot below).

WinSCP session screen

Permission changes were made using the properties window as shown in the screenshot below:

winscp properties

Here are the suggestions from osdir.com and how each was followed. Suggestions are preceded by an asterisk “*” and how the suggestions were followed are in bold :

*Change ownership of OpenSSH folder/subfolders to Administrators using Windows Explorer – Performed this for the folder and all subfolders using WinSCP.

*Grant Administrators full control of the OpenSSH folder – Same as above using Octal 0700

*From a command prompt, type “cacls c:\program files\openssh /t /e /c /g Administrators:F” * – Performed this for the c:\ssh folder, which was the OpenSSH folder on my PC.

Edit sshd_config file and set StrictModes to “no” –  Changed the StrictModes entry to “no” and saved the file

*Under the user’s profile, grant Administrators (and only Administrators) full control of the .ssh folder and files – Did this for all folders and files for .ssh in the user directory (C:\Documents and Settings\user\.ssh).

*If this folder does not exist, it can be created by establishing an SSH connection to another box – Skipped. The .ssh file already existed

*On clients only, copy the private RSA key to the local .ssh folder and name it “id_rsa” – Skipped. The private keys already existed.

*Copy the client’s public RSA key to the desired server(s) by adding it to an “authorized_keys” text file located under the server’s .ssh folder – Skipped. Done previously.

* To use publickey authentication, use the SSH command line switch “-o PreferredAuthentications=publickey”. Alternately, you can modify the ssh_config file to make this the default – Skipped.

If the above instructions worked:

Decide whether to use RSA authentication exclusively. If so, edit the sshd_config file per the instructions above.

Note: many instructions on various web sites suggest copying public keys to the user’s .ssh directory on the server. If you do, make sure to place them in a separate folder such as a otherkeys folder or another name such as username_key since existing public keys (id_rsa.pub) will be overwritten if multiple PCs are used to access the same machine. 

Share
03. May 2011 · Comments Off on Automate Encrypted VNC Sessions with SSVNC · Categories: Networking · Tags: Linux, Windows
Last updated on 04/17/2021

VNC is one of many protocols used to share desktops between Linux and Windows PCs (see this Wikipedia entry for a comparison of various remote desktop software packages). Although a number of VNC (Virtual Network Computing) servers include some type of built-in encryption, most do not. In addition, many VNC client/viewers tend to be basic, so they generally don’t include any built-in encryption support. For both aforementioned situations, SSH tunneling can be used to secure sessions between VNC servers and the most basic VNC client/viewers, regardless of any built-in protocols. However, using SSH to encrypt VNC communications can be a manually intensive and multi-step process requiring starting up SSH and VNC servers and configuring SSH and VNC clients for local or remote port forwarding.

An Enhanced TightVNC Viewer, SSVNC, is a free multi-platform SSH/SSL VNC viewer that automates this process. It’s also compatible with a wide range of VNC servers. In fact, the SSVNC web site states that SSVNC works with nearly any VNC Server host running SSHD and those running an SSL tunnel, including VeNCrypt SSL/TLS and Vino/ANONTLS encryption extensions to VNC on Unix, Mac OS X, and Windows. SSVNC also works as a regular VNC viewer without encryption as well. SSVNC is available from the Ubuntu repositories and installable through the Synaptic Package Manager or apt-get, while Unix, MacOS, and Windows versions are available from the SSVNC web site and through Sourceforge.net.

SSVNC Viewer Screen

For this post, SSVNC (using the precompiled binaries) was tested on a Windows XP machine connected to TightVNC and X11VNC servers running on a Lubuntu machine and SSH tunneling enabled through the SSVNC viewer. Although this viewer is packed with features, it worked quickly and easily. Its many features are listed on the SSVNC web site.

viewer interface

Related Information:

VNC on Linux

 

Share
notice
">Bear

Bad Behavior has blocked 1904 access attempts in the last 7 days.

home