https://wiki.archlinux.org/api.php?action=feedcontributions&user=SamSpade&feedformat=atomArchWiki - User contributions [en]2024-03-29T06:21:38ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Hyper-V&diff=490330Hyper-V2017-09-16T02:26:02Z<p>SamSpade: Add NAT/PAT port forwarding example</p>
<hr />
<div>[[Category:Hypervisors]]<br />
[[ja:Hyper-V]]<br />
Hyper-V is a hypervisor that is included with some versions of Microsoft Windows. It is capable of running an Arch Linux virtual machine. Hyper-V is generally oriented toward enterprise rather than desktop use, and doesn't provide as convenient and simple of an interface as consumer VM programs like [https://www.virtualbox.org/ VirtualBox], [https://www.parallels.com/ Parallels], or [http://www.vmware.com/ VMWare]. However more recent versions and builds of Windows 10 and Windows Server 2016 include easier configuration options and better compatibility for Arch Linux. Networking features such as NAT for internal switches, multiple NATs and port forwarding have been added without the need to set up Internet Connection Sharing (ICS). Generation 2 virtual machines also now work properly for Arch Linux.<br />
<br />
== Installation ==<br />
<br />
Hyper-V is included with Windows since Windows Server 2008 as well as Windows 8, 8.1 and 10 in the Pro versions. <!-- If someone has experience with Windows Server 2008+ and knows how Hyper-V is enabled, could they add it here? --> It can be enabled from Control Panel at "Turn Windows features on or off" under "Programs and Features". Activate the "Hyper-V" checkbox, apply the change, and follow the directions on screen.<br />
<br />
== Network configuration ==<br />
<br />
First, you must configure a new virtual switch so that your virtual machine will be able to connect to the Internet. Once Hyper-V is enabled, start the Hyper-V Manager (search for it, or start it from Command Prompt with the command<br />
<br />
%windir%\system32\mmc.exe "%windir%\system32\virtmgmt.msc"<br />
<br />
=== Set up a virtual switch ===<br />
<br />
In order to connect your virtual machine to an existing network, either use an internal or external network switch (virtual network adapter). An external switch must be bound (bridged) to one of the host's existing network adapters (e.g. Ethernet or Wi-Fi). An internal switch can be used for network communication between the host and VM, without the VMs having access to the external network. Adding NAT functionality to an internal switch makes the host act as a router for the VMs, enabling the VMs access to the external network.<br />
<br />
Not all networking features (e.g. NAT configuration) can be set up through the Hyper-V Manager GUI. Using PowerShell, run as an Administrator, permits better control over configuration.<br />
<br />
==== External switch ====<br />
<br />
To create an external switch, in the right sidebar, select "Virtual Switch Manager...". In the left sidebar of the dialog that opens, choose "New virtual network switch". Under "What type of virtual switch do you want to create?", select "External", then "Create Virtual Switch". Type a new name for the virtual switch. Under "External network", choose the network adapter to bind with the external switch.<br />
<br />
You will be prompted about network disruption; continue and your network will be briefly disconnected as the switch is configured.<br />
<br />
Using PowerShell (run as Administrator), the above steps can be done with the following:<br />
# Get a list of the network adapters in the host. In a laptop you should typically see 'Ethernet' and 'Wi-Fi'<br />
PS C:\WINDOWS\system32> Get-NetAdapter<br />
<br />
# Create the external switch with a name of VM-External-Switch, bound to the network adapter named {{ic|Wi-Fi}} retrieved from the previous command<br />
PS C:\WINDOWS\system32> New-VMSwitch -Name "VM-External-Switch" -AllowManagementOS $True -NetAdapterName "Wi-Fi"<br />
<br />
On an Arch Linux VM, choosing the external switch as the VM network adapter effectively bridges the Windows host's network adapter with the VM's {{ic|eth0}} interface. The interface can then be set up in Arch Linux through the usual ways (systemd-networkd, netctl, etc.) with a static IP address or with DHCP. The VM will act just like another host in the external network.<br />
<br />
For example, if you want the Arch Linux VM to use a static IP, and the Windows host is configured as {{ic|192.168.0.100/24}}, then the Arch Linux VM interface should be configured like {{ic|192.168.0.101/24}}, with the same gateway and DNS servers as set up in the host.<br />
<br />
If using DHCP for the VM, the IP address will be assigned by the DHCP server in the external network.<br />
<br />
==== Internal switch ====<br />
<br />
To create an internal switch, follow the same steps as the external switch, however replace the relevant choices for 'internal switch'. Starting with Windows 10 Anniversary Update (Version 1607, OS Build 14393), native NAT support for internal switches was added to Hyper-V. For earlier versions, Internet Connection Sharing (ICS) can be used to enable network access for virtual machines on internal switches.<br />
<br />
To find out which version and build of Windows you are using, on a command prompt or PowerShell, run:<br />
> winver<br />
<br />
Using PowerShell (run as Administrator), an internal switch can be created with the following commands:<br />
# Create the internal switch with a name of VM-Internal-Switch<br />
PS C:\WINDOWS\system32> New-VMSwitch -Name "VM-Internal-Switch" -SwitchType Internal<br />
<br />
# Verify that the internal switch was created<br />
PS C:\WINDOWS\system32> Get-VMSwitch<br />
<br />
# Get the ifIndex of the newly created internal switch, usually named 'vEthernet (name)'<br />
PS C:\WINDOWS\system32> Get-NetAdapter<br />
<br />
# Set the IP address of the internal switch, noting the ifIndex retrieved from the previous command.<br />
# In this example, the network address of the internal switch is 192.168.3.0/24, and the ifIndex is 50.<br />
PS C:\WINDOWS\system32> New-NetIPAddress -IPAddress 192.168.3.1 -PrefixLength 24 -InterfaceIndex 50<br />
<br />
# The VMs using the internal switch must use static IP addresses, such as 192.168.3.2/24.<br />
# Support for DHCP in internal switches is not included in current Windows versions (as of Version 1703, OS Build 15063).<br />
<br />
With the above steps, the host and VMs can already communicate with each other since they will be on the same virtual network (192.168.3.0/24). The VMs however will not be able to access the external network until NAT or ICS is configured.<br />
<br />
On Windows 10 build 14393 or later, internal switches can be configured for NAT and port forwarding:<br />
# Create the NAT with IP address of the internal switch<br />
PS C:\WINDOWS\system32> New-NetNat -Name "VM-NAT-Network" -InternalIPInterfaceAddressPrefix 192.168.3.1/24<br />
<br />
# Verify that the NAT was created<br />
PS C:\WINDOWS\system32> Get-NetNat<br />
<br />
# Enable SSH port forwarding on port 2222 of any interface on the host, to a VM with an IP address of 192.168.3.2/24<br />
PS C:\WINDOWS\system32> Add-NetNatStaticMapping -NatName "VM-NAT-Network" -Protocol TCP -ExternalIPAddress 0.0.0.0 -ExternalPort 2222 -InternalIPAddress 192.168.3.2 -InternalPort 22<br />
<br />
# Verify that the port forward is active<br />
PS C:\WINDOWS\system32> Get-NetNatStaticMapping<br />
<br />
Consult Microsoft's [https://docs.microsoft.com/en-us/powershell/module/netnat/ NetNat] documentation for a complete list of commands.<br />
<br />
For earlier versions and builds of Windows, Internet Connection Sharing can be used. Open Network and Sharing Settings, and Adapter Settings, where you will need to enable internet connection sharing for your internet adapter that you normally use. Once the connection can be shared, add it to a bridge together with the virtual switch that you created in the previous step.<br />
<br />
== Virtual machine creation ==<br />
<br />
In the left sidebar, select your computer under "Hyper-V Manager". In the right sidebar, select "New" > "Virtual Machine...". In New Virtual Machine Wizard, you may in general specify whichever settings you like, but some must be specifically configured.<br />
<br />
Under "Specify Generation", you may choose "Generation 1" or "Generation 2". Generation 1 virtual machines emulate a BIOS-based machine and legacy ports. Generation 2 provides a UEFI-based machine. In general, use Generation 2 unless for compatibility or portability reasons you need to use Generation 1. Also, when using Generation 2 for an Arch Linux VM, make sure to disable Secure Boot in the VM's settings under Hardware -> Security.<br />
<br />
For "Startup memory" under Assign Memory, choose enough to ensure Arch and any programs will run properly.<br />
<br />
For "Connection" under "Configure Networking", choose the virtual switch you created earlier.<br />
<br />
For "Connect Virtual Hard Disk", choose "Create a virtual hard disk", and make sure the "Size" is appropriate for your use case. The virtual hard disk is sparse, so the virtual hard disk will only use as much real storage as is necessary to store what the virtual OS has written to it.<br />
<br />
For "Installation Options", choose "Install an operating system from a bootable CD/DVD-ROM". If you are installing Arch from a disc or USB device, choose "Physical CD/DVD drive" under "Media", and select the appropriate letter. If you are installing Arch from an ISO file, select "Image file (.iso)", and select the file in the "Browse..." dialog. For Generation 2 machines, booting from a physical CD/DVD drive is not supported.<br />
<br />
== Virtual machine configuration ==<br />
<br />
Next, you need to configure the VM's settings.<br />
<br />
If you like, you can add more virtual processors to your virtual machine. This allows the virtual machine to use more than one of your processor cores, which will increase performance in many cases. If you plan to use the virtual machine intensively, you may wish to allot up to half of your processor cores. To change the number of virtual processors, select "Processor" in the left sidebar, then adjust "Number of virtual processors".<br />
<br />
Change any settings, then select "OK" to apply your changes and exit the settings dialog.<br />
<br />
== Arch installation ==<br />
<br />
Once the virtual machine is fully configured, you are ready to install Arch. In the right sidebar, select "Start", then "Connect...", and a connection window will open. The network should work automatically when the Arch installation media is running; check by using {{ic|ping}} on an address you know is responding, e.g.<br />
<br />
ping archlinux.org<br />
<br />
If no response is received, the connection is not working. If this is the case, you are probably experiencing [https://support.microsoft.com/kb/974909 a bug Microsoft has acknowledged]. You can try installing the hotfix from the Knowledge Base page, or just wait a little while and try again.<br />
<br />
In general, you may now install Arch as you would on any other system. The Generation 1 VMs are BIOS-only (no UEFI), so you must follow the BIOS-specific instructions for the various [[bootloaders]].<br />
<br />
== Post-installation ==<br />
<br />
After Arch has been installed, you can continue to configure features.<br />
<br />
First, you should shut down the VM, open the Settings dialog again, and in the left sidebar, select "DVD Drive" under "IDE Controller 1". Under "Media", choose "None". This will stop the VM from trying to boot from the install media on every start.<br />
<br />
=== Shared directories ===<br />
<br />
Files can be shared between the host and guest with very little effort. First, on the host, choose the folder you want to share with the guest, or create it. Open the Properties dialog for the folder ({{ic|alt}} + {{ic|Enter}} or right-click and choose "Properties..."). Go to the "Sharing" tab and select "Advanced Sharing...". Activate the "Share this folder" checkbox. By default, the folder will have read-only permissions, meaning the VM can read from the folder but cannot write anything to it. If you'd like to modify these permissions, select "Permissions". Here, you choose which users can access the shared folder, and what permissions they have. In general, you will probably be sharing in both directions and should check "Allow" for both "Change" and "Read".<br />
Before exiting the Properties dialog for the shared folder, note its "Network Path", which should be of the form {{ic|\\''computer name''\''folder name''}}.<br />
<br />
Next, you need to find the IP address of the host. Exit the Properties dialog, and open Command Prompt or PowerShell. Run {{ic|ipconfig}}. You should see an entry whose name ends with the name of the virtual switch you created (e.g. {{ic|Ethernet adapter vEthernet (New Virtual Switch)}}). Under this entry, look for {{ic|IPv4 Address}} and note it down.<br />
<br />
Next, you need to mount the shared folder from Arch. Boot the VM. Once it is running, you will first need to install {{Pkg|cifs-utils}}, which will allow you to mount CIFS shares (CIFS is the protocol Windows uses for shared folders). Next, you will need to decide where you will be mounting the shared folder. A reasonable choice would be somewhere in {{ic|/mnt}}, like {{ic|/mnt/Hyper-V}}.<br />
<br />
In the command to mount the share, replace any backslashes in the "Network Path" from earlier with forward slashes.<br />
<br />
# mount -t cifs [''Network Path with forward slashes''] ''mountpoint'' -o user=[''user you wish to authenticate as''],ip=[''host IP noted earlier'']<br />
<br />
You will be prompted for the password for the user you're authenticating as. You can specify the password in the command options via {{ic|1=password=''password''}}, but this isn't a good idea in terms of security as the password for the host will now be in your command history file; or if you are running the command from a script, stored in the script indefinitely. Instead, you can use a credentials file, which allows you to specify your username and password in a file with restricted access rights. It can be called anything; for an example, if it were called {{ic|.credentials}} and stored in your home directory, it would be of the following form:<br />
<br />
{{hc|~/.credentials|2=<br />
username=''username''<br />
password=''password''<br />
}}<br />
<br />
After creating the file, change the permissions to restrict read access:<br />
<br />
chmod 600 ~/.credentials<br />
<br />
Then you can add another option to the {{ic|mount}} command: {{ic|1=credentials=~/.credentials}}. Now, when mounting the share, your username and password will automatically be applied.<br />
<br />
For a more concrete example, let's say you are mounting a share with a Network Path of {{ic|\\PC\share}} at {{ic|/mnt/Hyper-V}}, where your username on the host is "John" and the host's IP is 198.123.151.23. The mount command would thus be<br />
<br />
# mount -t cifs //PC/share /mnt/Hyper-V -o credentials=~/.credentials,ip=198.123.151.23<br />
<br />
One problem with this method is that if the host's IP ever changes (e.g. it has a dynamic IP assigned via DHCP, or moves to a new network), every instance of the host's IP on the guest must be replaced. However, the {{Pkg|smbclient}} package provides {{ic|nmblookup}}, a utility which finds the IP address associated with an SMB host. Thus, in the case of the example above, you would run<br />
<br />
{{hc|nmblookup PC|2=<br />
198.123.151.23 PC<00><br />
}}<br />
<br />
You only want the IP address, so you can use {{ic|head}} and {{ic|cut}} to parse it:<br />
<br />
{{hc|nmblookup PC <nowiki>|</nowiki> head -n 1 <nowiki>|</nowiki> cut -d ' ' -f 1|2=<br />
192.123.151.23<br />
}}<br />
<br />
Then you can simply replace the IP address in the {{ic|mount}} command:<br />
<br />
# mount -t cifs //PC/share /mnt/Hyper-V -o <nowiki>credentials=~/.credentials,ip=</nowiki>"$(nmblookup PC <nowiki>|</nowiki> head -n 1 <nowiki>|</nowiki> cut -d ' ' -f 1)"<br />
<br />
More ways to mount shared folders, including automatic mounting on startup, are detailed in the [[Samba]] article.<br />
<br />
=== Xorg ===<br />
<br />
Graphical programs can easily be run via Xorg via the {{Pkg|xf86-video-fbdev}} package. Simply install it and the window manager or desktop environment you wish to use, and you should be able to start X without issue.</div>SamSpadehttps://wiki.archlinux.org/index.php?title=Hyper-V&diff=490329Hyper-V2017-09-16T01:43:59Z<p>SamSpade: Include newer support for Generation 2 machines</p>
<hr />
<div>[[Category:Hypervisors]]<br />
[[ja:Hyper-V]]<br />
Hyper-V is a hypervisor that is included with some versions of Microsoft Windows. It is capable of running an Arch Linux virtual machine. Hyper-V is generally oriented toward enterprise rather than desktop use, and doesn't provide as convenient and simple of an interface as consumer VM programs like [https://www.virtualbox.org/ VirtualBox], [https://www.parallels.com/ Parallels], or [http://www.vmware.com/ VMWare]. However more recent versions and builds of Windows 10 and Windows Server 2016 include easier configuration options and better compatibility for Arch Linux. Networking features such as NAT for internal switches, multiple NATs and port forwarding have been added without the need to set up Internet Connection Sharing (ICS). Generation 2 virtual machines also now work properly for Arch Linux.<br />
<br />
== Installation ==<br />
<br />
Hyper-V is included with Windows since Windows Server 2008 as well as Windows 8, 8.1 and 10 in the Pro versions. <!-- If someone has experience with Windows Server 2008+ and knows how Hyper-V is enabled, could they add it here? --> It can be enabled from Control Panel at "Turn Windows features on or off" under "Programs and Features". Activate the "Hyper-V" checkbox, apply the change, and follow the directions on screen.<br />
<br />
== Network configuration ==<br />
<br />
First, you must configure a new virtual switch so that your virtual machine will be able to connect to the Internet. Once Hyper-V is enabled, start the Hyper-V Manager (search for it, or start it from Command Prompt with the command<br />
<br />
%windir%\system32\mmc.exe "%windir%\system32\virtmgmt.msc"<br />
<br />
=== Set up a virtual switch ===<br />
<br />
In order to connect your virtual machine to an existing network, either use an internal or external network switch (virtual network adapter). An external switch must be bound (bridged) to one of the host's existing network adapters (e.g. Ethernet or Wi-Fi). An internal switch can be used for network communication between the host and VM, without the VMs having access to the external network. Adding NAT functionality to an internal switch makes the host act as a router for the VMs, enabling the VMs access to the external network.<br />
<br />
Not all networking features (e.g. NAT configuration) can be set up through the Hyper-V Manager GUI. Using PowerShell, run as an Administrator, permits better control over configuration.<br />
<br />
==== External switch ====<br />
<br />
To create an external switch, in the right sidebar, select "Virtual Switch Manager...". In the left sidebar of the dialog that opens, choose "New virtual network switch". Under "What type of virtual switch do you want to create?", select "External", then "Create Virtual Switch". Type a new name for the virtual switch. Under "External network", choose the network adapter to bind with the external switch.<br />
<br />
You will be prompted about network disruption; continue and your network will be briefly disconnected as the switch is configured.<br />
<br />
Using PowerShell (run as Administrator), the above steps can be done with the following:<br />
# Get a list of the network adapters in the host. In a laptop you should typically see 'Ethernet' and 'Wi-Fi'<br />
PS C:\WINDOWS\system32> Get-NetAdapter<br />
<br />
# Create the external switch with a name of VM-External-Switch, bound to the network adapter named {{ic|Wi-Fi}} retrieved from the previous command<br />
PS C:\WINDOWS\system32> New-VMSwitch -Name "VM-External-Switch" -AllowManagementOS $True -NetAdapterName "Wi-Fi"<br />
<br />
On an Arch Linux VM, choosing the external switch as the VM network adapter effectively bridges the Windows host's network adapter with the VM's {{ic|eth0}} interface. The interface can then be set up in Arch Linux through the usual ways (systemd-networkd, netctl, etc.) with a static IP address or with DHCP. The VM will act just like another host in the external network.<br />
<br />
For example, if you want the Arch Linux VM to use a static IP, and the Windows host is configured as {{ic|192.168.0.100/24}}, then the Arch Linux VM interface should be configured like {{ic|192.168.0.101/24}}, with the same gateway and DNS servers as set up in the host.<br />
<br />
If using DHCP for the VM, the IP address will be assigned by the DHCP server in the external network.<br />
<br />
==== Internal switch ====<br />
<br />
To create an internal switch, follow the same steps as the external switch, however replace the relevant choices for 'internal switch'. Starting with Windows 10 Anniversary Update (Version 1607, OS Build 14393), native NAT support for internal switches was added to Hyper-V. For earlier versions, Internet Connection Sharing (ICS) can be used to enable network access for virtual machines on internal switches.<br />
<br />
To find out which version and build of Windows you are using, on a command prompt or PowerShell, run:<br />
> winver<br />
<br />
Using PowerShell (run as Administrator), an internal switch can be created with the following commands:<br />
# Create the internal switch with a name of VM-Internal-Switch<br />
PS C:\WINDOWS\system32> New-VMSwitch -Name "VM-Internal-Switch" -SwitchType Internal<br />
<br />
# Verify that the internal switch was created<br />
PS C:\WINDOWS\system32> Get-VMSwitch<br />
<br />
# Get the ifIndex of the newly created internal switch, usually named 'vEthernet (name)'<br />
PS C:\WINDOWS\system32> Get-NetAdapter<br />
<br />
# Set the IP address of the internal switch, noting the ifIndex retrieved from the previous command.<br />
# In this example, the network address of the internal switch is 192.168.3.0/24, and the ifIndex is 50.<br />
PS C:\WINDOWS\system32> New-NetIPAddress -IPAddress 192.168.3.1 -PrefixLength 24 -InterfaceIndex 50<br />
<br />
# The VMs using the internal switch must use static IP addresses, such as 192.168.3.2/24.<br />
# Support for DHCP in internal switches is not included in current Windows versions (as of Version 1703, OS Build 15063).<br />
<br />
With the above steps, the host and VMs can already communicate with each other since they will be on the same virtual network (192.168.3.0/24). The VMs however will not be able to access the external network until NAT or ICS is configured.<br />
<br />
On Windows 10 build 14393 or later, internal switches can be configured for NAT:<br />
# Create the NAT with IP address of the internal switch<br />
PS C:\WINDOWS\system32> New-NetNat -Name "VM-NAT-Network" -InternalIPInterfaceAddressPrefix 192.168.3.1/24<br />
<br />
# Verify that the NAT was created<br />
PS C:\WINDOWS\system32> Get-NetNat<br />
<br />
Consult Microsoft's [https://docs.microsoft.com/en-us/powershell/module/netnat/ NetNat] documentation for a complete list of commands.<br />
<br />
For earlier versions and builds of Windows, Internet Connection Sharing can be used. Open Network and Sharing Settings, and Adapter Settings, where you will need to enable internet connection sharing for your internet adapter that you normally use. Once the connection can be shared, add it to a bridge together with the virtual switch that you created in the previous step.<br />
<br />
== Virtual machine creation ==<br />
<br />
In the left sidebar, select your computer under "Hyper-V Manager". In the right sidebar, select "New" > "Virtual Machine...". In New Virtual Machine Wizard, you may in general specify whichever settings you like, but some must be specifically configured.<br />
<br />
Under "Specify Generation", you may choose "Generation 1" or "Generation 2". Generation 1 virtual machines emulate a BIOS-based machine and legacy ports. Generation 2 provides a UEFI-based machine. In general, use Generation 2 unless for compatibility or portability reasons you need to use Generation 1. Also, when using Generation 2 for an Arch Linux VM, make sure to disable Secure Boot in the VM's settings under Hardware -> Security.<br />
<br />
For "Startup memory" under Assign Memory, choose enough to ensure Arch and any programs will run properly.<br />
<br />
For "Connection" under "Configure Networking", choose the virtual switch you created earlier.<br />
<br />
For "Connect Virtual Hard Disk", choose "Create a virtual hard disk", and make sure the "Size" is appropriate for your use case. The virtual hard disk is sparse, so the virtual hard disk will only use as much real storage as is necessary to store what the virtual OS has written to it.<br />
<br />
For "Installation Options", choose "Install an operating system from a bootable CD/DVD-ROM". If you are installing Arch from a disc or USB device, choose "Physical CD/DVD drive" under "Media", and select the appropriate letter. If you are installing Arch from an ISO file, select "Image file (.iso)", and select the file in the "Browse..." dialog. For Generation 2 machines, booting from a physical CD/DVD drive is not supported.<br />
<br />
== Virtual machine configuration ==<br />
<br />
Next, you need to configure the VM's settings.<br />
<br />
If you like, you can add more virtual processors to your virtual machine. This allows the virtual machine to use more than one of your processor cores, which will increase performance in many cases. If you plan to use the virtual machine intensively, you may wish to allot up to half of your processor cores. To change the number of virtual processors, select "Processor" in the left sidebar, then adjust "Number of virtual processors".<br />
<br />
Change any settings, then select "OK" to apply your changes and exit the settings dialog.<br />
<br />
== Arch installation ==<br />
<br />
Once the virtual machine is fully configured, you are ready to install Arch. In the right sidebar, select "Start", then "Connect...", and a connection window will open. The network should work automatically when the Arch installation media is running; check by using {{ic|ping}} on an address you know is responding, e.g.<br />
<br />
ping archlinux.org<br />
<br />
If no response is received, the connection is not working. If this is the case, you are probably experiencing [https://support.microsoft.com/kb/974909 a bug Microsoft has acknowledged]. You can try installing the hotfix from the Knowledge Base page, or just wait a little while and try again.<br />
<br />
In general, you may now install Arch as you would on any other system. The Generation 1 VMs are BIOS-only (no UEFI), so you must follow the BIOS-specific instructions for the various [[bootloaders]].<br />
<br />
== Post-installation ==<br />
<br />
After Arch has been installed, you can continue to configure features.<br />
<br />
First, you should shut down the VM, open the Settings dialog again, and in the left sidebar, select "DVD Drive" under "IDE Controller 1". Under "Media", choose "None". This will stop the VM from trying to boot from the install media on every start.<br />
<br />
=== Shared directories ===<br />
<br />
Files can be shared between the host and guest with very little effort. First, on the host, choose the folder you want to share with the guest, or create it. Open the Properties dialog for the folder ({{ic|alt}} + {{ic|Enter}} or right-click and choose "Properties..."). Go to the "Sharing" tab and select "Advanced Sharing...". Activate the "Share this folder" checkbox. By default, the folder will have read-only permissions, meaning the VM can read from the folder but cannot write anything to it. If you'd like to modify these permissions, select "Permissions". Here, you choose which users can access the shared folder, and what permissions they have. In general, you will probably be sharing in both directions and should check "Allow" for both "Change" and "Read".<br />
Before exiting the Properties dialog for the shared folder, note its "Network Path", which should be of the form {{ic|\\''computer name''\''folder name''}}.<br />
<br />
Next, you need to find the IP address of the host. Exit the Properties dialog, and open Command Prompt or PowerShell. Run {{ic|ipconfig}}. You should see an entry whose name ends with the name of the virtual switch you created (e.g. {{ic|Ethernet adapter vEthernet (New Virtual Switch)}}). Under this entry, look for {{ic|IPv4 Address}} and note it down.<br />
<br />
Next, you need to mount the shared folder from Arch. Boot the VM. Once it is running, you will first need to install {{Pkg|cifs-utils}}, which will allow you to mount CIFS shares (CIFS is the protocol Windows uses for shared folders). Next, you will need to decide where you will be mounting the shared folder. A reasonable choice would be somewhere in {{ic|/mnt}}, like {{ic|/mnt/Hyper-V}}.<br />
<br />
In the command to mount the share, replace any backslashes in the "Network Path" from earlier with forward slashes.<br />
<br />
# mount -t cifs [''Network Path with forward slashes''] ''mountpoint'' -o user=[''user you wish to authenticate as''],ip=[''host IP noted earlier'']<br />
<br />
You will be prompted for the password for the user you're authenticating as. You can specify the password in the command options via {{ic|1=password=''password''}}, but this isn't a good idea in terms of security as the password for the host will now be in your command history file; or if you are running the command from a script, stored in the script indefinitely. Instead, you can use a credentials file, which allows you to specify your username and password in a file with restricted access rights. It can be called anything; for an example, if it were called {{ic|.credentials}} and stored in your home directory, it would be of the following form:<br />
<br />
{{hc|~/.credentials|2=<br />
username=''username''<br />
password=''password''<br />
}}<br />
<br />
After creating the file, change the permissions to restrict read access:<br />
<br />
chmod 600 ~/.credentials<br />
<br />
Then you can add another option to the {{ic|mount}} command: {{ic|1=credentials=~/.credentials}}. Now, when mounting the share, your username and password will automatically be applied.<br />
<br />
For a more concrete example, let's say you are mounting a share with a Network Path of {{ic|\\PC\share}} at {{ic|/mnt/Hyper-V}}, where your username on the host is "John" and the host's IP is 198.123.151.23. The mount command would thus be<br />
<br />
# mount -t cifs //PC/share /mnt/Hyper-V -o credentials=~/.credentials,ip=198.123.151.23<br />
<br />
One problem with this method is that if the host's IP ever changes (e.g. it has a dynamic IP assigned via DHCP, or moves to a new network), every instance of the host's IP on the guest must be replaced. However, the {{Pkg|smbclient}} package provides {{ic|nmblookup}}, a utility which finds the IP address associated with an SMB host. Thus, in the case of the example above, you would run<br />
<br />
{{hc|nmblookup PC|2=<br />
198.123.151.23 PC<00><br />
}}<br />
<br />
You only want the IP address, so you can use {{ic|head}} and {{ic|cut}} to parse it:<br />
<br />
{{hc|nmblookup PC <nowiki>|</nowiki> head -n 1 <nowiki>|</nowiki> cut -d ' ' -f 1|2=<br />
192.123.151.23<br />
}}<br />
<br />
Then you can simply replace the IP address in the {{ic|mount}} command:<br />
<br />
# mount -t cifs //PC/share /mnt/Hyper-V -o <nowiki>credentials=~/.credentials,ip=</nowiki>"$(nmblookup PC <nowiki>|</nowiki> head -n 1 <nowiki>|</nowiki> cut -d ' ' -f 1)"<br />
<br />
More ways to mount shared folders, including automatic mounting on startup, are detailed in the [[Samba]] article.<br />
<br />
=== Xorg ===<br />
<br />
Graphical programs can easily be run via Xorg via the {{Pkg|xf86-video-fbdev}} package. Simply install it and the window manager or desktop environment you wish to use, and you should be able to start X without issue.</div>SamSpadehttps://wiki.archlinux.org/index.php?title=Hyper-V&diff=490324Hyper-V2017-09-16T01:02:26Z<p>SamSpade: Expanded steps creating internal switch and added PowerShell commands</p>
<hr />
<div>[[Category:Hypervisors]]<br />
[[ja:Hyper-V]]<br />
Hyper-V is a hypervisor that is included with some versions of Microsoft Windows. It is capable of running an Arch Linux virtual machine. Hyper-V is generally oriented toward enterprise rather than desktop use, and doesn't provide as convenient and simple of an interface as consumer VM programs like [https://www.virtualbox.org/ VirtualBox], [https://www.parallels.com/ Parallels], or [http://www.vmware.com/ VMWare]. However more recent versions and builds of Windows 10 and Windows Server 2016 include easier configuration options and better compatibility for Arch Linux. Networking features such as NAT for internal switches, multiple NATs and port forwarding have been added without the need to set up Internet Connection Sharing (ICS). Generation 2 virtual machines also now work properly for Arch Linux.<br />
<br />
== Installation ==<br />
<br />
Hyper-V is included with Windows since Windows Server 2008 as well as Windows 8, 8.1 and 10 in the Pro versions. <!-- If someone has experience with Windows Server 2008+ and knows how Hyper-V is enabled, could they add it here? --> It can be enabled from Control Panel at "Turn Windows features on or off" under "Programs and Features". Activate the "Hyper-V" checkbox, apply the change, and follow the directions on screen.<br />
<br />
== Network configuration ==<br />
<br />
First, you must configure a new virtual switch so that your virtual machine will be able to connect to the Internet. Once Hyper-V is enabled, start the Hyper-V Manager (search for it, or start it from Command Prompt with the command<br />
<br />
%windir%\system32\mmc.exe "%windir%\system32\virtmgmt.msc"<br />
<br />
=== Set up a virtual switch ===<br />
<br />
In order to connect your virtual machine to an existing network, either use an internal or external network switch (virtual network adapter). An external switch must be bound (bridged) to one of the host's existing network adapters (e.g. Ethernet or Wi-Fi). An internal switch can be used for network communication between the host and VM, without the VMs having access to the external network. Adding NAT functionality to an internal switch makes the host act as a router for the VMs, enabling the VMs access to the external network.<br />
<br />
Not all networking features (e.g. NAT configuration) can be set up through the Hyper-V Manager GUI. Using PowerShell, run as an Administrator, permits better control over configuration.<br />
<br />
==== External switch ====<br />
<br />
To create an external switch, in the right sidebar, select "Virtual Switch Manager...". In the left sidebar of the dialog that opens, choose "New virtual network switch". Under "What type of virtual switch do you want to create?", select "External", then "Create Virtual Switch". Type a new name for the virtual switch. Under "External network", choose the network adapter to bind with the external switch.<br />
<br />
You will be prompted about network disruption; continue and your network will be briefly disconnected as the switch is configured.<br />
<br />
Using PowerShell (run as Administrator), the above steps can be done with the following:<br />
# Get a list of the network adapters in the host. In a laptop you should typically see 'Ethernet' and 'Wi-Fi'<br />
PS C:\WINDOWS\system32> Get-NetAdapter<br />
<br />
# Create the external switch with a name of VM-External-Switch, bound to the network adapter named {{ic|Wi-Fi}} retrieved from the previous command<br />
PS C:\WINDOWS\system32> New-VMSwitch -Name "VM-External-Switch" -AllowManagementOS $True -NetAdapterName "Wi-Fi"<br />
<br />
On an Arch Linux VM, choosing the external switch as the VM network adapter effectively bridges the Windows host's network adapter with the VM's {{ic|eth0}} interface. The interface can then be set up in Arch Linux through the usual ways (systemd-networkd, netctl, etc.) with a static IP address or with DHCP. The VM will act just like another host in the external network.<br />
<br />
For example, if you want the Arch Linux VM to use a static IP, and the Windows host is configured as {{ic|192.168.0.100/24}}, then the Arch Linux VM interface should be configured like {{ic|192.168.0.101/24}}, with the same gateway and DNS servers as set up in the host.<br />
<br />
If using DHCP for the VM, the IP address will be assigned by the DHCP server in the external network.<br />
<br />
==== Internal switch ====<br />
<br />
To create an internal switch, follow the same steps as the external switch, however replace the relevant choices for 'internal switch'. Starting with Windows 10 Anniversary Update (Version 1607, OS Build 14393), native NAT support for internal switches was added to Hyper-V. For earlier versions, Internet Connection Sharing (ICS) can be used to enable network access for virtual machines on internal switches.<br />
<br />
To find out which version and build of Windows you are using, on a command prompt or PowerShell, run:<br />
> winver<br />
<br />
Using PowerShell (run as Administrator), an internal switch can be created with the following commands:<br />
# Create the internal switch with a name of VM-Internal-Switch<br />
PS C:\WINDOWS\system32> New-VMSwitch -Name "VM-Internal-Switch" -SwitchType Internal<br />
<br />
# Verify that the internal switch was created<br />
PS C:\WINDOWS\system32> Get-VMSwitch<br />
<br />
# Get the ifIndex of the newly created internal switch, usually named 'vEthernet (name)'<br />
PS C:\WINDOWS\system32> Get-NetAdapter<br />
<br />
# Set the IP address of the internal switch, noting the ifIndex retrieved from the previous command.<br />
# In this example, the network address of the internal switch is 192.168.3.0/24, and the ifIndex is 50.<br />
PS C:\WINDOWS\system32> New-NetIPAddress -IPAddress 192.168.3.1 -PrefixLength 24 -InterfaceIndex 50<br />
<br />
# The VMs using the internal switch must use static IP addresses, such as 192.168.3.2/24.<br />
# Support for DHCP in internal switches is not included in current Windows versions (as of Version 1703, OS Build 15063).<br />
<br />
With the above steps, the host and VMs can already communicate with each other since they will be on the same virtual network (192.168.3.0/24). The VMs however will not be able to access the external network until NAT or ICS is configured.<br />
<br />
On Windows 10 build 14393 or later, internal switches can be configured for NAT:<br />
# Create the NAT with IP address of the internal switch<br />
PS C:\WINDOWS\system32> New-NetNat -Name "VM-NAT-Network" -InternalIPInterfaceAddressPrefix 192.168.3.1/24<br />
<br />
# Verify that the NAT was created<br />
PS C:\WINDOWS\system32> Get-NetNat<br />
<br />
Consult Microsoft's [https://docs.microsoft.com/en-us/powershell/module/netnat/ NetNat] documentation for a complete list of commands.<br />
<br />
For earlier versions and builds of Windows, Internet Connection Sharing can be used. Open Network and Sharing Settings, and Adapter Settings, where you will need to enable internet connection sharing for your internet adapter that you normally use. Once the connection can be shared, add it to a bridge together with the virtual switch that you created in the previous step.<br />
<br />
== Virtual machine creation ==<br />
<br />
In the left sidebar, select "PC" under "Hyper-V Manager". In the right sidebar, select "New" > "Virtual Machine...". In New Virtual Machine Wizard, you may in general specify whichever settings you like, but some must be specifically configured. <br />
<br />
Under "Specify Generation", you must choose "Generation 1", as Arch does not work properly in Generation 2 Hyper-V VMs. <br />
<br />
For "Startup memory" under Assign Memory, choose enough to ensure Arch and any programs will run properly.<br />
<br />
For "Connection" under "Configure Networking", choose the virtual switch you created earlier.<br />
<br />
For "Connect Virtual Hard Disk", choose "Create a virtual hard disk", and make sure the "Size" is appropriate for your use case. The virtual hard disk is sparse, so the virtual hard disk will only use as much real storage as is necessary to store what the virtual OS has written to it.<br />
<br />
For "Installation Options", choose "Install an operating system from a bootable CD/DVD-ROM". If you are installing Arch from a disc or USB device, choose "Physical CD/DVD drive" under "Media", and select the appropriate letter. If you are installing Arch from an ISO file, select "Image file (.iso)", and select the file in the "Browse..." dialog.<br />
<br />
== Virtual machine configuration ==<br />
<br />
Next, you need to configure the VM's settings.<br />
<br />
If you like, you can add more virtual processors to your virtual machine. This allows the virtual machine to use more than one of your processor cores, which will increase performance in many cases. If you plan to use the virtual machine intensively, you may wish to allot up to half of your processor cores. To change the number of virtual processors, select "Processor" in the left sidebar, then adjust "Number of virtual processors".<br />
<br />
Change any settings, then select "OK" to apply your changes and exit the settings dialog.<br />
<br />
== Arch installation ==<br />
<br />
Once the virtual machine is fully configured, you are ready to install Arch. In the right sidebar, select "Start", then "Connect...", and a connection window will open. The network should work automatically when the Arch installation media is running; check by using {{ic|ping}} on an address you know is responding, e.g.<br />
<br />
ping archlinux.org<br />
<br />
If no response is received, the connection is not working. If this is the case, you are probably experiencing [https://support.microsoft.com/kb/974909 a bug Microsoft has acknowledged]. You can try installing the hotfix from the Knowledge Base page, or just wait a little while and try again.<br />
<br />
In general, you may now install Arch as you would on any other system. The Generation 1 VMs are BIOS-only (no UEFI), so you must follow the BIOS-specific instructions for the various [[bootloaders]].<br />
<br />
== Post-installation ==<br />
<br />
After Arch has been installed, you can continue to configure features.<br />
<br />
First, you should shut down the VM, open the Settings dialog again, and in the left sidebar, select "DVD Drive" under "IDE Controller 1". Under "Media", choose "None". This will stop the VM from trying to boot from the install media on every start.<br />
<br />
=== Shared directories ===<br />
<br />
Files can be shared between the host and guest with very little effort. First, on the host, choose the folder you want to share with the guest, or create it. Open the Properties dialog for the folder ({{ic|alt}} + {{ic|Enter}} or right-click and choose "Properties..."). Go to the "Sharing" tab and select "Advanced Sharing...". Activate the "Share this folder" checkbox. By default, the folder will have read-only permissions, meaning the VM can read from the folder but cannot write anything to it. If you'd like to modify these permissions, select "Permissions". Here, you choose which users can access the shared folder, and what permissions they have. In general, you will probably be sharing in both directions and should check "Allow" for both "Change" and "Read".<br />
Before exiting the Properties dialog for the shared folder, note its "Network Path", which should be of the form {{ic|\\''computer name''\''folder name''}}.<br />
<br />
Next, you need to find the IP address of the host. Exit the Properties dialog, and open Command Prompt or PowerShell. Run {{ic|ipconfig}}. You should see an entry whose name ends with the name of the virtual switch you created (e.g. {{ic|Ethernet adapter vEthernet (New Virtual Switch)}}). Under this entry, look for {{ic|IPv4 Address}} and note it down.<br />
<br />
Next, you need to mount the shared folder from Arch. Boot the VM. Once it is running, you will first need to install {{Pkg|cifs-utils}}, which will allow you to mount CIFS shares (CIFS is the protocol Windows uses for shared folders). Next, you will need to decide where you will be mounting the shared folder. A reasonable choice would be somewhere in {{ic|/mnt}}, like {{ic|/mnt/Hyper-V}}.<br />
<br />
In the command to mount the share, replace any backslashes in the "Network Path" from earlier with forward slashes.<br />
<br />
# mount -t cifs [''Network Path with forward slashes''] ''mountpoint'' -o user=[''user you wish to authenticate as''],ip=[''host IP noted earlier'']<br />
<br />
You will be prompted for the password for the user you're authenticating as. You can specify the password in the command options via {{ic|1=password=''password''}}, but this isn't a good idea in terms of security as the password for the host will now be in your command history file; or if you are running the command from a script, stored in the script indefinitely. Instead, you can use a credentials file, which allows you to specify your username and password in a file with restricted access rights. It can be called anything; for an example, if it were called {{ic|.credentials}} and stored in your home directory, it would be of the following form:<br />
<br />
{{hc|~/.credentials|2=<br />
username=''username''<br />
password=''password''<br />
}}<br />
<br />
After creating the file, change the permissions to restrict read access:<br />
<br />
chmod 600 ~/.credentials<br />
<br />
Then you can add another option to the {{ic|mount}} command: {{ic|1=credentials=~/.credentials}}. Now, when mounting the share, your username and password will automatically be applied.<br />
<br />
For a more concrete example, let's say you are mounting a share with a Network Path of {{ic|\\PC\share}} at {{ic|/mnt/Hyper-V}}, where your username on the host is "John" and the host's IP is 198.123.151.23. The mount command would thus be<br />
<br />
# mount -t cifs //PC/share /mnt/Hyper-V -o credentials=~/.credentials,ip=198.123.151.23<br />
<br />
One problem with this method is that if the host's IP ever changes (e.g. it has a dynamic IP assigned via DHCP, or moves to a new network), every instance of the host's IP on the guest must be replaced. However, the {{Pkg|smbclient}} package provides {{ic|nmblookup}}, a utility which finds the IP address associated with an SMB host. Thus, in the case of the example above, you would run<br />
<br />
{{hc|nmblookup PC|2=<br />
198.123.151.23 PC<00><br />
}}<br />
<br />
You only want the IP address, so you can use {{ic|head}} and {{ic|cut}} to parse it:<br />
<br />
{{hc|nmblookup PC <nowiki>|</nowiki> head -n 1 <nowiki>|</nowiki> cut -d ' ' -f 1|2=<br />
192.123.151.23<br />
}}<br />
<br />
Then you can simply replace the IP address in the {{ic|mount}} command:<br />
<br />
# mount -t cifs //PC/share /mnt/Hyper-V -o <nowiki>credentials=~/.credentials,ip=</nowiki>"$(nmblookup PC <nowiki>|</nowiki> head -n 1 <nowiki>|</nowiki> cut -d ' ' -f 1)"<br />
<br />
More ways to mount shared folders, including automatic mounting on startup, are detailed in the [[Samba]] article.<br />
<br />
=== Xorg ===<br />
<br />
Graphical programs can easily be run via Xorg via the {{Pkg|xf86-video-fbdev}} package. Simply install it and the window manager or desktop environment you wish to use, and you should be able to start X without issue.</div>SamSpadehttps://wiki.archlinux.org/index.php?title=Hyper-V&diff=490323Hyper-V2017-09-15T23:54:25Z<p>SamSpade: Expanded steps creating external switch and added PowerShell commands</p>
<hr />
<div>[[Category:Hypervisors]]<br />
[[ja:Hyper-V]]<br />
Hyper-V is a hypervisor that is included with some versions of Microsoft Windows. It is capable of running an Arch Linux virtual machine. Hyper-V is generally oriented toward enterprise rather than desktop use, and doesn't provide as convenient and simple of an interface as consumer VM programs like [https://www.virtualbox.org/ VirtualBox], [https://www.parallels.com/ Parallels], or [http://www.vmware.com/ VMWare]. However more recent versions and builds of Windows 10 and Windows Server 2016 include easier configuration options and better compatibility for Arch Linux. Networking features such as NAT for internal switches, multiple NATs and port forwarding have been added without the need to set up Internet Connection Sharing (ICS). Generation 2 virtual machines also now work properly for Arch Linux.<br />
<br />
== Installation ==<br />
<br />
Hyper-V is included with Windows since Windows Server 2008 as well as Windows 8, 8.1 and 10 in the Pro versions. <!-- If someone has experience with Windows Server 2008+ and knows how Hyper-V is enabled, could they add it here? --> It can be enabled from Control Panel at "Turn Windows features on or off" under "Programs and Features". Activate the "Hyper-V" checkbox, apply the change, and follow the directions on screen.<br />
<br />
== Network configuration ==<br />
<br />
First, you must configure a new virtual switch so that your virtual machine will be able to connect to the Internet. Once Hyper-V is enabled, start the Hyper-V Manager (search for it, or start it from Command Prompt with the command<br />
<br />
%windir%\system32\mmc.exe "%windir%\system32\virtmgmt.msc"<br />
<br />
=== Set up a virtual switch ===<br />
<br />
In order to connect your virtual machine to an existing network, either use an internal or external network switch (virtual network adapter). An external switch must be bound (bridged) to one of the host's existing network adapters (e.g. Ethernet or Wi-Fi). An internal switch can be used for network communication between the host and VM, without the VMs having access to the external network. Adding NAT functionality to an internal switch makes the host act as a router for the VMs, enabling the VMs access to the external network.<br />
<br />
Not all networking features (e.g. NAT configuration) can be set up through the Hyper-V Manager GUI. Using PowerShell, run as an Administrator, permits better control over configuration.<br />
<br />
==== External switch ====<br />
<br />
To create an external switch, in the right sidebar, select "Virtual Switch Manager...". In the left sidebar of the dialog that opens, choose "New virtual network switch". Under "What type of virtual switch do you want to create?", select "External", then "Create Virtual Switch". Type a new name for the virtual switch. Under "External network", choose the network adapter to bind with the external switch.<br />
<br />
You will be prompted about network disruption; continue and your network will be briefly disconnected as the switch is configured.<br />
<br />
Using PowerShell (run as Administrator), the above steps can be done with the following:<br />
# Get a list of the network adapters in the host. In a laptop you should typically see 'Ethernet' and 'Wi-Fi'<br />
PS C:\WINDOWS\system32> Get-NetAdapter<br />
<br />
# Create the external switch with a name of VM-External-Switch, bound to the network adapter named {{ic|Wi-Fi}} retrieved from the previous command<br />
PS C:\WINDOWS\system32> New-VMSwitch -Name "VM-External-Switch" -AllowManagementOS $True -NetAdapterName "Wi-Fi"<br />
<br />
On an Arch Linux VM, choosing the external switch as the VM network adapter effectively bridges the Windows host's network adapter with the VM's {{ic|eth0}} interface. The interface can then be set up in Arch Linux through the usual ways (systemd-networkd, netctl, etc.) with a static IP address or with DHCP. The VM will act just like another host in the external network.<br />
<br />
For example, if you want the Arch Linux VM to use a static IP, and the Windows host is configured as {{ic|192.168.0.100/24}}, then the Arch Linux VM interface should be configured like {{ic|192.168.0.101/24}}, with the same gateway and DNS servers as set up in the host.<br />
<br />
If using DHCP for the VM, the IP address will be assigned by the DHCP server in the external network.<br />
<br />
==== Internal switch ====<br />
<br />
To create an internal switch, follow the same steps as the external switch, however replace the relevant choices for 'internal switch'. Then open Network and Sharing Settings, and Adapter Settings, where you will need to enable internet connection sharing for your internet adapter that you normally use. Once the connection can be shared, add it to a bridge together with the virtual switch that you created in the previous step.<br />
<br />
== Virtual machine creation ==<br />
<br />
In the left sidebar, select "PC" under "Hyper-V Manager". In the right sidebar, select "New" > "Virtual Machine...". In New Virtual Machine Wizard, you may in general specify whichever settings you like, but some must be specifically configured. <br />
<br />
Under "Specify Generation", you must choose "Generation 1", as Arch does not work properly in Generation 2 Hyper-V VMs. <br />
<br />
For "Startup memory" under Assign Memory, choose enough to ensure Arch and any programs will run properly.<br />
<br />
For "Connection" under "Configure Networking", choose the virtual switch you created earlier.<br />
<br />
For "Connect Virtual Hard Disk", choose "Create a virtual hard disk", and make sure the "Size" is appropriate for your use case. The virtual hard disk is sparse, so the virtual hard disk will only use as much real storage as is necessary to store what the virtual OS has written to it.<br />
<br />
For "Installation Options", choose "Install an operating system from a bootable CD/DVD-ROM". If you are installing Arch from a disc or USB device, choose "Physical CD/DVD drive" under "Media", and select the appropriate letter. If you are installing Arch from an ISO file, select "Image file (.iso)", and select the file in the "Browse..." dialog.<br />
<br />
== Virtual machine configuration ==<br />
<br />
Next, you need to configure the VM's settings.<br />
<br />
If you like, you can add more virtual processors to your virtual machine. This allows the virtual machine to use more than one of your processor cores, which will increase performance in many cases. If you plan to use the virtual machine intensively, you may wish to allot up to half of your processor cores. To change the number of virtual processors, select "Processor" in the left sidebar, then adjust "Number of virtual processors".<br />
<br />
Change any settings, then select "OK" to apply your changes and exit the settings dialog.<br />
<br />
== Arch installation ==<br />
<br />
Once the virtual machine is fully configured, you are ready to install Arch. In the right sidebar, select "Start", then "Connect...", and a connection window will open. The network should work automatically when the Arch installation media is running; check by using {{ic|ping}} on an address you know is responding, e.g.<br />
<br />
ping archlinux.org<br />
<br />
If no response is received, the connection is not working. If this is the case, you are probably experiencing [https://support.microsoft.com/kb/974909 a bug Microsoft has acknowledged]. You can try installing the hotfix from the Knowledge Base page, or just wait a little while and try again.<br />
<br />
In general, you may now install Arch as you would on any other system. The Generation 1 VMs are BIOS-only (no UEFI), so you must follow the BIOS-specific instructions for the various [[bootloaders]].<br />
<br />
== Post-installation ==<br />
<br />
After Arch has been installed, you can continue to configure features.<br />
<br />
First, you should shut down the VM, open the Settings dialog again, and in the left sidebar, select "DVD Drive" under "IDE Controller 1". Under "Media", choose "None". This will stop the VM from trying to boot from the install media on every start.<br />
<br />
=== Shared directories ===<br />
<br />
Files can be shared between the host and guest with very little effort. First, on the host, choose the folder you want to share with the guest, or create it. Open the Properties dialog for the folder ({{ic|alt}} + {{ic|Enter}} or right-click and choose "Properties..."). Go to the "Sharing" tab and select "Advanced Sharing...". Activate the "Share this folder" checkbox. By default, the folder will have read-only permissions, meaning the VM can read from the folder but cannot write anything to it. If you'd like to modify these permissions, select "Permissions". Here, you choose which users can access the shared folder, and what permissions they have. In general, you will probably be sharing in both directions and should check "Allow" for both "Change" and "Read".<br />
Before exiting the Properties dialog for the shared folder, note its "Network Path", which should be of the form {{ic|\\''computer name''\''folder name''}}.<br />
<br />
Next, you need to find the IP address of the host. Exit the Properties dialog, and open Command Prompt or PowerShell. Run {{ic|ipconfig}}. You should see an entry whose name ends with the name of the virtual switch you created (e.g. {{ic|Ethernet adapter vEthernet (New Virtual Switch)}}). Under this entry, look for {{ic|IPv4 Address}} and note it down.<br />
<br />
Next, you need to mount the shared folder from Arch. Boot the VM. Once it is running, you will first need to install {{Pkg|cifs-utils}}, which will allow you to mount CIFS shares (CIFS is the protocol Windows uses for shared folders). Next, you will need to decide where you will be mounting the shared folder. A reasonable choice would be somewhere in {{ic|/mnt}}, like {{ic|/mnt/Hyper-V}}.<br />
<br />
In the command to mount the share, replace any backslashes in the "Network Path" from earlier with forward slashes.<br />
<br />
# mount -t cifs [''Network Path with forward slashes''] ''mountpoint'' -o user=[''user you wish to authenticate as''],ip=[''host IP noted earlier'']<br />
<br />
You will be prompted for the password for the user you're authenticating as. You can specify the password in the command options via {{ic|1=password=''password''}}, but this isn't a good idea in terms of security as the password for the host will now be in your command history file; or if you are running the command from a script, stored in the script indefinitely. Instead, you can use a credentials file, which allows you to specify your username and password in a file with restricted access rights. It can be called anything; for an example, if it were called {{ic|.credentials}} and stored in your home directory, it would be of the following form:<br />
<br />
{{hc|~/.credentials|2=<br />
username=''username''<br />
password=''password''<br />
}}<br />
<br />
After creating the file, change the permissions to restrict read access:<br />
<br />
chmod 600 ~/.credentials<br />
<br />
Then you can add another option to the {{ic|mount}} command: {{ic|1=credentials=~/.credentials}}. Now, when mounting the share, your username and password will automatically be applied.<br />
<br />
For a more concrete example, let's say you are mounting a share with a Network Path of {{ic|\\PC\share}} at {{ic|/mnt/Hyper-V}}, where your username on the host is "John" and the host's IP is 198.123.151.23. The mount command would thus be<br />
<br />
# mount -t cifs //PC/share /mnt/Hyper-V -o credentials=~/.credentials,ip=198.123.151.23<br />
<br />
One problem with this method is that if the host's IP ever changes (e.g. it has a dynamic IP assigned via DHCP, or moves to a new network), every instance of the host's IP on the guest must be replaced. However, the {{Pkg|smbclient}} package provides {{ic|nmblookup}}, a utility which finds the IP address associated with an SMB host. Thus, in the case of the example above, you would run<br />
<br />
{{hc|nmblookup PC|2=<br />
198.123.151.23 PC<00><br />
}}<br />
<br />
You only want the IP address, so you can use {{ic|head}} and {{ic|cut}} to parse it:<br />
<br />
{{hc|nmblookup PC <nowiki>|</nowiki> head -n 1 <nowiki>|</nowiki> cut -d ' ' -f 1|2=<br />
192.123.151.23<br />
}}<br />
<br />
Then you can simply replace the IP address in the {{ic|mount}} command:<br />
<br />
# mount -t cifs //PC/share /mnt/Hyper-V -o <nowiki>credentials=~/.credentials,ip=</nowiki>"$(nmblookup PC <nowiki>|</nowiki> head -n 1 <nowiki>|</nowiki> cut -d ' ' -f 1)"<br />
<br />
More ways to mount shared folders, including automatic mounting on startup, are detailed in the [[Samba]] article.<br />
<br />
=== Xorg ===<br />
<br />
Graphical programs can easily be run via Xorg via the {{Pkg|xf86-video-fbdev}} package. Simply install it and the window manager or desktop environment you wish to use, and you should be able to start X without issue.</div>SamSpadehttps://wiki.archlinux.org/index.php?title=Hyper-V&diff=490322Hyper-V2017-09-15T23:51:01Z<p>SamSpade: Expanded explanation of external/internal switches and note for PowerShell configuration</p>
<hr />
<div>[[Category:Hypervisors]]<br />
[[ja:Hyper-V]]<br />
Hyper-V is a hypervisor that is included with some versions of Microsoft Windows. It is capable of running an Arch Linux virtual machine. Hyper-V is generally oriented toward enterprise rather than desktop use, and doesn't provide as convenient and simple of an interface as consumer VM programs like [https://www.virtualbox.org/ VirtualBox], [https://www.parallels.com/ Parallels], or [http://www.vmware.com/ VMWare]. However more recent versions and builds of Windows 10 and Windows Server 2016 include easier configuration options and better compatibility for Arch Linux. Networking features such as NAT for internal switches, multiple NATs and port forwarding have been added without the need to set up Internet Connection Sharing (ICS). Generation 2 virtual machines also now work properly for Arch Linux.<br />
<br />
== Installation ==<br />
<br />
Hyper-V is included with Windows since Windows Server 2008 as well as Windows 8, 8.1 and 10 in the Pro versions. <!-- If someone has experience with Windows Server 2008+ and knows how Hyper-V is enabled, could they add it here? --> It can be enabled from Control Panel at "Turn Windows features on or off" under "Programs and Features". Activate the "Hyper-V" checkbox, apply the change, and follow the directions on screen.<br />
<br />
== Network configuration ==<br />
<br />
First, you must configure a new virtual switch so that your virtual machine will be able to connect to the Internet. Once Hyper-V is enabled, start the Hyper-V Manager (search for it, or start it from Command Prompt with the command<br />
<br />
%windir%\system32\mmc.exe "%windir%\system32\virtmgmt.msc"<br />
<br />
=== Set up a virtual switch ===<br />
<br />
In order to connect your virtual machine to an existing network, either use an internal or external network switch (virtual network adapter). An external switch must be bound (bridged) to one of the host's existing network adapters (e.g. Ethernet or Wi-Fi). An internal switch can be used for network communication between the host and VM, without the VMs having access to the external network. Adding NAT functionality to an internal switch makes the host act as a router for the VMs, enabling the VMs access to the external network.<br />
<br />
Not all networking features (e.g. NAT configuration) can be set up through the Hyper-V Manager GUI. Using PowerShell, run as an Administrator, permits better control over configuration.<br />
<br />
==== External switch ====<br />
<br />
To create an external switch, in the right sidebar, select "Virtual Switch Manager...". In the left sidebar of the dialog that opens, choose "New virtual network switch". Under "What type of virtual switch do you want to create?", select "External", then "Create Virtual Switch". You will be prompted about network disruption; continue and your network will be briefly disconnected as the switch is configured.<br />
<br />
==== Internal switch ====<br />
<br />
To create an internal switch, follow the same steps as the external switch, however replace the relevant choices for 'internal switch'. Then open Network and Sharing Settings, and Adapter Settings, where you will need to enable internet connection sharing for your internet adapter that you normally use. Once the connection can be shared, add it to a bridge together with the virtual switch that you created in the previous step.<br />
<br />
== Virtual machine creation ==<br />
<br />
In the left sidebar, select "PC" under "Hyper-V Manager". In the right sidebar, select "New" > "Virtual Machine...". In New Virtual Machine Wizard, you may in general specify whichever settings you like, but some must be specifically configured. <br />
<br />
Under "Specify Generation", you must choose "Generation 1", as Arch does not work properly in Generation 2 Hyper-V VMs. <br />
<br />
For "Startup memory" under Assign Memory, choose enough to ensure Arch and any programs will run properly.<br />
<br />
For "Connection" under "Configure Networking", choose the virtual switch you created earlier.<br />
<br />
For "Connect Virtual Hard Disk", choose "Create a virtual hard disk", and make sure the "Size" is appropriate for your use case. The virtual hard disk is sparse, so the virtual hard disk will only use as much real storage as is necessary to store what the virtual OS has written to it.<br />
<br />
For "Installation Options", choose "Install an operating system from a bootable CD/DVD-ROM". If you are installing Arch from a disc or USB device, choose "Physical CD/DVD drive" under "Media", and select the appropriate letter. If you are installing Arch from an ISO file, select "Image file (.iso)", and select the file in the "Browse..." dialog.<br />
<br />
== Virtual machine configuration ==<br />
<br />
Next, you need to configure the VM's settings.<br />
<br />
If you like, you can add more virtual processors to your virtual machine. This allows the virtual machine to use more than one of your processor cores, which will increase performance in many cases. If you plan to use the virtual machine intensively, you may wish to allot up to half of your processor cores. To change the number of virtual processors, select "Processor" in the left sidebar, then adjust "Number of virtual processors".<br />
<br />
Change any settings, then select "OK" to apply your changes and exit the settings dialog.<br />
<br />
== Arch installation ==<br />
<br />
Once the virtual machine is fully configured, you are ready to install Arch. In the right sidebar, select "Start", then "Connect...", and a connection window will open. The network should work automatically when the Arch installation media is running; check by using {{ic|ping}} on an address you know is responding, e.g.<br />
<br />
ping archlinux.org<br />
<br />
If no response is received, the connection is not working. If this is the case, you are probably experiencing [https://support.microsoft.com/kb/974909 a bug Microsoft has acknowledged]. You can try installing the hotfix from the Knowledge Base page, or just wait a little while and try again.<br />
<br />
In general, you may now install Arch as you would on any other system. The Generation 1 VMs are BIOS-only (no UEFI), so you must follow the BIOS-specific instructions for the various [[bootloaders]].<br />
<br />
== Post-installation ==<br />
<br />
After Arch has been installed, you can continue to configure features.<br />
<br />
First, you should shut down the VM, open the Settings dialog again, and in the left sidebar, select "DVD Drive" under "IDE Controller 1". Under "Media", choose "None". This will stop the VM from trying to boot from the install media on every start.<br />
<br />
=== Shared directories ===<br />
<br />
Files can be shared between the host and guest with very little effort. First, on the host, choose the folder you want to share with the guest, or create it. Open the Properties dialog for the folder ({{ic|alt}} + {{ic|Enter}} or right-click and choose "Properties..."). Go to the "Sharing" tab and select "Advanced Sharing...". Activate the "Share this folder" checkbox. By default, the folder will have read-only permissions, meaning the VM can read from the folder but cannot write anything to it. If you'd like to modify these permissions, select "Permissions". Here, you choose which users can access the shared folder, and what permissions they have. In general, you will probably be sharing in both directions and should check "Allow" for both "Change" and "Read".<br />
Before exiting the Properties dialog for the shared folder, note its "Network Path", which should be of the form {{ic|\\''computer name''\''folder name''}}.<br />
<br />
Next, you need to find the IP address of the host. Exit the Properties dialog, and open Command Prompt or PowerShell. Run {{ic|ipconfig}}. You should see an entry whose name ends with the name of the virtual switch you created (e.g. {{ic|Ethernet adapter vEthernet (New Virtual Switch)}}). Under this entry, look for {{ic|IPv4 Address}} and note it down.<br />
<br />
Next, you need to mount the shared folder from Arch. Boot the VM. Once it is running, you will first need to install {{Pkg|cifs-utils}}, which will allow you to mount CIFS shares (CIFS is the protocol Windows uses for shared folders). Next, you will need to decide where you will be mounting the shared folder. A reasonable choice would be somewhere in {{ic|/mnt}}, like {{ic|/mnt/Hyper-V}}.<br />
<br />
In the command to mount the share, replace any backslashes in the "Network Path" from earlier with forward slashes.<br />
<br />
# mount -t cifs [''Network Path with forward slashes''] ''mountpoint'' -o user=[''user you wish to authenticate as''],ip=[''host IP noted earlier'']<br />
<br />
You will be prompted for the password for the user you're authenticating as. You can specify the password in the command options via {{ic|1=password=''password''}}, but this isn't a good idea in terms of security as the password for the host will now be in your command history file; or if you are running the command from a script, stored in the script indefinitely. Instead, you can use a credentials file, which allows you to specify your username and password in a file with restricted access rights. It can be called anything; for an example, if it were called {{ic|.credentials}} and stored in your home directory, it would be of the following form:<br />
<br />
{{hc|~/.credentials|2=<br />
username=''username''<br />
password=''password''<br />
}}<br />
<br />
After creating the file, change the permissions to restrict read access:<br />
<br />
chmod 600 ~/.credentials<br />
<br />
Then you can add another option to the {{ic|mount}} command: {{ic|1=credentials=~/.credentials}}. Now, when mounting the share, your username and password will automatically be applied.<br />
<br />
For a more concrete example, let's say you are mounting a share with a Network Path of {{ic|\\PC\share}} at {{ic|/mnt/Hyper-V}}, where your username on the host is "John" and the host's IP is 198.123.151.23. The mount command would thus be<br />
<br />
# mount -t cifs //PC/share /mnt/Hyper-V -o credentials=~/.credentials,ip=198.123.151.23<br />
<br />
One problem with this method is that if the host's IP ever changes (e.g. it has a dynamic IP assigned via DHCP, or moves to a new network), every instance of the host's IP on the guest must be replaced. However, the {{Pkg|smbclient}} package provides {{ic|nmblookup}}, a utility which finds the IP address associated with an SMB host. Thus, in the case of the example above, you would run<br />
<br />
{{hc|nmblookup PC|2=<br />
198.123.151.23 PC<00><br />
}}<br />
<br />
You only want the IP address, so you can use {{ic|head}} and {{ic|cut}} to parse it:<br />
<br />
{{hc|nmblookup PC <nowiki>|</nowiki> head -n 1 <nowiki>|</nowiki> cut -d ' ' -f 1|2=<br />
192.123.151.23<br />
}}<br />
<br />
Then you can simply replace the IP address in the {{ic|mount}} command:<br />
<br />
# mount -t cifs //PC/share /mnt/Hyper-V -o <nowiki>credentials=~/.credentials,ip=</nowiki>"$(nmblookup PC <nowiki>|</nowiki> head -n 1 <nowiki>|</nowiki> cut -d ' ' -f 1)"<br />
<br />
More ways to mount shared folders, including automatic mounting on startup, are detailed in the [[Samba]] article.<br />
<br />
=== Xorg ===<br />
<br />
Graphical programs can easily be run via Xorg via the {{Pkg|xf86-video-fbdev}} package. Simply install it and the window manager or desktop environment you wish to use, and you should be able to start X without issue.</div>SamSpadehttps://wiki.archlinux.org/index.php?title=Hyper-V&diff=490321Hyper-V2017-09-15T23:47:46Z<p>SamSpade: Update first paragraph to note recent features</p>
<hr />
<div>[[Category:Hypervisors]]<br />
[[ja:Hyper-V]]<br />
Hyper-V is a hypervisor that is included with some versions of Microsoft Windows. It is capable of running an Arch Linux virtual machine. Hyper-V is generally oriented toward enterprise rather than desktop use, and doesn't provide as convenient and simple of an interface as consumer VM programs like [https://www.virtualbox.org/ VirtualBox], [https://www.parallels.com/ Parallels], or [http://www.vmware.com/ VMWare]. However more recent versions and builds of Windows 10 and Windows Server 2016 include easier configuration options and better compatibility for Arch Linux. Networking features such as NAT for internal switches, multiple NATs and port forwarding have been added without the need to set up Internet Connection Sharing (ICS). Generation 2 virtual machines also now work properly for Arch Linux.<br />
<br />
== Installation ==<br />
<br />
Hyper-V is included with Windows since Windows Server 2008 as well as Windows 8, 8.1 and 10 in the Pro versions. <!-- If someone has experience with Windows Server 2008+ and knows how Hyper-V is enabled, could they add it here? --> It can be enabled from Control Panel at "Turn Windows features on or off" under "Programs and Features". Activate the "Hyper-V" checkbox, apply the change, and follow the directions on screen.<br />
<br />
== Network configuration ==<br />
<br />
First, you must configure a new virtual switch so that your virtual machine will be able to connect to the Internet. Once Hyper-V is enabled, start the Hyper-V Manager (search for it, or start it from Command Prompt with the command<br />
<br />
%windir%\system32\mmc.exe "%windir%\system32\virtmgmt.msc"<br />
<br />
=== Set up a virtual switch ===<br />
<br />
In order to connect your virtual machine to an existing network, either use an internal or external network switch. An external switch will assign the VM an IP address, and will give it total external access on the network, which not be possible on some networks with high security; the host machine will lose internet access as a result. An internal switch can be used for simple internet access.<br />
<br />
==== External switch ====<br />
<br />
To create an external switch, in the right sidebar, select "Virtual Switch Manager...". In the left sidebar of the dialog that opens, choose "New virtual network switch". Under "What type of virtual switch do you want to create?", select "External", then "Create Virtual Switch". You will be prompted about network disruption; continue and your network will be briefly disconnected as the switch is configured.<br />
<br />
==== Internal switch ====<br />
<br />
To create an internal switch, follow the same steps as the external switch, however replace the relevant choices for 'internal switch'. Then open Network and Sharing Settings, and Adapter Settings, where you will need to enable internet connection sharing for your internet adapter that you normally use. Once the connection can be shared, add it to a bridge together with the virtual switch that you created in the previous step.<br />
<br />
== Virtual machine creation ==<br />
<br />
In the left sidebar, select "PC" under "Hyper-V Manager". In the right sidebar, select "New" > "Virtual Machine...". In New Virtual Machine Wizard, you may in general specify whichever settings you like, but some must be specifically configured. <br />
<br />
Under "Specify Generation", you must choose "Generation 1", as Arch does not work properly in Generation 2 Hyper-V VMs. <br />
<br />
For "Startup memory" under Assign Memory, choose enough to ensure Arch and any programs will run properly.<br />
<br />
For "Connection" under "Configure Networking", choose the virtual switch you created earlier.<br />
<br />
For "Connect Virtual Hard Disk", choose "Create a virtual hard disk", and make sure the "Size" is appropriate for your use case. The virtual hard disk is sparse, so the virtual hard disk will only use as much real storage as is necessary to store what the virtual OS has written to it.<br />
<br />
For "Installation Options", choose "Install an operating system from a bootable CD/DVD-ROM". If you are installing Arch from a disc or USB device, choose "Physical CD/DVD drive" under "Media", and select the appropriate letter. If you are installing Arch from an ISO file, select "Image file (.iso)", and select the file in the "Browse..." dialog.<br />
<br />
== Virtual machine configuration ==<br />
<br />
Next, you need to configure the VM's settings.<br />
<br />
If you like, you can add more virtual processors to your virtual machine. This allows the virtual machine to use more than one of your processor cores, which will increase performance in many cases. If you plan to use the virtual machine intensively, you may wish to allot up to half of your processor cores. To change the number of virtual processors, select "Processor" in the left sidebar, then adjust "Number of virtual processors".<br />
<br />
Change any settings, then select "OK" to apply your changes and exit the settings dialog.<br />
<br />
== Arch installation ==<br />
<br />
Once the virtual machine is fully configured, you are ready to install Arch. In the right sidebar, select "Start", then "Connect...", and a connection window will open. The network should work automatically when the Arch installation media is running; check by using {{ic|ping}} on an address you know is responding, e.g.<br />
<br />
ping archlinux.org<br />
<br />
If no response is received, the connection is not working. If this is the case, you are probably experiencing [https://support.microsoft.com/kb/974909 a bug Microsoft has acknowledged]. You can try installing the hotfix from the Knowledge Base page, or just wait a little while and try again.<br />
<br />
In general, you may now install Arch as you would on any other system. The Generation 1 VMs are BIOS-only (no UEFI), so you must follow the BIOS-specific instructions for the various [[bootloaders]].<br />
<br />
== Post-installation ==<br />
<br />
After Arch has been installed, you can continue to configure features.<br />
<br />
First, you should shut down the VM, open the Settings dialog again, and in the left sidebar, select "DVD Drive" under "IDE Controller 1". Under "Media", choose "None". This will stop the VM from trying to boot from the install media on every start.<br />
<br />
=== Shared directories ===<br />
<br />
Files can be shared between the host and guest with very little effort. First, on the host, choose the folder you want to share with the guest, or create it. Open the Properties dialog for the folder ({{ic|alt}} + {{ic|Enter}} or right-click and choose "Properties..."). Go to the "Sharing" tab and select "Advanced Sharing...". Activate the "Share this folder" checkbox. By default, the folder will have read-only permissions, meaning the VM can read from the folder but cannot write anything to it. If you'd like to modify these permissions, select "Permissions". Here, you choose which users can access the shared folder, and what permissions they have. In general, you will probably be sharing in both directions and should check "Allow" for both "Change" and "Read".<br />
Before exiting the Properties dialog for the shared folder, note its "Network Path", which should be of the form {{ic|\\''computer name''\''folder name''}}.<br />
<br />
Next, you need to find the IP address of the host. Exit the Properties dialog, and open Command Prompt or PowerShell. Run {{ic|ipconfig}}. You should see an entry whose name ends with the name of the virtual switch you created (e.g. {{ic|Ethernet adapter vEthernet (New Virtual Switch)}}). Under this entry, look for {{ic|IPv4 Address}} and note it down.<br />
<br />
Next, you need to mount the shared folder from Arch. Boot the VM. Once it is running, you will first need to install {{Pkg|cifs-utils}}, which will allow you to mount CIFS shares (CIFS is the protocol Windows uses for shared folders). Next, you will need to decide where you will be mounting the shared folder. A reasonable choice would be somewhere in {{ic|/mnt}}, like {{ic|/mnt/Hyper-V}}.<br />
<br />
In the command to mount the share, replace any backslashes in the "Network Path" from earlier with forward slashes.<br />
<br />
# mount -t cifs [''Network Path with forward slashes''] ''mountpoint'' -o user=[''user you wish to authenticate as''],ip=[''host IP noted earlier'']<br />
<br />
You will be prompted for the password for the user you're authenticating as. You can specify the password in the command options via {{ic|1=password=''password''}}, but this isn't a good idea in terms of security as the password for the host will now be in your command history file; or if you are running the command from a script, stored in the script indefinitely. Instead, you can use a credentials file, which allows you to specify your username and password in a file with restricted access rights. It can be called anything; for an example, if it were called {{ic|.credentials}} and stored in your home directory, it would be of the following form:<br />
<br />
{{hc|~/.credentials|2=<br />
username=''username''<br />
password=''password''<br />
}}<br />
<br />
After creating the file, change the permissions to restrict read access:<br />
<br />
chmod 600 ~/.credentials<br />
<br />
Then you can add another option to the {{ic|mount}} command: {{ic|1=credentials=~/.credentials}}. Now, when mounting the share, your username and password will automatically be applied.<br />
<br />
For a more concrete example, let's say you are mounting a share with a Network Path of {{ic|\\PC\share}} at {{ic|/mnt/Hyper-V}}, where your username on the host is "John" and the host's IP is 198.123.151.23. The mount command would thus be<br />
<br />
# mount -t cifs //PC/share /mnt/Hyper-V -o credentials=~/.credentials,ip=198.123.151.23<br />
<br />
One problem with this method is that if the host's IP ever changes (e.g. it has a dynamic IP assigned via DHCP, or moves to a new network), every instance of the host's IP on the guest must be replaced. However, the {{Pkg|smbclient}} package provides {{ic|nmblookup}}, a utility which finds the IP address associated with an SMB host. Thus, in the case of the example above, you would run<br />
<br />
{{hc|nmblookup PC|2=<br />
198.123.151.23 PC<00><br />
}}<br />
<br />
You only want the IP address, so you can use {{ic|head}} and {{ic|cut}} to parse it:<br />
<br />
{{hc|nmblookup PC <nowiki>|</nowiki> head -n 1 <nowiki>|</nowiki> cut -d ' ' -f 1|2=<br />
192.123.151.23<br />
}}<br />
<br />
Then you can simply replace the IP address in the {{ic|mount}} command:<br />
<br />
# mount -t cifs //PC/share /mnt/Hyper-V -o <nowiki>credentials=~/.credentials,ip=</nowiki>"$(nmblookup PC <nowiki>|</nowiki> head -n 1 <nowiki>|</nowiki> cut -d ' ' -f 1)"<br />
<br />
More ways to mount shared folders, including automatic mounting on startup, are detailed in the [[Samba]] article.<br />
<br />
=== Xorg ===<br />
<br />
Graphical programs can easily be run via Xorg via the {{Pkg|xf86-video-fbdev}} package. Simply install it and the window manager or desktop environment you wish to use, and you should be able to start X without issue.</div>SamSpadehttps://wiki.archlinux.org/index.php?title=Network_configuration&diff=435519Network configuration2016-05-19T12:03:39Z<p>SamSpade: /* Change device name */</p>
<hr />
<div>[[Category:Network configuration]]<br />
[[cs:Network configuration]]<br />
[[el:Network configuration]]<br />
[[es:Network configuration]]<br />
[[fr:Connexions reseau]]<br />
[[it:Network configuration]]<br />
[[ja:ネットワーク設定]]<br />
[[nl:Network configuration]]<br />
[[pt:Network configuration]]<br />
[[ro:Configurare retea]]<br />
[[ru:Network configuration]]<br />
[[sk:Network configuration]]<br />
[[tr:Ağ Yapılandırması]]<br />
[[zh-cn:Network configuration]]<br />
[[zh-tw:Network configuration]]<br />
{{Related articles start}}<br />
{{Related|Jumbo frames}}<br />
{{Related|Firewalls}}<br />
{{Related|Wireless network configuration}}<br />
{{Related|Network bridge}}<br />
{{Related|List of applications/Internet#Network managers}}<br />
{{Related articles end}}<br />
<br />
This page explains how to set up a '''wired''' connection to a network. If you need to set up '''wireless''' networking see the [[Wireless network configuration]] page.<br />
<br />
== Check the connection ==<br />
<br />
The basic installation procedure typically has a functional network configuration. Use ''ping'' to check the connection:<br />
<br />
{{hc|$ ping www.google.com|2=<br />
PING www.l.google.com (74.125.132.105) 56(84) bytes of data.<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=1 ttl=50 time=17.0 ms<br />
...<br />
}}<br />
<br />
If the ping is successful (you see 64 bytes messages as above), then the network is configured. Press {{ic|Control-C}} to stop the ping.<br />
<br />
If the ping failed with an ''Unknown hosts'' error, it means that your machine was unable to resolve this domain name. It may be related to your service provider or your router/gateway. Try pinging a static IP address to prove that your machine has access to the Internet:<br />
<br />
{{hc|$ ping 8.8.8.8|<nowiki><br />
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.<br />
64 bytes from 8.8.8.8: icmp_req=1 ttl=53 time=52.9 ms<br />
...<br />
</nowiki>}}<br />
<br />
If you are able to ping {{ic|8.8.8.8}} but not {{ic|www.google.com}}, check your DNS configuration. See [[resolv.conf]] for details. The {{ic|hosts}} line in {{ic|/etc/nsswitch.conf}} is another place you can check.<br />
<br />
If not, check for cable issues before diagnosing further.<br />
<br />
{{Note|<br />
* If you receive an error like {{ic|ping: icmp open socket: Operation not permitted}} when executing ''ping'', try to re-install the {{Pkg|iputils}} package.<br />
* The {{ic|-c ''num''}} option can be used to make exactly {{ic|''num''}} pings, otherwise it pings infinitely and has to be terminated manually. See {{ic|man ping}} for more information.<br />
* {{ic|8.8.8.8}} is a static address that is easy to remember. It is the address of Google's primary DNS server, therefore it can be considered reliable, and is generally not blocked by content filtering systems and proxies.<br />
}}<br />
<br />
== Set the hostname ==<br />
<br />
A [[Wikipedia:Hostname|hostname]] is a unique name created to identify a machine on a network: it is configured in {{ic|/etc/hostname}}. The file can contain the system's domain name, if any. To set the hostname, do:<br />
<br />
# hostnamectl set-hostname ''myhostname''<br />
<br />
This will put {{ic|''myhostname''}} into {{ic|/etc/hostname}}. See {{ic|man 5 hostname}} and {{ic|man 1 hostnamectl}} for details.<br />
<br />
It is recommended to also set the hostname in {{ic|/etc/hosts}}:<br />
<br />
{{hc|/etc/hosts|2=<br />
#<br />
# /etc/hosts: static lookup table for host names<br />
#<br />
<br />
#<ip-address> <hostname.domain.org> <hostname><br />
127.0.0.1 localhost.localdomain localhost ''myhostname''<br />
::1 localhost.localdomain localhost ''myhostname''<br />
}}<br />
<br />
{{Note|{{Pkg|systemd}} provides hostname resolution via the {{ic|myhostname}} nss module (enabled by default in {{ic|/etc/nsswitch.conf}}), which means that changing hostnames in {{ic|/etc/hosts}} is normally not necessary. However several users have reported bugs such as delays in network-based applications when the hostname was not set correctly in {{ic|/etc/hosts}}. See [[#Local network hostname resolution]] for details.}}<br />
<br />
To temporarily set the hostname (until reboot), use ''hostname'' from {{Pkg|inetutils}}:<br />
<br />
# hostname ''myhostname''<br />
<br />
To set the "pretty" hostname and other machine metadata, see the manpage for {{ic|machine-info}}.<br />
<br />
== Device driver ==<br />
<br />
=== Check the status ===<br />
<br />
[[udev]] should detect your network interface card (see [[Wikipedia:Network interface controller]]) and automatically load the necessary module at start up. Check the "Ethernet controller" entry (or similar) from the {{ic|lspci -v}} output. It should tell you which kernel module contains the driver for your network device. For example:<br />
<br />
{{hc|$ lspci -v|<br />
02:00.0 Ethernet controller: Attansic Technology Corp. L1 Gigabit Ethernet Adapter (rev b0)<br />
...<br />
Kernel driver in use: atl1<br />
Kernel modules: atl1<br />
}}<br />
<br />
Next, check that the driver was loaded via {{ic|dmesg <nowiki>|</nowiki> grep ''module_name''}}. For example:<br />
<br />
$ dmesg | grep atl1<br />
...<br />
atl1 0000:02:00.0: eth0 link is up 100 Mbps full duplex<br />
<br />
Skip the next section if the driver was loaded successfully. Otherwise, you will need to know which module is needed for your particular model.<br />
<br />
=== Load the module ===<br />
<br />
Search in the Internet for the right module/driver for the chipset. Some common modules are {{ic|8139too}} for cards with a Realtek chipset, or {{ic|sis900}} for cards with a SiS chipset. Once you know which module to use, try to [[Kernel modules#Manual module handling|load it manually]]. If you get an error saying that the module was not found, it's possible that the driver is not included in Arch kernel. You may search the [[AUR]] for the module name.<br />
<br />
If udev is not detecting and loading the proper module automatically during bootup, see [[Kernel modules#Loading]].<br />
<br />
== Network interfaces ==<br />
<br />
=== Device names ===<br />
<br />
For computers with multiple NICs, it is important to have fixed device names. Many configuration problems are caused by interface name changing.<br />
<br />
[[udev]] is responsible for which device gets which name. Systemd v197 introduced [http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames Predictable Network Interface Names], which automatically assigns static names to network devices. Interfaces are now prefixed with {{ic|en}} (ethernet), {{ic|wl}} (WLAN), or {{ic|ww}} (WWAN) followed by an automatically generated identifier, creating an entry such as {{ic|enp0s25}}. This behavior may be disabled by adding {{ic|1=net.ifnames=0}} to the [[kernel parameters]].<br />
<br />
{{Note|When changing the interface naming scheme, do not forget to update all network-related configuration files and custom systemd unit files to reflect the change. Specifically, if you have [[netctl#Basic method|netctl static profiles]] enabled, run {{ic|netctl reenable ''profile''}} to update the generated service file.}}<br />
<br />
==== Get current device names ====<br />
<br />
Current NIC names can be found via {{ic|sysfs}} or {{ic|ip link}}. For example:<br />
<br />
{{hc|$ ls /sys/class/net|<br />
lo enp0s3<br />
}}<br />
<br />
{{hc|$ ip link|<br />
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default <br />
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br />
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000<br />
link/ether 08:00:27:23:6f:3a brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
Wireless device names can also be retrieved using {{ic|iw dev}}. See [[Wireless network configuration#Getting some useful information]] for details.<br />
<br />
==== Change device name ====<br />
<br />
The easiest way to change a device name is to create [https://www.freedesktop.org/software/systemd/man/systemd.link.html systemd.link] files, which udev reads from the {{ic|/etc/systemd/network}} directory. A useful example is to set a fixed interface name for a USB-to-Ethernet adapter based on its MAC address, as those adapters are usually given different names depending on which USB port they are plugged into.<br />
{{hc|head=/etc/systemd/network/10-ethusb0.link|output=<br />
[Match]<br />
MACAddress=12:34:56:78:90:ab<br />
<br />
[Link]<br />
Description=USB to Ethernet Adapter<br />
Name=ethusb0<br />
}}<br />
<br />
The {{ic|[Match]}} section can have several keys including udev properties such as {{ic|1=Path=}} or {{ic|1=Driver=}}. The {{ic|[Link]}} section also has other options like {{ic|1=MACAddress=}} for MAC address spoofing, or {{ic|1=MTUBytes=}} to change the maximum transmission unit (MTU) for the device. For further details please see the official [https://www.freedesktop.org/software/systemd/man/systemd.link.html systemd.link] documentation.<br />
<br />
{{Note|The default link file {{ic|/usr/lib/systemd/network/99-default.link}} is shipped by the system. Any user-supplied .link '''should''' have a lexically earlier file name to be considered at all. For example, name the file {{ic|10-ethusb0.link }} and not {{ic|ethusb0.link}}.}}<br />
<br />
You can also change the device name by defining the name manually with an udev-rule. For example:<br />
<br />
{{hc|/etc/udev/rules.d/10-network.rules|<nowiki><br />
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="net1"<br />
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="ff:ee:dd:cc:bb:aa", NAME="net0"<br />
</nowiki>}}<br />
<br />
These rules will be applied automatically at boot.<br />
<br />
A couple of things to note:<br />
<br />
* To get the MAC address of each card, use this command: {{ic|cat /sys/class/net/''device_name''/address}}<br />
* Make sure to use the lower-case hex values in your udev rules. It doesn't like upper-case.<br />
<br />
If the network card has a dynamic MAC, you can use {{ic|DEVPATH}}, for example:<br />
<br />
{{hc|/etc/udev/rules.d/10-network.rules|<nowiki><br />
SUBSYSTEM=="net", DEVPATH=="/devices/platform/wemac.*", NAME="int"<br />
SUBSYSTEM=="net", DEVPATH=="/devices/pci*/*1c.0/*/net/*", NAME="en"<br />
</nowiki>}}<br />
<br />
The device path should match both the new and old device name, since the rule may be executed more than once on bootup. For example, in the second rule, {{ic|"/devices/pci*/*1c.0/*/net/enp*"}} would be wrong since it will stop matching once the name is changed to {{ic|en}}. Only the system-default rule will fire the second time around, causing the name to be changed back to e.g. {{ic|enp1s0}}.<br />
<br />
To [[Udev#Testing_rules_before_loading|test]] your rules, they can be triggered directly from userspace, e.g. with {{ic|udevadm --debug test /sys/''DEVPATH''}}. Remember to first take down the interface you are trying to rename (e.g. {{ic|ip link set enp1s0 down}}).<br />
<br />
{{Note|When choosing the static names '''it should be avoided to use names in the format of "eth''X''" and "wlan''X''"''', because this may lead to race conditions between the kernel and udev during boot. Instead, it is better to use interface names that are not used by the kernel as default, e.g.: {{ic|net0}}, {{ic|net1}}, {{ic|wifi0}}, {{ic|wifi1}}. For further details please see the [http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames systemd] documentation.}}<br />
<br />
==== Reverting to traditional device names ====<br />
<br />
If you would prefer to retain traditional interface names such as eth0, [http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames Predictable Network Interface Names] can be disabled with the following:<br />
<br />
# ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules<br />
<br />
=== Set device MTU and queue length ===<br />
<br />
You can change the device MTU and queue length by defining manually with an udev-rule. For example:<br />
<br />
{{hc|/etc/udev/rules.d/10-network.rules|<nowiki><br />
ACTION=="add", SUBSYSTEM=="net", KERNEL=="wl*", ATTR{mtu}="1480", ATTR{tx_queue_len}="2000"<br />
</nowiki>}}<br />
<br />
=== Enabling and disabling network interfaces ===<br />
<br />
You can activate or deactivate network interfaces using:<br />
<br />
# ip link set eth0 up<br />
# ip link set eth0 down<br />
<br />
To check the result:<br />
<br />
{{hc|$ ip link show dev eth0|<br />
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT qlen 1000<br />
...<br />
}}<br />
<br />
{{Note| If your default route is through interface {{ic|eth0}}, taking it down will also remove the route, and bringing it back up will not automatically reestablish the default route. See [[#Manual assignment]] for reestablishing it.}}<br />
<br />
== Configure the IP address ==<br />
<br />
You have two options: a dynamically assigned address using [[Wikipedia:Dynamic Host Configuration Protocol|DHCP]], or an unchanging "static" address.<br />
<br />
{{Tip| In addition to the methods described below one can also use a [[List of applications#Network managers|network manager]]. Network managers are especially useful for dynamic network connections and wifi networking.}}<br />
<br />
=== Dynamic IP address ===<br />
<br />
==== systemd-networkd ====<br />
<br />
An easy way to setup DHCP for simple requirements is to use [[systemd-networkd]] service provided by systemd. See [[systemd-networkd#Basic DHCP network]]. <br />
<br />
==== dhcpcd ====<br />
<br />
[[dhcpcd]] is the default client in Arch Linux to setup DHCP on the installation ISO. It is a powerful tool with many configurable DHCP client options. See [[dhcpcd#Running]] on how to activate it for an interface.<br />
<br />
==== netctl ====<br />
<br />
[[netctl]] is a CLI-based tool for configuring and managing network connections through user-created profiles. Create a profile as shown in [[netctl#Example profiles]], then enable it as described in [[netctl#Basic method]].<br />
<br />
=== Static IP address ===<br />
<br />
A static IP address can be configured with most standard Arch Linux networking tools. Independent of the tool you choose, you will probably need to be prepared with the following information:<br />
<br />
* Static IP address<br />
* Subnet mask, or possibly its [[wikipedia:Classless Inter-Domain Routing#CIDR notation|CIDR notation]], for example {{ic|/24}} is the CIDR notation of {{ic|255.255.255.0}} netmask.<br />
* [[Wikipedia:Broadcast_address|Broadcast address]]<br />
* [[Wikipedia:Default_gateway|Gateway]]'s IP address<br />
* Name server (DNS) IP addresses. See also [[resolv.conf]].<br />
<br />
If you are running a private network, it is safe to use IP addresses in {{ic|192.168.*.*}} for your IP addresses, with a subnet mask of {{ic|255.255.255.0}} and a broadcast address of {{ic|192.168.*.255}}. The gateway is usually {{ic|192.168.*.1}} or {{ic|192.168.*.254}}.<br />
<br />
{{Warning|<br />
* Make sure manually assigned IP addresses do not conflict with DHCP assigned ones. See [http://www.raspberrypi.org/forums/viewtopic.php?f&#61;28&t&#61;16797 this forum thread]<br />
* If you share your Internet connection from a Windows machine without a router, be sure to use static IP addresses on both computers to avoid LAN problems.<br />
}}<br />
<br />
==== netctl ====<br />
<br />
To create a [[netctl]] profile with a static IP, set the {{ic|1=IP=static}} option as well as {{ic|Address}}, {{ic|Gateway}}, and {{ic|DNS}}. See [[netctl#Wired]].<br />
<br />
==== systemd-networkd ====<br />
<br />
The [[systemd-networkd]] service provided by systemd can set up a static IP using a simple configuration file. See [[systemd-networkd#Wired adapter using a static IP]].<br />
<br />
==== dhcpcd ====<br />
<br />
See [[dhcpcd#Static profile]].<br />
<br />
==== Manual assignment ====<br />
<br />
It is possible to manually set up a static IP using only the {{pkg|iproute2}} package. This is a good way to test connection settings since the connection will not persist across reboots. First enable the [[#Network interfaces|network interface]]:<br />
<br />
# ip link set ''interface'' up<br />
<br />
Assign a static IP address in the console:<br />
<br />
# ip addr add ''IP_address''/''subnet_mask'' broadcast ''broadcast_address'' dev ''interface''<br />
<br />
Then add your gateway IP address:<br />
<br />
# ip route add default via ''default_gateway''<br />
<br />
For example:<br />
<br />
# ip link set eth0 up<br />
# ip addr add 192.168.1.2/24 broadcast 192.168.1.255 dev eth0<br />
# ip route add default via 192.168.1.1<br />
<br />
To undo these steps (e.g. before switching to a dynamic IP), first remove any assigned IP address:<br />
<br />
# ip addr flush dev ''interface''<br />
<br />
Then remove any assigned gateway:<br />
<br />
# ip route flush dev ''interface''<br />
<br />
And finally disable the interface:<br />
<br />
# ip link set ''interface'' down<br />
<br />
For more options, see the {{ic|ip(8)}} man page. These commands can be automated using scripts and [[systemd#Writing unit files|systemd units]].<br />
<br />
==== Calculating addresses ====<br />
<br />
You can use {{ic|ipcalc}} provided by the {{Pkg|ipcalc}} package to calculate IP broadcast, network, netmask, and host ranges for more advanced configurations. An example is using Ethernet over Firewire to connect a Windows machine to Linux. To improve security and organization, both machines have their own network with the netmask and broadcast configured accordingly. <br />
<br />
Finding out the respective netmask and broadcast addresses is done with {{ic|ipcalc}}, by specifying the IP of the Linux NIC {{ic|10.66.66.1}} and the number of hosts (here two):<br />
<br />
{{hc|$ ipcalc -nb 10.66.66.1 -s 1|<nowiki><br />
Address: 10.66.66.1<br />
<br />
Netmask: 255.255.255.252 = 30<br />
Network: 10.66.66.0/30<br />
HostMin: 10.66.66.1<br />
HostMax: 10.66.66.2<br />
Broadcast: 10.66.66.3<br />
Hosts/Net: 2 Class A, Private Internet<br />
</nowiki>}}<br />
<br />
== Additional settings ==<br />
<br />
=== ifplugd for laptops ===<br />
<br />
{{Tip|[[dhcpcd]] provides the same feature out of the box.}}<br />
<br />
{{Pkg|ifplugd}} in [[official repositories]] is a daemon which will automatically configure your Ethernet device when a cable is plugged in and automatically unconfigure it if the cable is pulled. This is useful on laptops with onboard network adapters, since it will only configure the interface when a cable is really connected. Another use is when you just need to restart the network but do not want to restart the computer or do it from the shell.<br />
<br />
By default it is configured to work for the {{ic|eth0}} device. This and other settings like delays can be configured in {{ic|/etc/ifplugd/ifplugd.conf}}.<br />
<br />
{{Note|[[netctl]] package includes {{ic|netctl-ifplugd@.service}}, otherwise you can use {{ic|ifplugd@.service}} from {{Pkg|ifplugd}} package. For example, [[enable]] {{ic|ifplugd@eth0.service}}.}}<br />
<br />
=== Bonding or LAG ===<br />
<br />
See [[netctl#Bonding]] or [[Wireless bonding]].<br />
<br />
=== IP address aliasing ===<br />
<br />
IP aliasing is the process of adding more than one IP address to a network interface. With this, one node on a network can have multiple connections to a network, each serving a different purpose. Typical uses are virtual hosting of Web and FTP servers, or reorganizing servers without having to update any other machines (this is especially useful for nameservers).<br />
<br />
==== Example ====<br />
<br />
To manually set an alias, for some NIC, use {{Pkg|iproute2}} to execute<br />
<br />
# ip addr add 192.168.2.101/24 dev eth0 label eth0:1<br />
<br />
To remove a given alias execute<br />
<br />
# ip addr del 192.168.2.101/24 dev eth0:1<br />
<br />
Packets destined for a subnet will use the primary alias by default. If the destination IP is within a subnet of a secondary alias, then the source IP is set respectively. Consider the case where there is more than one NIC, the default routes can be listed with {{ic|ip route}}.<br />
<br />
=== Change MAC/hardware address ===<br />
<br />
See [[MAC address spoofing]].<br />
<br />
=== Internet sharing ===<br />
<br />
See [[Internet sharing]].<br />
<br />
=== Router configuration ===<br />
<br />
See [[Router]].<br />
<br />
=== Local network hostname resolution ===<br />
<br />
The pre-requisite is to [[#Set the hostname]] after which hostname resolution works on the local system itself:<br />
<br />
{{hc|$ ping ''myhostname''|2=<br />
PING myhostname (192.168.1.2) 56(84) bytes of data.<br />
64 bytes from myhostname (192.168.1.2): icmp_seq=1 ttl=64 time=0.043 ms}}<br />
<br />
To enable other machines to address the host by name, either a manual configuration of the respective {{ic|/etc/hosts}} files or a service to propagate/resolve the name is required. With systemd the latter is done via the {{ic|myhostname}} nss module. However, not all network services (on the same system; examples: [https://bbs.archlinux.org/viewtopic.php?id=176761], [https://bbs.archlinux.org/viewtopic.php?id=186967]) or other clients with different operating systems use the same methods to try resolve the hostname. <br />
<br />
A first work-around that can be tried is to add the following line to {{ic|/etc/hosts}}:<br />
<br />
127.0.1.1 ''myhostname''.localdomain ''myhostname'' <br />
<br />
As a result the system resolves to both entries: <br />
$ getent hosts <br />
127.0.0.1 localhost<br />
127.0.1.1 myhostname.localdomain myhostname<br />
<br />
For a system with a permanent IP address, that permanent IP address should be used instead of {{ic|127.0.1.1}}. <br />
<br />
Another possibility is to set up a full DNS server such as [[BIND]] or [[Unbound]], but that is overkill and too complex for most systems. For small networks and dynamic flexibility with hosts joining and leaving the network [[Wikipedia:Zero-configuration_networking|zero-configuration networking]] services may be more applicable. There are two options available: <br />
<br />
*[[Samba]] provides hostname resolution via Microsoft's '''NetBIOS'''. It only requires installation of {{Pkg|samba}} and enabling of the {{ic|nmbd.service}} service. Computers running Windows, OS X, or Linux with {{ic|nmbd}} running, will be able to find your machine.<br />
<br />
*[[Avahi]] provides hostname resolution via '''zeroconf''', also known as Avahi or Bonjour. It requires slightly more complex configuration than Samba: see [[Avahi#Hostname resolution]] for details. Computers running OS X, or Linux with an Avahi daemon running, will be able to find your machine. Windows does not have an built-in Avahi client or daemon.<br />
<br />
=== Promiscuous mode ===<br />
<br />
Toggling [[wikipedia:Promiscuous_mode|promiscuous mode]] will make a (wireless) NIC forward all traffic it receives to the OS for further processing. This is opposite to "normal mode" where a NIC will drop frames it is not intended to receive. It is most often used for advanced network troubleshooting and [[wikipedia:Packet_sniffing|packet sniffing]].<br />
<br />
{{hc|/etc/systemd/system/promiscuous@.service|<nowiki><br />
[Unit]<br />
Description=Set %i interface in promiscuous mode<br />
After=network.target<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/usr/bin/ip link set dev %i promisc on<br />
RemainAfterExit=yes<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
If you want to enable promiscuous mode on interface {{ic|eth0}} run [[enable]] {{ic|promiscuous@eth0.service}}.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Swapping computers on the cable modem ===<br />
<br />
Some cable ISPs (videotron for example) have the cable modem configured to recognize only one client PC, by the MAC address of its network interface. Once the cable modem has learned the MAC address of the first PC or equipment that talks to it, it will not respond to another MAC address in any way. Thus if you swap one PC for another (or for a router), the new PC (or router) will not work with the cable modem, because the new PC (or router) has a MAC address different from the old one. To reset the cable modem so that it will recognise the new PC, you must power the cable modem off and on again. Once the cable modem has rebooted and gone fully online again (indicator lights settled down), reboot the newly connected PC so that it makes a DHCP request, or manually make it request a new DHCP lease.<br />
<br />
If this method does not work, you will need to clone the MAC address of the original machine. See also [[#Change MAC/hardware address]].<br />
<br />
=== The TCP window scaling problem ===<br />
<br />
TCP packets contain a "window" value in their headers indicating how much data the other host may send in return. This value is represented with only 16 bits, hence the window size is at most 64Kb. TCP packets are cached for a while (they have to be reordered), and as memory is (or used to be) limited, one host could easily run out of it.<br />
<br />
Back in 1992, as more and more memory became available, [http://www.faqs.org/rfcs/rfc1323.html RFC 1323] was written to improve the situation: Window Scaling. The "window" value, provided in all packets, will be modified by a Scale Factor defined once, at the very beginning of the connection. That 8-bit Scale Factor allows the Window to be up to 32 times higher than the initial 64Kb.<br />
<br />
It appears that some broken routers and firewalls on the Internet are rewriting the Scale Factor to 0 which causes misunderstandings between hosts. The Linux kernel 2.6.17 introduced a new calculation scheme generating higher Scale Factors, virtually making the aftermaths of the broken routers and firewalls more visible.<br />
<br />
The resulting connection is at best very slow or broken.<br />
<br />
==== How to diagnose the problem ====<br />
<br />
First of all, let's make it clear: this problem is odd. In some cases, you will not be able to use TCP connections (HTTP, FTP, ...) at all and in others, you will be able to communicate with some hosts (very few).<br />
<br />
When you have this problem, the {{ic|dmesg}}'s output is OK, logs are clean and {{ic|ip addr}} will report normal status... and actually everything appears normal.<br />
<br />
If you cannot browse any website, but you can ping some random hosts, chances are great that you're experiencing this problem: ping uses ICMP and is not affected by TCP problems.<br />
<br />
You can try to use [[Wireshark]]. You might see successful UDP and ICMP communications but unsuccessful TCP communications (only to foreign hosts).<br />
<br />
==== Ways of fixing it ====<br />
<br />
===== Bad =====<br />
<br />
To fix it the bad way, you can change the {{ic|tcp_rmem}} value, on which Scale Factor calculation is based. Although it should work for most hosts, it is not guaranteed, especially for very distant ones.<br />
<br />
# echo "4096 87380 174760" > /proc/sys/net/ipv4/tcp_rmem<br />
<br />
===== Good =====<br />
<br />
Simply disable Window Scaling. Since Window Scaling is a nice TCP feature, it may be uncomfortable to disable it, especially if you cannot fix the broken router. There are several ways to disable Window Scaling, and it seems that the most bulletproof way (which will work with most kernels) is to add the following line to {{ic|/etc/sysctl.d/99-disable_window_scaling.conf}} (see also [[sysctl]]):<br />
<br />
net.ipv4.tcp_window_scaling = 0<br />
<br />
===== Best =====<br />
<br />
This problem is caused by broken routers/firewalls, so let's change them. Some users have reported that the broken router was their very own DSL router.<br />
<br />
==== More about it ====<br />
<br />
This section is based on the LWN article [http://lwn.net/Articles/92727/ TCP window scaling and broken routers] and a Kernel Trap article: [http://kerneltrap.org/node/6723 Window Scaling on the Internet].<br />
<br />
There are also several relevant threads on the LKML.<br />
<br />
=== Realtek no link / WOL problem ===<br />
<br />
Users with Realtek 8168 8169 8101 8111(C) based NICs (cards / and on-board) may notice a problem where the NIC seems to be disabled on boot and has no Link light. This can usually be found on a dual boot system where Windows is also installed. It seems that using the offical Realtek drivers (dated anything after May 2007) under Windows is the cause. These newer drivers disable the Wake-On-LAN feature by disabling the NIC at Windows shutdown time, where it will remain disabled until the next time Windows boots. You will be able to notice if this problem is affecting you if the Link light remains off until Windows boots up; during Windows shutdown the Link light will switch off. Normal operation should be that the link light is always on as long as the system is on, even during POST. This problem will also affect other operating systems without newer drivers (eg. Live CDs). Here are a few fixes for this problem.<br />
<br />
==== Enable the NIC directly in Linux ====<br />
<br />
Follow [[#Enabling and disabling network interfaces]] to enable the interface.<br />
<br />
==== Rollback/change Windows driver ====<br />
<br />
You can roll back your Windows NIC driver to the Microsoft provided one (if available), or roll back/install an official Realtek driver pre-dating May 2007 (may be on the CD that came with your hardware).<br />
<br />
==== Enable WOL in Windows driver ====<br />
<br />
Probably the best and the fastest fix is to change this setting in the Windows driver. This way it should be fixed system-wide and not only under Arch (eg. live CDs, other operating systems). In Windows, under Device Manager, find your Realtek network adapter and double-click it. Under the "Advanced" tab, change "Wake-on-LAN after shutdown" to "Enable".<br />
<br />
In Windows XP (example):<br />
<br />
Right click my computer and choose "Properties"<br />
--> "Hardware" tab<br />
--> Device Manager<br />
--> Network Adapters<br />
--> "double click" Realtek ...<br />
--> Advanced tab<br />
--> Wake-On-Lan After Shutdown<br />
--> Enable<br />
<br />
{{Note|Newer Realtek Windows drivers (tested with ''Realtek 8111/8169 LAN Driver v5.708.1030.2008'', dated 2009/01/22, available from GIGABYTE) may refer to this option slightly differently, like ''Shutdown Wake-On-LAN --> Enable''. It seems that switching it to {{ic|Disable}} has no effect (you will notice the Link light still turns off upon Windows shutdown). One rather dirty workaround is to boot to Windows and just reset the system (perform an ungraceful restart/shutdown) thus not giving the Windows driver a chance to disable LAN. The Link light will remain on and the LAN adapter will remain accessible after POST - that is until you boot back to Windows and shut it down properly again.}}<br />
<br />
==== Newer Realtek Linux driver ====<br />
<br />
Any newer driver for these Realtek cards can be found for Linux on the realtek site (untested but believed to also solve the problem).<br />
<br />
==== Enable ''LAN Boot ROM'' in BIOS/CMOS ====<br />
<br />
It appears that setting ''Integrated Peripherals --> Onboard LAN Boot ROM --> Enabled'' in BIOS/CMOS reactivates the Realtek LAN chip on system boot-up, despite the Windows driver disabling it on OS shutdown.<br />
<br />
{{Note|This was tested several times on a GIGABYTE GA-G31M-ES2L motherboard, BIOS version F8 released on 2009/02/05.}}<br />
<br />
=== No interface with Atheros chipsets ===<br />
<br />
Users of some Atheros ethernet chips are reporting it does not work out-of-the-box (with installation media of February 2014). The working solution for this is to install {{AUR|backports-patched}}.<br />
<br />
=== Broadcom BCM57780 ===<br />
<br />
This Broadcom chipset sometimes does not behave well unless you specify the order of the modules to be loaded. The modules are {{ic|broadcom}} and {{ic|tg3}}, the former needing to be loaded first.<br />
<br />
These steps should help if your computer has this chipset:<br />
<br />
* Find your NIC in ''lspci'' output:<br />
<br />
$ lspci | grep Ethernet<br />
02:00.0 Ethernet controller: Broadcom Corporation NetLink BCM57780 Gigabit Ethernet PCIe (rev 01)<br />
<br />
* If your wired networking is not functioning in some way or another, try unplugging your cable then doing the following:<br />
<br />
# modprobe -r tg3<br />
# modprobe broadcom<br />
# modprobe tg3<br />
<br />
* Plug you network cable in. If this solves your problems you can make this permanent by adding {{ic|broadcom}} and {{ic|tg3}} (in this order) to the {{ic|MODULES}} array in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
MODULES=".. broadcom tg3 .."<br />
<br />
* Rebuild the initramfs:<br />
<br />
# mkinitcpio -p linux<br />
<br />
* Alternatively, you can create an {{ic|/etc/modprobe.d/broadcom.conf}}:<br />
<br />
softdep tg3 pre: broadcom<br />
<br />
{{Note|These methods may work for other chipsets, such as BCM57760.}}<br />
<br />
=== Realtek RTL8111/8168B ===<br />
<br />
{{hc|<nowiki># lspci | grep Ethernet</nowiki>|<br />
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)<br />
}}<br />
<br />
The adapter should be recognized by the {{ic|r8169}} module. However, with some chip revisions the connection may go off and on all the time. The alternative {{Pkg|r8168}} can be found in the [[official repositories]] and should be used for a reliable connection in this case. [[Kernel_modules#Blacklisting|Blacklist]] {{ic|r8169}}, if {{Pkg|r8168}} is not automatically loaded by [[udev]] add it to your list of user specified [[Kernel_modules#Loading|modules]].<br />
<br />
{{Accuracy|"some revisions", no proof the driver is the cause, and not e.g poorly configured DNS servers}}<br />
<br />
Another fault in the drivers for some revisions of this adapter is poor IPv6 support. [[IPv6#Disable functionality]] can be helpful if you encounter issues such as hanging webpages and slow speeds.<br />
<br />
=== Gigabyte Motherboard with Realtek 8111/8168/8411 ===<br />
With motherboards such as the Gigabyte GA-990FXA-UD3, booting with IOMMU off (which can be the default) will cause the network interface to be unreliable, often failing to connect or connecting but allowing no throughput. This will apply not only to the onboard NIC, but any other pci-NIC you put in the box because the IOMMU setting affects the entire network interface on the board. Enabling IOMMU and booting with the install media will throw AMD I-10/xhci page faults for a second, but then boot normally, resulting in a fully functional onboard NIC (even with the r8169 module).<br />
<br />
When configuring the boot process for your installation, add {{ic|1=iommu=soft}} as a [[kernel parameter]] to eliminate the error messages on boot and restore USB3.0 functionality.</div>SamSpadehttps://wiki.archlinux.org/index.php?title=Systemd-networkd&diff=435270Systemd-networkd2016-05-17T13:09:10Z<p>SamSpade: /* link files */</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Network configuration]]<br />
[[Category:Virtualization]]<br />
[[es:Systemd-networkd]]<br />
[[fr:systemd-networkd]]<br />
[[ja:systemd-networkd]]<br />
[[ru:Systemd-networkd]]<br />
{{Related articles start}}<br />
{{Related|systemd}}<br />
{{Related|systemd-nspawn}}<br />
{{Related|Network bridge}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related|:Category:Network configuration}}<br />
{{Related articles end}}<br />
<br />
''systemd-networkd'' is a system daemon that manages network configurations. It detects and configures network devices as they appear; it can also create virtual network devices. This service can be especially useful to set up complex network configurations for a container managed by [[systemd-nspawn]] or for virtual machines. It also works fine on simple connections.<br />
<br />
== Basic usage ==<br />
The {{Pkg|systemd}} package is part of the default Arch installation and contains all needed files to operate a wired network. Wireless adapters can be setup by other services, such as [[wpa_supplicant]], which are covered later in this article.<br />
<br />
=== Required services and setup ===<br />
<br />
To use ''systemd-networkd'', [[start]] the following two services and [[enable]] them to run on system boot:<br />
<br />
* {{ic|systemd-networkd.service}}<br />
* {{ic|systemd-resolved.service}}<br />
<br />
{{Note|''systemd-resolved'' is actually required only if you are specifying DNS entries in ''.network'' files or if you want to obtain DNS addresses from networkd's DHCP client.}}<br />
<br />
For compatibility with [[resolv.conf]], delete or rename the existing file and create the following symbolic link:<br />
<br />
# ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf<br />
<br />
Optionally, if you wish to use the local DNS stub resolver of ''systemd-resolved'' (and thus use LLMNR and DNS merging per interface), replace {{ic|dns}} with {{ic|resolve}} in {{ic|/etc/nsswitch.conf}}:<br />
<br />
hosts: files '''resolve''' myhostname<br />
<br />
See {{ic|man systemd-resolved}} and {{ic|man resolved.conf}} and [https://github.com/systemd/systemd/blob/master/README#L205 Systemd README].<br />
<br />
{{Note|Systemd's {{ic|resolve}} may not search the local domain when given just the hostname, even when {{ic|1=UseDomains=yes}} or {{ic|1=Domains=[domain-list]}} is present in the appropriate {{ic|.network}} file, and that file produces the expected {{ic|search [domain-list]}} in {{ic|resolv.conf}}. If you run into this problem:<br />
* Switch to using fully-qualified domain names<br />
* Use {{ic|/etc/hosts}} to resolve hostnames<br />
* Fall back to using glibc's {{ic|dns}} instead of using systemd's {{ic|resolve}}}}<br />
<br />
=== Configuration examples ===<br />
All configurations in this section are stored as {{ic|foo.network}} in {{ic|/etc/systemd/network}}. For a full listing of options and processing order, see [[#Configuration files]] and the {{ic|systemd.network}} man page.<br />
<br />
Systemd/udev automatically assigns predictable, stable network interface names for all local Ethernet, WLAN, and WWAN interfaces. Use {{ic|networkctl list}} to list the devices on the system.<br />
<br />
After making changes to a configuration file, [[restart]] {{ic|systemd-networkd.service}}.<br />
<br />
{{Note|In the examples below, '''enp1s0''' is the wired adapter and '''wlp2s0''' is the wireless adapter. These names can be different on different systems.}}<br />
<br />
==== Wired adapter using DHCP ====<br />
{{hc|/etc/systemd/network/''wired''.network|<nowiki><br />
[Match]<br />
Name=enp1s0<br />
<br />
[Network]<br />
DHCP=ipv4</nowiki><br />
}}<br />
<br />
==== Wired adapter using a static IP ====<br />
{{hc|/etc/systemd/network/''wired''.network|<nowiki><br />
[Match]<br />
Name=enp1s0<br />
<br />
[Network]<br />
Address=10.1.10.9/24<br />
Gateway=10.1.10.1</nowiki><br />
}}<br />
<br />
See the {{ic|systemd.network(5)}} man page for more network options such as specifying DNS servers and a broadcast address.<br />
<br />
==== Wireless adapter ====<br />
In order to connect to a wireless network with ''systemd-networkd'', a wireless adapter configured with another service such as [[wpa_supplicant]] is required. In this example, the corresponding systemd service file that needs to be enabled is {{ic|wpa_supplicant@wlp2s0.service}}.<br />
<br />
{{hc|/etc/systemd/network/''wireless''.network|<nowiki><br />
[Match]<br />
Name=wlp2s0<br />
<br />
[Network]<br />
DHCP=ipv4<br />
</nowiki>}}<br />
<br />
If the wireless adapter has a static IP address, the configuration is the same (except for the interface name) as in a [[#Wired adapter using a static IP|wired adapter]].<br />
<br />
==== Wired and wireless adapters on the same machine ====<br />
<br />
This setup will enable a DHCP IP for both a wired and wireless connection making use of the metric directive to allow the kernel the decide on-the-fly which one to use. This way, no connection downtime is observed when the wired connection is unplugged.<br />
<br />
The kernel's route metric (same as configured with ''ip'') decides which route to use for outgoing packets, in cases when several match. This will be the case when both wireless and wired devices on the system have active connections. To break the tie, the kernel uses the metric. If one of the connections is terminated, the other automatically wins without there being a gap with nothing configured (ongoing transfers may still not deal with this nicely but that is at a different OSI layer).<br />
<br />
{{Note|The '''Metric''' option is for static routes while the '''RouteMetric''' option is for setups not using static routes.}}<br />
<br />
{{hc|/etc/systemd/network/''wired''.network|<nowiki><br />
[Match]<br />
Name=enp1s0<br />
<br />
[Network]<br />
DHCP=ipv4<br />
<br />
[DHCP]<br />
RouteMetric=10<br />
</nowiki>}}<br />
<br />
{{hc|/etc/systemd/network/''wireless''.network|<nowiki><br />
[Match]<br />
Name=wlp2s0<br />
<br />
[Network]<br />
DHCP=ipv4<br />
<br />
[DHCP]<br />
RouteMetric=20<br />
</nowiki>}}<br />
<br />
==== IPv6 privacy extensions ====<br />
<br />
If you are using IPv6 you might also want to set the {{ic|IPv6PrivacyExtensions}} option as settings placed in {{ic|/etc/sysctl.d/40-ipv6.conf}} are not honored.<br />
<br />
{{hc|/etc/systemd/network/''wireless''.network|<nowiki><br />
[Match]<br />
Name=wlp2s0<br />
<br />
[Network]<br />
DHCP=yes<br />
IPv6PrivacyExtensions=true<br />
<br />
[DHCP]<br />
RouteMetric=20<br />
</nowiki>}}<br />
<br />
== Configuration files ==<br />
<br />
Configuration files are located in {{ic|/usr/lib/systemd/network}}, the volatile runtime network directory {{ic|/run/systemd/network}} and, the local administration network directory {{ic|/etc/systemd/network}}. Files in {{ic|/etc/systemd/network}} have the highest priority.<br />
<br />
There are three types of configuration files. <br />
<br />
* '''.network''' files. They will apply a network configuration for a ''matching'' device<br />
* '''.netdev''' files. They will create a ''virtual network device'' for a ''matching'' environment<br />
* '''.link''' files. When a network device appears, [[udev]] will look for the first ''matching'' '''.link''' file<br />
<br />
They all follow the same rules: <br />
<br />
* If '''all''' conditions in the {{ic|[Match]}} section are matched, the profile will be activated<br />
* an empty {{ic|[Match]}} section means the profile will apply in any case (can be compared to the {{ic|*}} joker)<br />
* each entry is a key with the {{ic|1=NAME=VALUE}} syntax <br />
* all configuration files are collectively sorted and processed in lexical order, regardless of the directory in which they live<br />
* files with identical name replace each other<br />
<br />
{{Tip|<br />
* to override a system-supplied file in {{ic|/usr/lib/systemd/network}} in a permanent manner (i.e even after upgrade), place a file with same name in {{ic|/etc/systemd/network}} and symlink it to {{ic|/dev/null}}<br />
* the {{ic|*}} joker can be used in {{ic|VALUE}} (e.g {{ic|en*}} will match any Ethernet device)<br />
* following this [https://mailman.archlinux.org/pipermail/arch-general/2014-March/035381.html Arch-general thread], the best practice is to setup specific container network settings ''inside the container'' with '''networkd''' configuration files.<br />
}}<br />
<br />
=== network files ===<br />
<br />
These files are aimed at setting network configuration variables, especially for servers and containers.<br />
<br />
Below is a basic structure of a {{ic|''MyProfile''.network}} file:<br />
<br />
{{hc|/etc/systemd/network/''MyProfile''.network|<br />
[Match]<br />
''a vertical list of keys''<br />
<br />
[Network]<br />
''a vertical list of keys''<br />
<br />
[Address]<br />
''a vertical list of keys''<br />
<br />
[Route]<br />
''a vertical list of keys''<br />
}}<br />
<br />
==== [Match] section ====<br />
<br />
Most common keys are:<br />
<br />
* {{ic|1=Name=}} the device name (e.g Br0, enp4s0, en*)<br />
* {{ic|1=Host=}} the machine hostname<br />
* {{ic|1=Virtualization=}} check whether the system is executed in a virtualized environment or not. A {{ic|1=Virtualization=no}} key will only apply on your host machine, while {{ic|1=Virtualization=yes}} apply to any container or VM.<br />
<br />
==== [Link] section ====<br />
<br />
Most common keys are:<br />
<br />
* {{ic|1=MACAddress=}} useful for [[MAC_address_spoofing#Method_1:_systemd-networkd|MAC address spoofing]]<br />
* {{ic|1=MTUBytes=}} the maximum transmission unit in bytes (suffixes K, M, G, are supported and are understood to the base of 1024). Using a larger MTU value ([[Jumbo frames]]) can significantly speed up your network transfers.<br />
<br />
==== [Network] section ====<br />
<br />
Most common keys are:<br />
<br />
* {{ic|1=DHCP=}} enables [[Wikipedia:Dynamic Host Configuration Protocol|DHCPv4]] and/or DHCPv6 support. Accepts {{ic|yes}}, {{ic|no}}, {{ic|ipv4}} or {{ic|ipv6}}<br />
* {{ic|1=DNS=}} is a [[Wikipedia:Domain Name System|DNS]] server address. You can specify this option more than once<br />
* {{ic|1=Bridge=}} is the name of the bridge to add the link to<br />
* {{ic|1=IPForward=}} defaults to {{ic|no}}. It enables IP forwarding, performing the forwarding according to the routing table and is required for setting up [[Internet sharing]]. Note that turning {{ic|1=IPForward=}} on applies to ''all'' network interfaces. <br />
* {{ic|1=Domains=}} a list of the domains used for DNS host name resolution.<br />
<br />
Please see {{ic|systemd.network(5)}} for details.<br />
<br />
==== [Address] section ====<br />
Most common key in the {{ic|[Address]}} section is:<br />
<br />
* {{ic|1=Address=}} is a static '''IPv4''' or '''IPv6''' address and its prefix length, separated by a {{ic|/}} character (e.g {{ic|192.168.1.90/24}}). This option is '''mandatory''' unless DHCP is used.<br />
<br />
==== [Route] section ====<br />
Most common key in the {{ic|[Route]}} section is:<br />
<br />
* {{ic|1=Gateway=}} is the address of your machine gateway. This option is '''mandatory''' unless DHCP is used.<br />
For an exhaustive key list, please refer to {{ic|systemd.network(5)}}<br />
<br />
{{Tip|you can put the {{ic|1=Address=}} and {{ic|1=Gateway=}} keys in the {{ic|[Network]}} section as a short-hand if {{ic|1=Address=}} contains only an Address key and {{ic|1=Gateway=}} section contains only a Gateway key<br />
}}<br />
<br />
=== netdev files ===<br />
<br />
These files will create virtual network devices.<br />
<br />
Below is a basic structure of a ''Mydevice''.netdev file:<br />
<br />
{{hc|/etc/systemd/network/''MyDevice''.netdev|<br />
[Match]<br />
''a vertical list of keys''<br />
<br />
[NetDev]<br />
''a vertical list of keys''<br />
}}<br />
<br />
==== [Match] section ====<br />
<br />
Most common keys are {{ic|1=Host=}} and {{ic|1=Virtualization=}}<br />
<br />
==== [NetDev] section ====<br />
<br />
Most common keys are:<br />
<br />
* {{ic|1=Name=}} is the interface name used when creating the netdev. This option is '''compulsory'''<br />
* {{ic|1=Kind=}} is the netdev kind. For example, ''bridge'', ''bond'', ''vlan'', ''veth'', ''sit'', etc. are supported. This option is '''compulsory'''<br />
<br />
For an exhaustive key list, please refer to {{ic|systemd.netdev(5)}}<br />
<br />
=== link files ===<br />
<br />
These files are an alternative to custom udev rules and will be applied by [[udev]] as the device appears.<br />
<br />
Below is a basic structure of a ''Mydevice''.link file:<br />
<br />
{{hc|/etc/systemd/network/''MyDevice''.link|<br />
[Match]<br />
''a vertical list of keys''<br />
<br />
[Link]<br />
''a vertical list of keys''<br />
}}<br />
<br />
The {{ic|[Match]}} section will determine if a given link file may be applied to a given device, when the {{ic|[Link]}} section specifies the device configuration.<br />
<br />
==== [Match] section ====<br />
<br />
Most common keys are {{ic|1=MACAddress=}}, {{ic|1=Host=}} and {{ic|1=Virtualization=}}.<br />
<br />
{{ic|1=Type=}} is the device type (e.g. vlan)<br />
<br />
==== [Link] section ====<br />
<br />
Most common keys are:<br />
<br />
{{ic|1=MACAddressPolicy=}} is either ''persistent'' when the hardware has a persistent MAC address (as most hardware should) or ''random'' , which allows to give a random MAC address when the device appears.<br />
<br />
{{ic|1=MACAddress=}} shall be used when no {{ic|1=MACAddressPolicy=}} is specified.<br />
<br />
{{Note|the system {{ic|/usr/lib/systemd/network/99-default.link}} is generally sufficient for most of the basic cases.}}<br />
<br />
==== Renaming an interface ====<br />
Instead of editing udev rules, a .link file can be used to rename an interface. A useful example is to set a predictable interface name for a USB-to-Ethernet adapter based on its MAC address, as those adapters are usually given different names depending on which USB port they are plugged into.<br />
{{hc|head=/etc/systemd/network/10-ethusb0.link|output=<br />
[Match]<br />
MACAddress=12:34:56:78:90:ab<br />
<br />
[Link]<br />
Description=USB to Ethernet Adapter<br />
Name=ethusb0<br />
}}<br />
<br />
{{Note|The default link file {{ic|/usr/lib/systemd/network/99-default.link}} is shipped by the system. Any user-supplied .link '''should''' have a lexically earlier file name to be considered at all. For example, name the file {{ic|10-ethusb0.link }} and not {{ic|ethusb0.link}}.}}<br />
<br />
== Usage with containers ==<br />
<br />
The service is available with {{Pkg|systemd}} >= 210. You will want to [[systemd#Basic systemctl usage|enable and start]] the {{ic|systemd-networkd.service}} on the host and container.<br />
<br />
For debugging purposes, it is strongly advised to [[install]] the {{Pkg|bridge-utils}}, {{Pkg|net-tools}} and {{Pkg|iproute2}} packages.<br />
<br />
If you are using ''systemd-nspawn'', you may need to modify the {{ic|systemd-nspawn@.service}} and append boot options to the {{ic|ExecStart}} line. Please refer to {{ic|man 1 systemd-nspawn}} for an exhaustive list of options.<br />
<br />
Note that if you want to take advantage of automatic DNS configuration from DHCP, you need to enable {{ic|systemd-resolved}} and symlink {{ic|/run/systemd/resolve/resolv.conf}} to {{ic|/etc/resolv.conf}}. See {{ic|systemd-resolved.service(8)}} for more details.<br />
<br />
{{Style|Too many points for a tip, some of them are very similar so they could be merged.}}<br />
<br />
{{Tip|1=Before you start to configure your container network, it is useful to:<br />
* disable all your [[netctl]] services. This will avoid any potential conflicts with {{ic|systemd-networkd}} and make all your configurations easier to test. Furthermore, odds are high you will end with few or even no [[netctl]] activated profiles. The {{ic|netctl list}} command will output a list of all your profiles, with the activated one being starred.<br />
* disable the {{ic|systemd-nspawn@.service}} and use the {{ic|systemd-nspawn -bnD /path_to/your_container/}} command as root to boot the container. To log off and shutdown inside the container {{ic|systemctl poweroff}} is used as root. Once the network setting meets your requirements, [[systemd#Basic systemctl usage|enable and start]] {{ic|systemd-nspawn@.service}}<br />
* disable the {{ic|dhcpcd.service}} if enabled on your system, since it activates ''dhcpcd'' on '''all''' interfaces<br />
* make sure you have no [[netctl]] profiles activated in the container, and ensure that {{ic|systemd-networkd.service}} is neither enabled nor started<br />
* make sure you do not have any [[iptables]] rules which can block traffic<br />
* make sure ''packet forwarding'' is [[Internet sharing#Enable packet forwarding|enabled]] if you want to let containers access the internet. Make sure that your {{ic|.network}} file does not accidentally turn off forwarding because if you do not have a {{ic|1=IPForward=1}} setting in it, {{ic|systemd-networkd}} will turn off forwarding on this interface, even if you have it enabled globally.<br />
* when the daemon is started the systemd {{ic|networkctl}} command displays the status of network interfaces.<br />
}}<br />
<br />
{{Note|For the set-up described below, <br />
* we will limit the output of the {{ic|ip a}} command to the concerned interfaces<br />
* we assume the ''host'' is your main OS you are booting to and the ''container'' is your guest virtual machine<br />
* all interface names and IP addresses are only examples<br />
}}<br />
<br />
=== Basic DHCP network ===<br />
<br />
This setup will enable a DHCP IP for host and container. In this case, both systems will share the same IP as they share the same interfaces.<br />
<br />
{{hc|/etc/systemd/network/''MyDhcp''.network|<nowiki><br />
[Match]<br />
Name=en*<br />
<br />
[Network]<br />
DHCP=ipv4<br />
</nowiki>}}<br />
<br />
Then, [[enable]] and start {{ic|systemd-networkd.service}} on your container.<br />
<br />
You can of course replace {{ic|en*}} by the full name of your ethernet device given by the output of the {{ic|ip link}} command.<br />
<br />
* on host and container:<br />
<br />
{{hc|$ ip a|<br />
2: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
link/ether 14:da:e9:b5:7a:88 brd ff:ff:ff:ff:ff:ff<br />
inet 192.168.1.72/24 brd 192.168.1.255 scope global enp7s0<br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::16da:e9ff:feb5:7a88/64 scope link <br />
valid_lft forever preferred_lft forever<br />
}}<br />
<br />
By default, hostname received from the DHCP server will be used as the transient hostname.<br />
<br />
To change it add {{ic|1=UseHostname=false}} in section {{ic|[DHCPv4]}}<br />
{{hc|/etc/systemd/network/''MyDhcp''.network|<nowiki><br />
[DHCPv4]<br />
UseHostname=false<br />
</nowiki>}}<br />
<br />
If you did not want to configure a DNS in {{ic|/etc/resolv.conf}} and want to rely on DHCP for setting it up, you need to [[enable]] {{ic|systemd-resolved.service}} and symlink {{ic|/run/systemd/resolve/resolv.conf}} to {{ic|/etc/resolv.conf}}<br />
<br />
# ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf<br />
<br />
See {{ic|systemd-resolved.service(8)}} for more details.<br />
<br />
=== DHCP with two distinct IP ===<br />
<br />
==== Bridge interface ====<br />
<br />
Create a virtual bridge interface <br />
<br />
{{hc|/etc/systemd/network/''MyBridge''.netdev|<nowiki><br />
[NetDev]<br />
Name=br0<br />
Kind=bridge<br />
</nowiki>}}<br />
<br />
[[Restart]] {{ic|systemd-networkd.service}} to have systemd create the bridge.<br />
<br />
On host and container:<br />
<br />
{{hc|$ ip a|<br />
3: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default <br />
link/ether ae:bd:35:ea:0c:c9 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
Note that the interface br0 is listed but is DOWN.<br />
<br />
==== Bind ethernet to bridge ====<br />
<br />
Modify the {{ic|/etc/systemd/network/''MyDhcp''.network}} to remove the DHCP, as the bridge requires an interface to bind to with no IP, and add a key to bind this device to br0. Let us change its name to a more relevant one.<br />
<br />
{{hc|/etc/systemd/network/''MyEth''.network|<nowiki><br />
[Match]<br />
Name=en*<br />
<br />
[Network]<br />
Bridge=br0<br />
</nowiki>}}<br />
<br />
==== Bridge network ====<br />
<br />
Create a network profile for the Bridge<br />
<br />
{{hc|/etc/systemd/network/''MyBridge''.network|<nowiki><br />
[Match]<br />
Name=br0<br />
<br />
[Network]<br />
DHCP=ipv4<br />
</nowiki>}}<br />
<br />
==== Add option to boot the container ====<br />
<br />
As we want to give a separate IP for host and container, we need to ''Disconnect'' networking of the container from the host. To do this, add this option {{ic|1=--network-bridge=br0}} to your container boot command.<br />
<br />
# systemd-nspawn --network-bridge&#61;br0 -bD /path_to/my_container<br />
<br />
==== Result ====<br />
<br />
* on host<br />
<br />
{{hc|$ ip a|<br />
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default <br />
link/ether 14:da:e9:b5:7a:88 brd ff:ff:ff:ff:ff:ff<br />
inet 192.168.1.87/24 brd 192.168.1.255 scope global br0<br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::16da:e9ff:feb5:7a88/64 scope link <br />
valid_lft forever preferred_lft forever<br />
6: vb-''MyContainer'': <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000<br />
link/ether d2:7c:97:97:37:25 brd ff:ff:ff:ff:ff:ff<br />
inet6 fe80::d07c:97ff:fe97:3725/64 scope link <br />
valid_lft forever preferred_lft forever<br />
}}<br />
<br />
* on container<br />
<br />
{{hc|$ ip a|<br />
2: host0: <BROADCAST,MULTICAST,ALLMULTI,AUTOMEDIA,NOTRAILERS,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
link/ether 5e:96:85:83:a8:5d brd ff:ff:ff:ff:ff:ff<br />
inet 192.168.1.73/24 brd 192.168.1.255 scope global host0<br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5c96:85ff:fe83:a85d/64 scope link <br />
valid_lft forever preferred_lft forever<br />
}}<br />
<br />
==== Notice ====<br />
<br />
* we have now one IP address for Br0 on the host, and one for host0 in the container<br />
* two new interfaces have appeared: {{ic|vb-''MyContainer''}} in the host and {{ic|host0}} in the container. This comes as a result of the {{ic|1=--network-bridge=br0}} option. This option ''implies'' another option, {{ic|--network-veth}}. This means a ''virtual Ethernet link'' has been created between host and container.<br />
* the DHCP address on {{ic|host0}} comes from the system {{ic|/usr/lib/systemd/network/80-container-host0.network}} file.<br />
* on host<br />
<br />
{{hc|$ brctl show|<br />
bridge name bridge id STP enabled interfaces<br />
br0 8000.14dae9b57a88 no enp7s0<br />
vb-''MyContainer''<br />
}}<br />
<br />
the above command output confirms we have a bridge with two interfaces binded to.<br />
<br />
* on host<br />
<br />
{{hc|$ ip route|<br />
default via 192.168.1.254 dev br0 <br />
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.87<br />
}}<br />
<br />
* on container<br />
<br />
{{hc|$ ip route|<br />
default via 192.168.1.254 dev host0 <br />
192.168.1.0/24 dev host0 proto kernel scope link src 192.168.1.73<br />
}}<br />
<br />
the above command outputs confirm we have activated {{ic|br0}} and {{ic|host0}} interfaces with an IP address and Gateway 192.168.1.254. The gateway address has been automatically grabbed by ''systemd-networkd''<br />
<br />
{{hc|$ cat /run/systemd/resolve/resolv.conf|<br />
nameserver 192.168.1.254<br />
}}<br />
<br />
=== Static IP network ===<br />
<br />
Setting a static IP for each device can be helpful in case of deployed web services (e.g FTP, http, SSH). Each device will keep the same MAC address across reboots if your system {{ic|/usr/lib/systemd/network/99-default.link}} file has the {{ic|1=MACAddressPolicy=persistent}} option (it has by default). Thus, you will easily route any service on your Gateway to the desired device.<br />
First, we shall get rid of the system {{ic|/usr/lib/systemd/network/80-container-host0.network}} file. To do it in a permanent way (e.g even after upgrades), do the following on container. This will mask the file {{ic|/usr/lib/systemd/network/80-container-host0.network}} since files of the same name in {{ic|/etc/systemd/network}} take priority over {{ic|/usr/lib/systemd/network}}.<br />
<br />
# ln -sf /dev/null /etc/systemd/network/80-container-host0.network<br />
<br />
Then, [[systemd#Basic systemctl usage|enable and start]] {{ic|systemd-networkd}} on your container.<br />
<br />
The needed configuration files:<br />
* on host <br />
{{Accuracy|In the listing of configuration files, /etc/systemd/network/MyBridge.netdev has the .netdev extension. But, the MyBridge.network example file has the .network extension.}}<br />
<br />
/etc/systemd/network/''MyBridge''.netdev<br />
/etc/systemd/network/''MyEth''.network<br />
<br />
A modified ''MyBridge''.network<br />
<br />
{{hc|/etc/systemd/network/''MyBridge''.network|<nowiki><br />
[Match]<br />
Name=br0<br />
<br />
[Network]<br />
DNS=192.168.1.254<br />
Address=192.168.1.87/24<br />
Gateway=192.168.1.254<br />
</nowiki>}}<br />
<br />
* on container<br />
<br />
{{hc|/etc/systemd/network/''MyVeth''.network|<nowiki><br />
[Match]<br />
Name=host0<br />
<br />
[Network]<br />
DNS=192.168.1.254<br />
Address=192.168.1.94/24<br />
Gateway=192.168.1.254<br />
</nowiki>}}<br />
<br />
== Management and Desktop integration ==<br />
<br />
''systemd-networkd'' doesn't have a proper interactive management interface via either command-line or GUI. ''networkctl'' (via CLI) just offers a simple dump of the network interface states.<br />
<br />
When ''networkd'' is configured with [[wpa_supplicant]], both ''wpa_cli'' and ''wpa_gui'' offer the ability to associate and reconfigure WLAN interfaces dynamically.<br />
<br />
[https://github.com/wavexx/networkd-notify networkd-notify] can generate simple notifications in response to network interface state changes (such as connection/disconnection and re-association).<br />
<br />
<br />
== See also ==<br />
<br />
* [http://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html systemd.networkd man page]<br />
* [https://plus.google.com/u/0/+TomGundersen/posts Tom Gundersen, main systemd-networkd developer, G+ home page]<br />
* [https://coreos.com/blog/intro-to-systemd-networkd/ Tom Gundersen posts on Core OS blog]<br />
* [https://bbs.archlinux.org/viewtopic.php?pid=1393759#p1393759 How to set up systemd-networkd with wpa_supplicant] (WonderWoofy's walkthrough on Arch forums)</div>SamSpadehttps://wiki.archlinux.org/index.php?title=OpenSSH&diff=232080OpenSSH2012-10-28T05:09:05Z<p>SamSpade: /* Enabling the sshd daemon under a native systemd system */</p>
<hr />
<div>[[Category:Daemons and system services]]<br />
[[Category:Secure Shell]]<br />
[[es:Secure Shell]]<br />
[[fr:ssh]]<br />
[[it:Secure Shell]]<br />
[[ko:Secure Shell]]<br />
[[pl:Secure Shell]]<br />
[[pt:Secure Shell]]<br />
[[ru:Secure Shell]]<br />
[[sr:Secure Shell]]<br />
[[zh-CN:Secure Shell]]<br />
'''Secure Shell''' ('''SSH''') is a network protocol that allows data to be exchanged over a secure channel between two computers. Encryption provides confidentiality and integrity of data. SSH uses public-key cryptography to authenticate the remote computer and allow the remote computer to authenticate the user, if necessary.<br />
<br />
SSH is typically used to log into a remote machine and execute commands, but it also supports tunneling, forwarding arbitrary TCP ports and X11 connections; file transfer can be accomplished using the associated SFTP or SCP protocols.<br />
<br />
An SSH server, by default, listens on the standard TCP port 22. An SSH client program is typically used for establishing connections to an ''sshd'' daemon accepting remote connections. Both are commonly present on most modern operating systems, including Mac OS X, GNU/Linux, Solaris and OpenVMS. Proprietary, freeware and open source versions of various levels of complexity and completeness exist.<br />
<br />
(Source: [[Wikipedia:Secure Shell]])<br />
<br />
== OpenSSH ==<br />
OpenSSH (OpenBSD Secure Shell) is a set of computer programs providing encrypted communication sessions over a computer network using the ssh protocol. It was created as an open source alternative to the proprietary Secure Shell software suite offered by SSH Communications Security. OpenSSH is developed as part of the OpenBSD project, which is led by Theo de Raadt.<br />
<br />
OpenSSH is occasionally confused with the similarly-named OpenSSL; however, the projects have different purposes and are developed by different teams, the similar name is drawn only from similar goals.<br />
<br />
=== Installing OpenSSH ===<br />
[[pacman|Install]] {{Pkg|openssh}} from the [[official repositories]].<br />
<br />
=== Configuring SSH ===<br />
====Client====<br />
The SSH client configuration file can be found and edited in {{ic|/etc/ssh/ssh_config}}.<br />
<br />
An example configuration: <br />
<br />
{{hc|/etc/ssh/ssh_config|<br />
# $OpenBSD: ssh_config,v 1.26 2010/01/11 01:39:46 dtucker Exp $<br />
<br />
# This is the ssh client system-wide configuration file. See<br />
# ssh_config(5) for more information. This file provides defaults for<br />
# users, and the values can be changed in per-user configuration files<br />
# or on the command line.<br />
<br />
# Configuration data is parsed as follows:<br />
# 1. command line options<br />
# 2. user-specific file<br />
# 3. system-wide file<br />
# Any configuration value is only changed the first time it is set.<br />
# Thus, host-specific definitions should be at the beginning of the<br />
# configuration file, and defaults at the end.<br />
<br />
# Site-wide defaults for some commonly used options. For a comprehensive<br />
# list of available options, their meanings and defaults, please see the<br />
# ssh_config(5) man page.<br />
<br />
# Host *<br />
# ForwardAgent no<br />
# ForwardX11 no<br />
# RhostsRSAAuthentication no<br />
# RSAAuthentication yes<br />
# PasswordAuthentication yes<br />
# HostbasedAuthentication no<br />
# GSSAPIAuthentication no<br />
# GSSAPIDelegateCredentials no<br />
# BatchMode no<br />
# CheckHostIP yes<br />
# AddressFamily any<br />
# ConnectTimeout 0<br />
# StrictHostKeyChecking ask<br />
# IdentityFile ~/.ssh/identity<br />
# IdentityFile ~/.ssh/id_rsa<br />
# IdentityFile ~/.ssh/id_dsa<br />
# Port 22<br />
# Protocol 2,1<br />
# Cipher 3des<br />
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc<br />
# MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160<br />
# EscapeChar ~<br />
# Tunnel no<br />
# TunnelDevice any:any<br />
# PermitLocalCommand no<br />
# VisualHostKey no<br />
# ProxyCommand ssh -q -W %h:%p gateway.example.com<br />
}}<br />
<br />
It is recommended to change the Protocol line into this:<br />
Protocol 2<br />
<br />
That means that only Protocol 2 will be used, since Protocol 1 is considered somewhat insecure.<br />
<br />
====Daemon====<br />
The SSH daemon configuration file can be found and edited in {{ic|/etc/ssh/ssh'''d'''_config}}.<br />
<br />
An example configuration: <br />
<br />
{{hc|/etc/ssh/sshd_config|2=<br />
# $OpenBSD: sshd_config,v 1.82 2010/09/06 17:10:19 naddy Exp $<br />
<br />
# This is the sshd server system-wide configuration file. See<br />
# sshd_config(5) for more information.<br />
<br />
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin<br />
<br />
# The strategy used for options in the default sshd_config shipped with<br />
# OpenSSH is to specify options with their default value where<br />
# possible, but leave them commented. Uncommented options change a<br />
# default value.<br />
<br />
#Port 22<br />
#AddressFamily any<br />
#ListenAddress 0.0.0.0<br />
#ListenAddress ::<br />
<br />
# The default requires explicit activation of protocol 1<br />
#Protocol 2<br />
<br />
# HostKey for protocol version 1<br />
#HostKey /etc/ssh/ssh_host_key<br />
# HostKeys for protocol version 2<br />
#HostKey /etc/ssh/ssh_host_rsa_key<br />
#HostKey /etc/ssh/ssh_host_dsa_key<br />
#HostKey /etc/ssh/ssh_host_ecdsa_key<br />
<br />
# Lifetime and size of ephemeral version 1 server key<br />
#KeyRegenerationInterval 1h<br />
#ServerKeyBits 1024<br />
<br />
# Logging<br />
# obsoletes QuietMode and FascistLogging<br />
#SyslogFacility AUTH<br />
#LogLevel INFO<br />
<br />
# Authentication:<br />
<br />
#LoginGraceTime 2m<br />
#PermitRootLogin yes<br />
#StrictModes yes<br />
#MaxAuthTries 6<br />
#MaxSessions 10<br />
<br />
#RSAAuthentication yes<br />
#PubkeyAuthentication yes<br />
#AuthorizedKeysFile .ssh/authorized_keys<br />
<br />
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts<br />
#RhostsRSAAuthentication no<br />
# similar for protocol version 2<br />
#HostbasedAuthentication no<br />
# Change to yes if you do not trust ~/.ssh/known_hosts for<br />
# RhostsRSAAuthentication and HostbasedAuthentication<br />
#IgnoreUserKnownHosts no<br />
# Don't read the user's ~/.rhosts and ~/.shosts files<br />
#IgnoreRhosts yes<br />
<br />
# To disable tunneled clear text passwords, change to no here!<br />
#PasswordAuthentication yes<br />
#PermitEmptyPasswords no<br />
<br />
# Change to no to disable s/key passwords<br />
ChallengeResponseAuthentication no<br />
<br />
# Kerberos options<br />
#KerberosAuthentication no<br />
#KerberosOrLocalPasswd yes<br />
#KerberosTicketCleanup yes<br />
#KerberosGetAFSToken no<br />
<br />
# GSSAPI options<br />
#GSSAPIAuthentication no<br />
#GSSAPICleanupCredentials yes<br />
<br />
# Set this to 'yes' to enable PAM authentication, account processing, <br />
# and session processing. If this is enabled, PAM authentication will <br />
# be allowed through the ChallengeResponseAuthentication and<br />
# PasswordAuthentication. Depending on your PAM configuration,<br />
# PAM authentication via ChallengeResponseAuthentication may bypass<br />
# the setting of "PermitRootLogin without-password".<br />
# If you just want the PAM account and session checks to run without<br />
# PAM authentication, then enable this but set PasswordAuthentication<br />
# and ChallengeResponseAuthentication to 'no'.<br />
UsePAM yes<br />
<br />
#AllowAgentForwarding yes<br />
#AllowTcpForwarding yes<br />
#GatewayPorts no<br />
#X11Forwarding no<br />
#X11DisplayOffset 10<br />
#X11UseLocalhost yes<br />
#PrintMotd yes<br />
#PrintLastLog yes<br />
#TCPKeepAlive yes<br />
#UseLogin no<br />
#UsePrivilegeSeparation yes<br />
#PermitUserEnvironment no<br />
#Compression delayed<br />
#ClientAliveInterval 0<br />
#ClientAliveCountMax 3<br />
#UseDNS yes<br />
#PidFile /var/run/sshd.pid<br />
#MaxStartups 10<br />
#PermitTunnel no<br />
#ChrootDirectory none<br />
<br />
# no default banner path<br />
#Banner none<br />
<br />
# override default of no subsystems<br />
Subsystem sftp /usr/lib/ssh/sftp-server<br />
<br />
# Example of overriding settings on a per-user basis<br />
#Match User anoncvs<br />
# X11Forwarding no<br />
# AllowTcpForwarding no<br />
# ForceCommand cvs server<br />
}}<br />
<br />
To allow access only for some users add this line:<br />
AllowUsers user1 user2<br />
<br />
To disable root login over SSH, change the PermitRootLogin line into this:<br />
PermitRootLogin no<br />
<br />
To add a nice welcome message edit the file {{ic|/etc/issue}} and change the Banner line into this:<br />
Banner /etc/issue<br />
<br />
{{Tip| You may want to change the default port from 22 to any higher port (see [http://en.wikipedia.org/wiki/Security_through_obscurity security through obscurity]).}} <br />
<br />
Even though the port ssh is running on could be detected by using a port-scanner like nmap, changing it will reduce the number of log entries caused by automated authentication attempts. To help select a port review the [[Wikipedia:List of TCP and UDP port numbers|list of TCP and UDP port numbers]].<br />
<br />
{{Tip|Disabling password logins entirely will greatly increase security, see [[SSH Keys]] for more information.}}<br />
<br />
=== Managing the sshd daemon ===<br />
Just add sshd to the "DAEMONS" array of your {{ic|/etc/[[rc.conf]]}}:<br />
DAEMONS=(... ... '''sshd''' ... ...)<br />
<br />
To start/restart/stop the daemon, use the following:<br />
# rc.d {start|stop|restart} sshd<br />
<br />
=== Enabling the sshd daemon under a native systemd system === <br />
You can enable the sshd daemon at startup with the following command:<br />
<br />
{{bc|# systemctl enable sshd.service}}<br />
<br />
{{Warning|Systemd is an asynchronous starting process. If you bind the SSH daemon to a specific IP address {{ic|ListenAddress 192.168.1.100}} it may fail to load during boot since the default sshd.service unit file has no dependency on network interfaces being enabled. When binding to an IP address, you will need to add {{ic|After&#61;network.target}} to a custom sshd.service unit file. See [[Systemd#Replacing_provided_unit_files]]. }}<br />
<br />
<br />
Or you can enable SSH Daemon socket so the daemon is started on the first incoming connection :<br />
<br />
{{bc|# systemctl enable sshd.socket}}<br />
<br />
===Connecting to the server===<br />
To connect to a server, run:<br />
$ ssh -p port user@server-address<br />
<br />
== Other SSH clients and servers ==<br />
Apart from OpenSSH, there are many [http://en.wikipedia.org/wiki/Comparison_of_SSH_clients SSH clients] and [http://en.wikipedia.org/wiki/Comparison_of_SSH_servers servers] avaliable.<br />
<br />
=== Dropbear ===<br />
[http://en.wikipedia.org/wiki/Dropbear_%28software%29 Dropbear] is ssh 2 client and server. It's only SSH2 capable (protocol 1 is considered insecure). You could install via [https://aur.archlinux.org/packages.php?ID=1657 AUR]<br />
<br />
The commandline ssh client is named dbclient. You could alias via<br />
alias ssh='dbclient'<br />
<br />
=== SSH alternative: Mobile Shell - responsive, survives disconnects ===<br />
From the Mosh website [http://mosh.mit.edu/] :<br />
<br />
Remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes. Mosh is a replacement for SSH. It's more robust and responsive, especially over Wi-Fi, cellular, and long-distance links.<br />
<br />
[[pacman|Install]] {{Pkg|mosh}} from the [[official repositories]] or the latest revision from {{AUR|mosh-git}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Encrypted SOCKS tunnel ===<br />
This is highly useful for laptop users connected to various unsafe wireless connections. The only thing you need is an SSH server running at a somewhat secure location, like your home or at work. It might be useful to use a dynamic DNS service like [http://www.dyndns.org/ DynDNS] so you do not have to remember your IP-address.<br />
<br />
==== Step 1: start the connection ====<br />
You only have to execute this single command to start the connection:<br />
$ ssh -ND 4711 user@host<br />
where {{Ic|"user"}} is your username at the SSH server running at the {{Ic|"host"}}. It will ask for your password, and then you're connected! The {{Ic|"N"}} flag disables the interactive prompt, and the {{Ic|"D"}} flag specifies the local port on which to listen on (you can choose any port number if you want).<br />
<br />
One way to make this easier is to put an alias line in your {{ic|~/.bashrc}} file as following:<br />
alias sshtunnel="ssh -ND 4711 -v user@host"<br />
It's nice to add the verbose {{Ic|"-v"}} flag, because then you can verify that it's actually connected from that output. Now you just have to execute the {{Ic|"sshtunnel"}} command :)<br />
<br />
==== Step 2: configure your browser (or other programs) ====<br />
The above step is completely useless if you do not configure your web browser (or other programs) to use this newly created socks tunnel. Since the current version of SSH supports both SOCKS4 and SOCKS5, you can use either of them.<br />
<br />
* For Firefox: ''Edit &rarr; Preferences &rarr; Advanced &rarr; Network &rarr; Connection &rarr; Setting'':<br />
: Check the ''"Manual proxy configuration"'' radio button, and enter "localhost" in the ''"SOCKS host"'' text field, and then enter your port number in the next text field (I used 4711 above).<br />
<br />
Firefox does not automatically make DNS requests through the socks tunnel. This potential privacy concern can be mitigated by the following steps:<br />
<br />
# Type about:config into the Firefox location bar.<br />
# Search for network.proxy.socks_remote_dns<br />
# Set the value to true.<br />
# Restart the browser.<br />
<br />
* For Chromium: You can set the SOCKS settings as environment variables or as command line options. I recommend to add one of the following functions to your {{ic|.bashrc}}:<br />
function secure_chromium {<br />
port=4711<br />
export SOCKS_SERVER=localhost:$port<br />
export SOCKS_VERSION=5<br />
chromium &<br />
exit<br />
}<br />
OR<br />
function secure_chromium {<br />
port=4711<br />
chromium --proxy-server="socks://localhost:$port" &<br />
exit<br />
}<br />
<br />
Now open a terminal and just do:<br />
$ secure_chromium<br />
<br />
Enjoy your secure tunnel!<br />
<br />
=== X11 forwarding ===<br />
To run graphical programs through a SSH connection you can enable X11 forwarding. An option needs to be set in the configuration files on the server and client (here "client" means your (desktop) machine your X11 Server runs on, and you will run X applications on the "server").<br />
<br />
[[pacman|Install]] {{Pkg|xorg-xauth}} from the [[official repositories]] onto the server.<br />
<br />
* Enable the '''AllowTcpForwarding''' option in {{ic|ssh'''d'''_config}} on the '''server'''.<br />
* Enable the '''X11Forwarding''' option in {{ic|ssh'''d'''_config}} on the '''server'''.<br />
* Set the '''X11DisplayOffset''' option in {{ic|ssh'''d'''_config}} on the '''server''' to 10.<br />
* Enable the '''X11UseLocalhost''' option in {{ic|ssh'''d'''_config}} on the '''server'''.<br />
Also:<br />
* Enable the '''ForwardX11''' option in {{ic|ssh_config}} on the '''client'''.<br />
<br />
Enable the '''ForwardX11Trusted''' can help when gui drawing badly.<br />
<br />
You need to restart the ssh daemon on the server for these changes to take effect, of course.<br />
<br />
To use the forwarding, log on to your server through ssh:<br />
$ ssh -X -p port user@server-address<br />
If you receive errors trying to run graphical applications try trusted forwarding instead:<br />
$ ssh -Y -p port user@server-address<br />
You can now start any X program on the remote server, the output will be forwarded to your local session:<br />
$ xclock<br />
<br />
<br />
If you get "Cannot open display" errors try the following command as the non root user:<br />
$ xhost +<br />
<br />
the above command will allow anybody to forward X11 applications. To restrict forwarding to a particular host type:<br />
$ xhost +hostname<br />
<br />
where hostname is the name of the particular host you want to forward to. Type "man xhost" for more details.<br />
<br />
Be careful with some applications as they check for a running instance on the local machine. Firefox is an example. Either close running Firefox or use the following start parameter to start a remote instance on the local machine<br />
$ firefox -no-remote<br />
<br />
If you get "X11 forwarding request failed on channel 0" when you connect (and the server /var/log/errors.log shows "Failed to allocate internet-domain X11 display socket"), try to either<br />
* Enable the '''AddressFamily any''' option in {{ic|ssh'''d'''_config}} on the '''server''', or<br />
* Set the '''AddressFamily''' option in {{ic|ssh'''d'''_config}} on the '''server''' to inet.<br />
Setting it to inet may fix problems with Ubuntu clients on IPv4.<br />
<br />
=== Forwarding other ports ===<br />
In addition to SSH's built-in support for X11, it can also be used to securely tunnel any TCP connection, by use of local forwarding or remote forwarding.<br />
<br />
Local forwarding opens a port on the local machine, connections to which will be forwarded to the remote host and from there on to a given destination. Very often, the forwarding destination will be the same as the remote host, thus providing a secure shell and, e.g. a secure VNC connection, to the same machine. Local forwarding is accomplished by means of the {{Ic|-L}} switch and it's accompanying forwarding specification in the form of {{Ic|<tunnel port>:<destination address>:<destination port>}}.<br />
<br />
Thus:<br />
<br />
$ ssh -L 1000:mail.google.com:25 192.168.0.100<br />
<br />
will use SSH to login to and open a shell on 192.168.0.100, and will also create a tunnel from the local machine's TCP port 1000 to mail.google.com on port 25. Once established, connections to localhost:1000 will connect to the Gmail SMTP port. To Google, it will appear that any such connection (though not necessarily the data conveyed over the connection) originated from 192.168.0.100, and such data will be secure as between the local machine and 192.168.0.100, but not between 192.168.0.100, unless other measures are taken.<br />
<br />
Similarly:<br />
<br />
$ ssh -L 2000:192.168.0.100:6001 192.168.0.100<br />
<br />
will allow connections to localhost:2000 which will be transparently sent to the remote host on port 6001. The preceding example is useful for VNC connections using the vncserver utility--part of the tightvnc package--which, though very useful, is explicit about its lack of security.<br />
<br />
Remote forwarding allows the remote host to connect to an arbitrary host via the SSH tunnel and the local machine, providing a functional reversal of local forwarding, and is useful for situations where, e.g., the remote host has limited connectivity due to firewalling. It is enabled with the {{Ic|-R}} switch and a forwarding specification in the form of {{Ic|<tunnel port>:<destination address>:<destination port>}}.<br />
<br />
Thus:<br />
<br />
$ ssh -R 3000:irc.freenode.net:6667 192.168.0.200<br />
<br />
will bring up a shell on 192.168.0.200, and connections from 192.168.0.200 to itself on port 3000 (remotely speaking, localhost:3000) will be sent over the tunnel to the local machine and then on to irc.freenode.net on port 6667, thus, in this example, allowing the use of IRC programs on the remote host to be used, even if port 6667 would normally be blocked to it.<br />
<br />
Both local and remote forwarding can be used to provide a secure "gateway," allowing other computers to take advantage of an SSH tunnel, without actually running SSH or the SSH daemon by providing a bind-address for the start of the tunnel as part of the forwarding specification, e.g. {{Ic|<tunnel address>:<tunnel port>:<destination address>:<destination port>}}. The {{Ic|<tunnel address>}} can be any address on the machine at the start of the tunnel, {{Ic|localhost}}, {{Ic|*}} (or blank), which, respectively, allow connections via the given address, via the loopback interface, or via any interface. By default, forwarding is limited to connections from the machine at the "beginning" of the tunnel, i.e. the {{Ic|<tunnel address>}} is set to {{Ic|localhost}}. Local forwarding requires no additional configuration, however remote forwarding is limited by the remote server's SSH daemon configuration. See the {{Ic|GatewayPorts}} option in {{Ic|sshd_config(5)}} for more information.<br />
<br />
=== Speeding up SSH ===<br />
You can make all sessions to the same host use a single connection, which will greatly speed up subsequent logins, by adding these lines under the proper host in {{ic|/etc/ssh/ssh_config}}:<br />
ControlMaster auto<br />
ControlPath ~/.ssh/socket-%r@%h:%p<br />
<br />
Changing the ciphers used by SSH to less cpu-demanding ones can improve speed. In this aspect, the best choices are arcfour and blowfish-cbc. '''Please do not do this unless you know what you are doing; arcfour has a number of known weaknesses'''. To use them, run SSH with the {{Ic|"c"}} flag, like this:<br />
$ ssh -c arcfour,blowfish-cbc user@server-address<br />
To use them permanently, add this line under the proper host in {{ic|/etc/ssh/ssh_config}}:<br />
Ciphers arcfour,blowfish-cbc<br />
Another option to improve speed is to enable compression with the {{Ic|"C"}} flag. A permanent solution is to add this line under the proper host in {{ic|/etc/ssh/ssh_config}}:<br />
Compression yes<br />
Login time can be shorten by using the {{Ic|"4"}} flag, which bypasses IPv6 lookup. This can be made permanent by adding this line under the proper host in {{ic|/etc/ssh/ssh_config}}:<br />
AddressFamily inet<br />
Another way of making these changes permanent is to create an alias in {{ic|~/.bashrc}}:<br />
alias ssh='ssh -C4c arcfour,blowfish-cbc'<br />
<br />
=== Mounting a remote filesystem with SSHFS ===<br />
Please refer to the [[Sshfs]] article to use sshfs to mount a remote system - accessible via SSH - to a local folder, so you will be able to do any operation on the mounted files with any tool (copy, rename, edit with vim, etc.). Using sshfs instead of shfs is generally preferred as a new version of shfs hasn't been released since 2004.<br />
<br />
=== Keep alive ===<br />
Your ssh session will automatically log out if it is idle. To keep the connection active (alive) add this to {{ic|~/.ssh/config}} or to {{ic|/etc/ssh/ssh_config}} on the client.<br />
<br />
ServerAliveInterval 120<br />
<br />
This will send a "keep alive" signal to the server every 120 seconds.<br />
<br />
Conversely, to keep incoming connections alive, you can set<br />
<br />
ClientAliveInterval 120<br />
<br />
(or some other number greater than 0) in {{ic|/etc/ssh/sshd_config}} on the server.<br />
<br />
=== Saving connection data in ssh config ===<br />
Whenever you want to connect to a ssh server, you usually have to type at least its address and the username. To save that typing work for servers you regularly connect to, you can use the personal {{ic|$HOME/.ssh/config}} or the global {{ic|/etc/ssh/ssh_config}} files as shown in the following example:<br />
<br />
{{hc|$HOME/.ssh/config|<br />
Host myserver<br />
HostName 123.123.123.123<br />
Port 12345<br />
User bob<br />
Host other_server<br />
HostName test.something.org<br />
User alice<br />
CheckHostIP no<br />
Cipher blowfish<br />
}}<br />
<br />
Now you can simply connect to the server by using the name you specified:<br />
<br />
$ ssh myserver<br />
<br />
To see a complete list of the possible options, check out ssh_config's manpage on your system or the [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config ssh_config documentation] on the official website.<br />
<br />
=== Changing the Bash prompt when logged in over SSH ===<br />
It can sometimes be useful to make a difference between your local and your remote prompt, in particular when they are both configured in the same way. To do that, just insert this in the remote server's bashrc file:<br />
<br />
{{hc|$HOME/.bashrc|2=<br />
if [ -n "$SSH_CLIENT" ]; then<br />
PS1='\[\e[0;33m\]\u@\h:\wSSH$\[\e[m\] '<br />
else<br />
PS1='\[\e[0;32m\]\u\[\e[m\] \[\e[1;34m\]\w\[\e[m\] \[\e[1;32m\]\$\[\ e[m\] '<br />
fi<br />
}}<br />
<br />
See [[Color Bash Prompt]] for more information about the PS1 variable customization.<br />
<br />
=== Automatically logout all SSH users when the sshd daemon is shutdown ===<br />
To automatically log out all remote ssh users when the sshd server system shuts down, for reboot or halt, add this line to /etc/rc.local.shutdown on the sshd server:<br />
<br />
who | cut -d " " -f1 | uniq | xargs pkill -KILL -u<br />
<br />
This prevents ssh client terminals from hanging during a lengthy timeout, which eventually ends with:<br />
<br />
Write failed: Broken pipe<br />
<br />
=== Autossh - automatically restarts SSH sessions and tunnels ===<br />
When a ssh session or tunnel cannot be kept alive, because for example bad network conditions cause the sshd client to disconnect, you can use [http://www.harding.motd.ca/autossh/ Autossh] to automatically restart them. Autossh can be installed from the [[official repositories]]. <br />
<br />
Usage examples:<br />
$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" username@example.com<br />
Combined with [[ sshfs ]]:<br />
$ sshfs -o reconnect,compression=yes,transform_symlinks,ServerAliveInterval=45,ServerAliveCountMax=2,ssh_command='autossh -M 0' username@example.com: /mnt/example <br />
Connecting through a SOCKS-proxy set by [[ Proxy_settings ]]:<br />
$ autossh -M 0 "ServerAliveInterval 45" -o "ServerAliveCountMax 2" -NCD 8080 username@example.com <br />
With the {{ic|-f}} option autossh can be made to run as a background process. Running it this way however means the passprase cannot be entered interactively.<br />
<br />
The session will end once you type {{ic|exit}} in the session, or the autossh process receives a SIGTERM, SIGINT of SIGKILL signal.<br />
<br />
== Troubleshooting ==<br />
=== Connection refused or timeout problem ===<br />
<br />
==== Is your router doing port forwarding? ====<br />
The first thing is to make sure that your router knows to forward any incoming ssh connection to your machine. Your external IP is given to you by your ISP, and it is associated with any requests coming out of your router. So your router needs to know that any incoming ssh connection to your external IP needs to be forwarded to your machine running sshd.<br />
<br />
Find your internal network address.<br />
<br />
ifconfig<br />
<br />
Find your interface device and look for the inet field. Then access your router's configuration web interface, using your router's IP (find this on the web). Tell your router to forward it to your inet IP. Go to [http://portforward.com/] for more instructions on how to do so for your particular router.<br />
<br />
==== Is SSH running and listening? ====<br />
# netstat -tnlp | grep ssh<br />
<br />
If the above command doesn't display anything, then SSH is NOT running. Check {{ic|/var/log/messages}} for errors etc.<br />
<br />
==== Are there firewall rules blocking the connection? ====<br />
Flush your iptables rules to make sure they are not interfering:<br />
<br />
# rc.d stop iptables<br />
<br />
or:<br />
<br />
# iptables -P INPUT ACCEPT<br />
# iptables -P OUTPUT ACCEPT<br />
# iptables -F INPUT<br />
# iptables -F OUTPUT<br />
<br />
==== Is the traffic even getting to your computer? ====<br />
Start a traffic dump on the computer you're having problems with:<br />
<br />
# tcpdump -lnn -i any port ssh and tcp-syn<br />
<br />
This should show some basic information, then wait for any matching traffic to happen before displaying it. Try your connection now. If you do not see any output when you attempt to connect, then something outside of your computer is blocking the traffic (e. g., hardware firewall, NAT router etc.).<br />
<br />
==== Your ISP or a third party blocking default port? ====<br />
{{Note|Try this step if you '''KNOW''' you aren't running any firewalls and you know you have configured the router for DMZ or have forwarded the port to your computer and it still doesn't work. Here you will find diagnostic steps and a possible solution.}}<br />
<br />
In some cases, your ISP might block the default port (SSH port 22) so whatever you try (opening ports, hardening the stack, defending against flood attacks, et al) ends up useless. To confirm this, create a server on all interfaces (0.0.0.0) and connect remotely. <br />
<br />
If you get an error message comparable to this:<br />
ssh: connect to host www.inet.hr port 22: Connection refused<br />
<br />
That means the port '''ISN'T ''' being blocked by the ISP, but the server doesn't run SSH on that port (See [http://en.wikipedia.org/wiki/Security_through_obscurity security through obscurity]).<br />
<br />
However, if you get an error message comparable to this:<br />
ssh: connect to host 111.222.333.444 port 22: Operation timed out <br />
<br />
That means that something is rejecting your TCP traffic on port 22. Basically that port is stealth, either by your firewall or 3rd party intervetion (like an ISP blocking and/or rejecting incoming traffic on port 22). If you know you aren't running any firewall on your computer, and you know that Gremlins aren't growing in your routers and switches, then your ISP is blocking the traffic.<br />
<br />
To double check, you can run Wireshark on your server and listen to traffic on port 22. Since Wireshark is a Layer 2 Packet Sniffing utility, and TCP/UDP are Layer 3 and above (See [http://en.wikipedia.org/wiki/TCP/IP_model IP Network stack]), if you don't receive anything while connecting remotely, a third party is most likely to be blocking the traffic on that port to your server.<br />
<br />
===== Diagnosis via Wireshark =====<br />
First install Wireshark using pacman.<br />
pacman -Sy wireshark-cli <br />
<br />
And then run it using,<br />
tshark -f "tcp port 22" -i NET_IF<br />
<br />
where NET_IF is the network interface for a WAN connection (see {{ic|ifconfig}} to check). If you aren't receiving any packets while trying to connect remotely, you can be very sure that your ISP is blocking the incoming traffic on port 22.<br />
<br />
===== Possible solution =====<br />
The solution is just to use some other port that the ISP isn't blocking. Open the {{ic|/etc/ssh/sshd_config}} and configure the file to use different ports. For example, add:<br />
<br />
Port 22<br />
Port 1234<br />
<br />
Also make sure that other "Port" configuration lines in the file are commented out. Just commenting "Port 22" and putting "Port 1234" won't solve the issue because then sshd will only listen on port 1234. Use both lines to run the SSH server on both ports. <br />
<br />
Restart the server {{ic|/etc/rc.d/sshd restart}} and you're almost done. You still have to configure your client(s) to use the other port instead of the default port. There are numerous solutions to that problem, but let's cover two of them here.<br />
<br />
===== Client configuration (Quick/Greedy fix) =====<br />
Create an alias in your {{ic|.bashrc}}. Instead of using {{ic|ssh -p 1234 user@myssh.domain.com}} every time you connect, create an alias. For example, add <br />
alias myssh='ssh -p 1234 user@myssh.domain.com' <br />
to your {{ic|.bashrc}} and restart bash. Just type {{ic|myssh}} and you'll connect !<br />
<br />
===== Client configuration 2 (Recommended/Systematic approach) =====<br />
Create or use {{ic|~/.ssh/config}} to solve the issue. Add the following lines:<br />
Host myssh.domain.com<br />
Port 1234<br />
<br />
And ssh will automatically use port 1234 on connecting without you excplicitly having to define the port while connecting. <br />
<br />
==== Read from socket failed: connection reset by peer ====<br />
Recent versions of openssh sometimes fail with the above error message, due to a bug involving elliptic curve cryptography. In that case, edit the file<br />
<br />
~/.ssh/config<br />
<br />
or create it, if it does not already exist. Add the line<br />
<br />
HostKeyAlgorithms ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss<br />
<br />
With openssh 5.9, the above fix doesn't work. Instead, put the following lines in {{ic|~/.ssh/config}}:<br />
<br />
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc <br />
MACs hmac-md5,hmac-sha1,hmac-ripemd160<br />
<br />
See also the [http://www.gossamer-threads.com/lists/openssh/dev/51339 discussion] on the openssh bug forum.<br />
<br />
=== "[your shell]: No such file or directory" / ssh_exchange_identification problem ===<br />
One possible cause for this is the need of certain SSH clients to find an absolute path (one returned by {{Ic|whereis -b [your shell]}}, for instance) in {{Ic|$SHELL}}, even if the shell's binary is located in one of the {{Ic|$PATH}} entries. Another reason can be that the user is no member of the ''network'' group.<br />
<br />
== See also ==<br />
*[[SSH Keys]]<br />
*[[Pam abl]]<br />
*[[fail2ban]]<br />
*[[sshguard]]<br />
*[[Sshfs]]<br />
*[[Syslog-ng]] : To send ssh log data to another file<br />
<br />
== Links & references ==<br />
*[http://www.soloport.com/iptables.html A Cure for the Common SSH Login Attack]<br />
*[http://www.la-samhna.de/library/brutessh.html Defending against brute force ssh attacks]<br />
*[http://www.ibm.com/developerworks/library/l-keyc/index.html OpenSSH key management, Part 1] and [http://www.ibm.com/developerworks/library/l-keyc2 Part 2] on IBM developerWorks</div>SamSpade