XFS (sda1): Mounting V1 Filesystem XFS (sda1): Ending clean mount Restart the VM, and then check if the problem is resolved. Reboot -f Repair the VM offline. Attach the system disk of the VM as a data disk to a recovery VM (any working Linux VM). As cstamas suggested, you can use ssh -v localhost. Uou simply ssh to yourself 127.0.0.1 on verbose mode, which will display debugging messages of the progress. Yes, through this process you can look at the top of the communication and you can get the SSH version that you are currently running. Teleport is an identity-aware, multi-protocol access proxy which understands SSH, HTTPS, Kubernetes API, MySQL and PostgreSQL wire protocols. On the server side, Teleport is a single binary which enables convenient secure access to behind-NAT resources such as: SSH nodes - SSH works in browsers too! Kubernetes clusters; PostgreSQL and MySQL. Provided that you are intentionally running some SSH server product, your goal would be to harden its configuration by disabling SSH v1 and insecure cipher suites (think MD5/SHA1, etc). Ultimately this is specific to what you are running, and would almost be a second question about that.
Name
ssh-keygen - authentication key generation, management and conversion
Synopsis
ssh-keygen [-q] [-bbits] -ttype [-Nnew_passphrase] [-Ccomment] [-foutput_keyfile]
ssh-keygen -p [-Pold_passphrase] [-Nnew_passphrase] [-fkeyfile]
ssh-keygen -i [-finput_keyfile]
ssh-keygen -e [-finput_keyfile]
ssh-keygen -y [-finput_keyfile]
ssh-keygen -c [-Ppassphrase] [-Ccomment] [-fkeyfile]
ssh-keygen -l [-finput_keyfile]
ssh-keygen -B [-finput_keyfile]
ssh-keygen -Dreader
ssh-keygen -Fhostname [-fknown_hosts_file] [-l]
ssh-keygen -H [-fknown_hosts_file]
ssh-keygen -Rhostname [-fknown_hosts_file]
ssh-keygen -Ureader [-finput_keyfile]
ssh-keygen -rhostname [-finput_keyfile] [-g]
ssh-keygen -Goutput_file [-v] [-bbits] [-Mmemory] [-Sstart_point]
ssh-keygen -Toutput_file-finput_file [-v] [-anum_trials] [-Wgenerator]
ssh-keygen [-n] [-Dsmartcard]
Description
ssh-keygen generates, manages and converts authentication keys for ssh(1). ssh-keygen can create RSA keys for use by SSH protocol version 1and RSA or DSA keys for use by SSH protocol version 2. The type of key to be generated is specified with the -t option. If invoked without anyarguments, ssh-keygen will generate an RSA key for use in SSH protocol 2 connections.
ssh-keygen is also used to generate groups for use in Diffie-Hellman group exchange (DH-GEX). See the MODULI GENERATION section for details.
Normally each user wishing to use SSH with RSA or DSA authentication runs this once to create the authentication key in ~/.ssh/identity,~/.ssh/id_dsa or ~/.ssh/id_rsa. Additionally, the system administrator may use this to generate host keys, as seen in /etc/rc.
Normally this program generates the key and asks for a file in which to store the private key. The public key is stored in a file with the same name but'.pub' appended. The program also asks for a passphrase. The passphrase may be empty to indicate no passphrase (host keys must have an empty passphrase), orit may be a string of arbitrary length. A passphrase is similar to a password, except it can be a phrase with a series of words, punctuation, numbers,whitespace, or any string of characters you want. Good passphrases are 10-30 characters long, are not simple sentences or otherwise easily guessable (Englishprose has only 1-2 bits of entropy per character, and provides very bad passphrases), and contain a mix of upper and lowercase letters, numbers, andnon-alphanumeric characters. The passphrase can be changed later by using the -p option.
There is no way to recover a lost passphrase. If the passphrase is lost or forgotten, a new key must be generated and copied to the corresponding public keyto other machines.
For RSA1 keys, there is also a comment field in the key file that is only for convenience to the user to help identify the key. The comment can tell whatthe key is for, or whatever is useful. The comment is initialized to 'user@host' when the key is created, but can be changed using the -c option.
After a key is generated, instructions below detail where the keys should be placed to be activated.
The options are as follows:
Specifies the number of primality tests to perform when screening DH-GEX candidates using the -T command.-B' Show the bubblebabble digest of specified private or public key file.
-bbits
Specifies the number of bits in the key to create. For RSA keys, the minimum size is 768 bits and the default is 2048 bits. Generally, 2048 bits is consideredsufficient. DSA keys must be exactly 1024 bits as specified by FIPS 186-2.
Specifies the number of bits in the key to create. For RSA keys, the minimum size is 768 bits and the default is 2048 bits. Generally, 2048 bits is consideredsufficient. DSA keys must be exactly 1024 bits as specified by FIPS 186-2.
-Ccomment
Provides a new comment.
Provides a new comment.
-c' Requests changing the comment in the private and public key files. This operation is only supported for RSA1 keys. The program will prompt forthe file containing the private keys, for the passphrase if the key has one, and for the new comment.
-Dreader
Download the RSA public key stored in the smartcard in reader.
Download the RSA public key stored in the smartcard in reader.
-e' This option will read a private or public OpenSSH key file and print the key in RFC 4716 SSH Public Key File Format to stdout. This option allowsexporting keys for use by several commercial SSH implementations.
-Fhostname
Search for the specified hostname in a known_hosts file, listing any occurrences found. This option is useful to find hashed host names oraddresses and may also be used in conjunction with the -H option to print found keys in a hashed format.
Search for the specified hostname in a known_hosts file, listing any occurrences found. This option is useful to find hashed host names oraddresses and may also be used in conjunction with the -H option to print found keys in a hashed format.
-ffilename
Specifies the filename of the key file.
Specifies the filename of the key file.
-Goutput_file
Generate candidate primes for DH-GEX. These primes must be screened for safety (using the -T option) before use.
Generate candidate primes for DH-GEX. These primes must be screened for safety (using the -T option) before use.
-g' Use generic DNS format when printing fingerprint resource records using the -r command.
-H' Hash a known_hosts Adobe 1.5. file. This replaces all hostnames and addresses with hashed representations within the specified file; the originalcontent is moved to a file with a .old suffix. These hashes may be used normally by ssh and sshd, but they do not reveal identifying informationshould the file's contents be disclosed. This option will not modify existing hashed hostnames and is therefore safe to use on files that mix hashed andnon-hashed names.
-i' This option will read an unencrypted private (or public) key file in SSH2-compatible format and print an OpenSSH compatible private (or public)key to stdout. ssh-keygen also reads the RFC 4716 SSH Public Key File Format. This option allows importing keys from several commercial SSHimplementations.
-l' Show fingerprint of specified public key file. Private RSA1 keys are also supported. For RSA and DSA keys ssh-keygen tries to find thematching public key file and prints its fingerprint. If combined with -v, an ASCII art representation of the key is supplied with the fingerprint.
-Mmemory
Specify the amount of memory to use (in megabytes) when generating candidate moduli for DH-GEX.
Specify the amount of memory to use (in megabytes) when generating candidate moduli for DH-GEX.
-n' Extract the public key from smartcard.
-Nnew_passphrase
Provides the new passphrase.
Provides the new passphrase.
-Ppassphrase
Provides the (old) passphrase.
Provides the (old) passphrase.
-p' Requests changing the passphrase of a private key file instead of creating a new private key. The program will prompt for the file containing theprivate key, for the old passphrase, and twice for the new passphrase.
-q' Silence ssh-keygen. Used by /etc/rc when creating a new key.
-Rhostname
Removes all keys belonging to hostname from a known_hosts file. This option is useful to delete hashed hosts (see the -H option above).
Removes all keys belonging to hostname from a known_hosts file. This option is useful to delete hashed hosts (see the -H option above).
-rhostname
Print the SSHFP fingerprint resource record named hostname for the specified public key file.
Print the SSHFP fingerprint resource record named hostname for the specified public key file.
-Sstart
Specify start point (in hex) when generating candidate moduli for DH-GEX.
Specify start point (in hex) when generating candidate moduli for DH-GEX.
-Toutput_file
Test DH group exchange candidate primes (generated using the -G option) for safety.
Test DH group exchange candidate primes (generated using the -G option) for safety.
-ttype
Specifies the type of key to create. The possible values are 'rsa1' for protocol version 1 and 'rsa' or 'dsa' for protocol version 2.
Specifies the type of key to create. The possible values are 'rsa1' for protocol version 1 and 'rsa' or 'dsa' for protocol version 2.
-Ureader
Upload an existing RSA private key into the smartcard in reader.
Upload an existing RSA private key into the smartcard in reader.
-v' Verbose mode. Causes ssh-keygen to print debugging messages about its progress. This is helpful for debugging moduli generation. Multiple-v options increase the verbosity. The maximum is 3.
-Wgenerator
Specify desired generator when testing candidate moduli for DH-GEX.
Specify desired generator when testing candidate moduli for DH-GEX.
-y' This option will read a private OpenSSH format file and print an OpenSSH public key to stdout.
Moduli Generation
ssh-keygen may be used to generate groups for the Diffie-Hellman Group Exchange (DH-GEX) protocol. Generating these groups is a two-step process:first, candidate primes are generated using a fast, but memory intensive process. These candidate primes are then tested for suitability (a CPU-intensiveprocess).
Generation of primes is performed using the -G option. The desired length of the primes may be specified by the -b option. Forexample:
- # ssh-keygen -T moduli-2048 -f moduli-2048.candidates
By default, each candidate will be subjected to 100 primality tests. This may be overridden using the -a option. The DH generator value will bechosen automatically for the prime under consideration. If a specific generator is desired, it may be requested using the -W option. Valid generatorvalues are 2, 3, and 5.
Screened DH groups may be installed in /etc/ssh/moduli. It is important that this file contains moduli of a range of bit lengths and that both endsof a connection share common moduli.
Files
Contains the protocol version 1 RSA authentication identity of the user. This file should not be readable by anyone but the user. It is possible to specifya passphrase when generating the key; that passphrase will be used to encrypt the private part of this file using 3DES. This file is not automatically accessedby ssh-keygen but it is offered as the default file for the private key. ssh(1) will read this file when a login attempt is made.~/.ssh/identity.pub
Contains the protocol version 1 RSA public key for authentication. The contents of this file should be added to ~/.ssh/authorized_keys on all machineswhere the user wishes to log in using RSA authentication. There is no need to keep the contents of this file secret.
Contains the protocol version 1 RSA public key for authentication. The contents of this file should be added to ~/.ssh/authorized_keys on all machineswhere the user wishes to log in using RSA authentication. There is no need to keep the contents of this file secret.
~/.ssh/id_dsa
Contains the protocol version 2 DSA authentication identity of the user. This file should not be readable by anyone but the user. It is possible to specify apassphrase when generating the key; that passphrase will be used to encrypt the private part of this file using 3DES. This file is not automatically accessedby ssh-keygen but it is offered as the default file for the private key. ssh(1) will read this file when a login attempt is made.
Contains the protocol version 2 DSA authentication identity of the user. This file should not be readable by anyone but the user. It is possible to specify apassphrase when generating the key; that passphrase will be used to encrypt the private part of this file using 3DES. This file is not automatically accessedby ssh-keygen but it is offered as the default file for the private key. ssh(1) will read this file when a login attempt is made.
~/.ssh/id_dsa.pub
Contains the protocol version 2 DSA public key for authentication. The contents of this file should be added to ~/.ssh/authorized_keys on all machineswhere the user wishes to log in using public key authentication. There is no need to keep the contents of this file secret.
Contains the protocol version 2 DSA public key for authentication. The contents of this file should be added to ~/.ssh/authorized_keys on all machineswhere the user wishes to log in using public key authentication. There is no need to keep the contents of this file secret.
~/.ssh/id_rsa
Contains the protocol version 2 RSA authentication identity of the user. This file should not be readable by anyone but the user. It is possible to specify apassphrase when generating the key; that passphrase will be used to encrypt the private part of this file using 3DES. This file is not automatically accessedby ssh-keygen but it is offered as the default file for the private key. ssh(1) will read this file when a login attempt is made.
Contains the protocol version 2 RSA authentication identity of the user. This file should not be readable by anyone but the user. It is possible to specify apassphrase when generating the key; that passphrase will be used to encrypt the private part of this file using 3DES. This file is not automatically accessedby ssh-keygen but it is offered as the default file for the private key. ssh(1) will read this file when a login attempt is made.
~/.ssh/id_rsa.pub
Contains the protocol version 2 RSA public key for authentication. The contents of this file should be added to ~/.ssh/authorized_keys on all machineswhere the user wishes to log in using public key authentication. There is no need to keep the contents of this file secret.
Contains the protocol version 2 RSA public key for authentication. The contents of this file should be added to ~/.ssh/authorized_keys on all machineswhere the user wishes to log in using public key authentication. There is no need to keep the contents of this file secret.
/etc/ssh/moduli
Contains Diffie-Hellman groups used for DH-GEX. The file format is described in moduli(5).
Contains Diffie-Hellman groups used for DH-GEX. The file format is described in moduli(5).
Environment
The reseeding of the OpenSSL random generator is usually done from /dev/urandom. If the SSH_USE_STRONG_RNG environment variable is set tovalue other than![Ssh Ssh](/uploads/1/1/0/3/110314021/201870869.jpg)
See Also
ssh(1), ssh-add(1), ssh-agent(1), moduli(5), sshd(8)
Authors
OpenSSH is a derivative of the original and free ssh 1.2.12 release by Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt andDug Song removed many bugs, re-added newer features and created OpenSSH. Markus Friedl contributed the support for SSH protocol versions 1.5 and 2.0.
BSD April 14, 2013 BSD
Referenced By
amaddclient(8),autossh(1),backup-manager(8),gsimoduli(5),gsissh(1),gsissh-keysign(8),gsissh_config(5),gsisshd(8),rsnapshot(1),scp(1),sftp(1),ssh-keysign(8),ssh_config(5),tlsa(1) These docs are for Rancher 1.6, if you are looking for Rancher 2.x docs, see here.
Getting Started with Hosts
Hosts are the most basic unit of resource within Rancher and is represented as any Linux server, virtual or physical, with the following minimum requirements:
- x86 CPU architecture
- Any modern Linux distribution with a supported version of Docker. RancherOS, Ubuntu, RHEL/CentOS 7 are more heavily tested.
- For RHEL/CentOS, the default storage driver, i.e. devicemapper using loopback, is not recommended by Docker. Please refer to the Docker documentation on how to change it.
- For RHEL/CentOS, if you want to enable SELinux, you will need to install an additional SELinux module.
- For RHEL/CentOS, please use kernel version
3.10.0-514.2.2.el7.x86_64
or higher. Includes when using release 7.3 or higher. - For host running a local caching nameserver (e.g. Ubuntu 18.04 Bionic Beaver), see Hosts running a local caching nameserver
- 1GB RAM
- Recommended CPU w/ AES-NI
- Ability to communicate with a Rancher server via http or https through the pre-configured port. Default is 8080.
- Ability to be routed to any other hosts under the same environment to leverage Rancher’s cross-host networking for Docker containers.
Rancher also supports Docker Machine and allows you to add your host via any of its supported drivers.
From the Infrastructure -> Hosts tab, click on Add Host.
Supported Docker Versions
Version | Supported? | Kubernetes Supported? | Windows Supported? | Install Script |
---|---|---|---|---|
1.9.x and lower | No | |||
1.10.0 - 1.10.2 | No | |||
1.10.3 (and higher) | No (Yes in v1.6.5 and lower) | No | No | curl https://releases.rancher.com/install-docker/1.10.sh | sh |
1.11.x | No | curl https://releases.rancher.com/install-docker/1.11.sh | sh | ||
1.12.0 - 1.12.2 | No | |||
1.12.3 (and higher) | Yes | Yes | No | curl https://releases.rancher.com/install-docker/1.12.sh | sh |
1.13.x | Yes | Yes (Kubernetes version 1.8, 1.9, 1.10, 1.11) | No | curl https://releases.rancher.com/install-docker/1.13.sh | sh |
17.03.x-ce | Yes | Yes (Kubernetes version 1.8, 1.9, 1.10, 1.11) | No | curl https://releases.rancher.com/install-docker/17.03.sh | sh |
17.03.x-ee | Yes | Yes (Kubernetes version 1.8, 1.9, 1.10, 1.11) | No | n/a |
17.04.x-ce | No | No | No | curl https://releases.rancher.com/install-docker/17.04.sh | sh |
17.05.x-ce | No | No | No | curl https://releases.rancher.com/install-docker/17.05.sh | sh |
17.06.x-ce | Yes (v1.6.3 and higher) | No | No | curl https://releases.rancher.com/install-docker/17.06.sh | sh |
17.06.x-ee | Yes (v1.6.3 and higher) | No | Yes (v1.6.13 and higher) | n/a |
17.09.x-ce | Yes (v1.6.11 and higher) | No | No | curl https://releases.rancher.com/install-docker/17.09.sh | sh |
17.09.x-ee | Yes (v1.6.11 and higher) | No | No | n/a |
17.10.x-ce | No | No | curl https://releases.rancher.com/install-docker/17.10.sh | sh | |
17.11.x-ce | No | No | n/a | |
17.12.x-ce | Yes (v1.6.14 and higher) | No | No | curl https://releases.rancher.com/install-docker/17.12.sh | sh |
17.12.x-ee | Yes (v1.6.14 and higher) | No | No | n/a |
18.01.x-ce | No | No | n/a | |
18.02.x-ce | No | No | n/a | |
18.03.x-ce | Yes (v1.6.17 and higher) | No | No | curl https://releases.rancher.com/install-docker/18.03.sh | sh |
18.03.x-ee | Yes (v1.6.17 and higher) | No | No | n/a |
18.06.x-ce | Yes (v1.6.20 and higher) | Yes (Kubernetes version 1.12) | No | curl https://releases.rancher.com/install-docker/18.06.sh | sh |
18.06.x-ee | Yes (v1.6.20 and higher) | Yes (Kubernetes version 1.12) | No | n/a |
18.09.x-ce | Yes (v1.6.26 and higher) | Yes (Kubernetes version 1.12) | No | curl https://releases.rancher.com/install-docker/18.09.sh | sh |
18.09.x-ee | Yes (v1.6.26 and higher) | Yes (Kubernetes version 1.12) | No | n/a |
Note: Oversight. We will not support the test/nightly/edge releases of Docker, but will support the stable releases of Docker.
Installing a Specific Docker Version
The standard
curl https://get.docker.com | sh
always installs the latest Docker release available at that time and may not be supported by your installed Rancher version. Instead, we recommend you use the scripts above to install a specific version. These are a slightly modified version of the standard script and pin the installation to a specific Docker engine version. Exact patch releases are also available as 1.<x>.<y>.sh
, e.g. 1.12.6.sh
.Note: If you are launching a host from the UI, you can select which version of Docker you’d like to install on the host. In the Advanced Options section, there is a Docker Install URL.
How do Hosts work?
A host gets connected to Rancher server when the Rancher agent container is started on the host. The registration token, which is the long URL in the Add Host -> Custom screen, is used by the Rancher agent to connect to the server for the first time. Upon connection, it generates an agent account and API key pair in Rancher server. The key pair is then used for all subsequent communication using the same authentication and authorization logic as there is for other kinds of accounts, like environment API keys.
The design is that the agent is untrusted because it is running on the outside and potentially hostile (to the server) hardware. The agent accounts have access to only the resources they need in the API, replies to events are checked that the event was actually sent to that agent, etc. There is not as much in the opposite direction for the agent to verify the host, so you can also set up TLS and the certificate will be verified.
The registration token is per environment. It is generated on the server, stored in the database, and sent to the host as part of the agent registration with the API key pair. The connections are point to point between hosts and AES encrypted, which is accelerated by most modern CPUs.
Adding a Host
The first time that you add a host, you may be required to set up the Host Registration URL. This setup determines what DNS name or IP address, and port that your hosts will be connected to the Rancher API. By default, we have selected the management server IP and port
8080
. If you choose to change the address, please make sure to specify the port that should be used to connect to the Rancher API. At any time, you can update the Host Registration. After setting up your host registration, click on Save.We support adding hosts directly from cloud providers or adding a host that’s already been provisioned. For cloud providers, we provision using
docker-machine
and support any images that docker-machine
supports.Select which host type you want to add:
When a host is added to Rancher, a rancher agent container is launched on the host. Rancher will automatically pull the correct image version tag for the
rancher/agent
and run the required version. The agent version is tagged specifically to each Rancher server version.Host Labels
With each host, you have the ability to add labels to help you organize your hosts. The labels are added as an environment variable when launching the rancher/agent container. The host label in the UI will be a key/value pair and the keys must be unique identifiers. If you added two keys with different values, we’ll take the last inputted value to use as the key/value pair.
By adding labels to hosts, you can use these labels when schedule services/load balancers and create a whitelist or blacklist of hosts for your services to run on.
If you are planning to use an external DNS service and will require to program the DNS records using an IP other than the host IP, then you will need to include the label
io.rancher.host.external_dns_ip=<IP_TO_BE_USED_FOR_EXTERNAL_DNS>
on the host. The host label can be added when registering the host or after the host has been added to Rancher, but it should be added to the host before the external DNS service starts. The value of this label will be used when programming rules for external DNS services.When using the UI to add hosts with the different cloud providers, the rancher/agent command is automatically launched for you with the host labels that are added in the UI.
When adding a custom host, you can add the labels using the UI and it will automatically add the environment variable (
CATTLE_HOST_LABELS
) with the key/value pair into the command on the UI screen.Example
Note: The
rancher/agent
version is correlated to the Rancher server version. You will need to check the custom command to get the appropriate tag for the version to use.Automatically Applied Host Labels
Rancher automatically creates host labels related to linux kernel version and Docker Engine version of the host.
Key | Value | Description |
---|---|---|
io.rancher.host.linux_kernel_version | Linux Kernel Version on Host (e.g, 3.19 ) | Version of the Linux kernel running on the host |
io.rancher.host.docker_version | Docker Version on the host (e.g. 1.10 ) | Docker Engine Version on the host |
io.rancher.host.provider | Cloud provider info | Cloud provider name (currently only applied for AWS) |
io.rancher.host.region | Cloud provider region | Cloud provider region (currently only applied for AWS) |
io.rancher.host.zone | Cloud provider zone | Cloud provider zone (currently only applied for AWS) |
Scheduler IPs
In order to enable the ability to publish ports on multiple IPs, the host needs to be configured so that Rancher is aware of which IPs are available to be scheduled against. The method to add scheduler IPs for a host depends on whether the host is already in Rancher (i.e. Rancher agent has already been launched) versus a new host (i.e. Rancher agent has yet to be launched).
Adding Scheduler IPs to Existing Hosts
For any existing hosts in an environment, additional IPs can be added for scheduling by adding a specific host label (
io.rancher.scheduler.ips
to the host. In the UI, click on Edit Host for the host, and add a Scheduler IP. If you want to update the host details through the API, you would add the host label io.rancher.scheduler.ips
and list the IPs as the value in a comma separated list (i.e. 1.2.3.4, 2.3.4.5
).Note: If any ports are published for services on a host before adding the scheduler IPs, those ports are published on
0.0.0.0
, which means they are consumed on all IPs, including the schedulers IPs added after the service has been launched.Adding Scheduler IPs for a new Host
Cisco Show Ssh Version
For any custom hosts that have not been added to Rancher, an environment variable (i.e.
CATTLE_SCHEDULER_IPS
) can be added to the Rancher agent command to list the available IPs on the host.Hosts behind an HTTP Proxy
If you are behind an HTTP proxy, in order to add hosts to Rancher server, you will need to edit the Docker daemon of the host to point to the proxy. Capture one db. The detailed instructions are listed within our adding custom host page.
Hosts running a local caching nameserver
Some Linux distributions run a local caching nameserver by default. This means that the configured nameserver in
/etc/resolv.conf
is pointing to address in loopback range (127.0.0.0/8
). While this will function fine on the host itself, containers are not able to reach this address (unless run with network mode host
). Our infrastructure services need to be able to resolve DNS to function, so a change to the system is required before adding the host to a Rancher environment. This involves two steps:- Disabling the local caching nameserver.
- Modifying the contents of
/etc/resolv.conf
to point to correct nameservers.
For Ubuntu 18.04, you can run the following commands to modify the system:
If
/run/systemd/resolve/resolv.conf
is not present on the system, you can create your own /etc/resolv.conf
as shown below:Accessing hosts from the Cloud Providers
If you choose to select to launch a host through Rancher, Rancher is making a Docker Machine call to lauch in the cloud provider. We provide all the certificates generated when launching the machine in an easy to download file. Click on Machine Config in the host’s dropdown menu. It will download a tar.gz file that has all the certificates.
To SSH into your host, go to your terminal/command prompt. Navigate to the folder of all the certificates and ssh in using the
id_rsa
certificate.Cloning a Host
Since launching hosts on cloud providers requires using an access key, you might want to easily create another host without needing to input all the credentials again. Rancher provides the ability to clone these credentials to spin up a new host. Select Clone from the host’s drop down menu. It will bring up an Add Host page with the credentials of the cloned host populated.
Ssh V1 Vs V2
Editing Hosts
The options for what can be done to a host are located in the host’s dropdown. From the Infrastructure -> Hosts page, the dropdown icon will appear when you hover over the host. If you click on the host name to view more details of a host, the dropdown icon is located in the upper right corner of the page. It’s located next to the State of the host.
If you select Edit, you can update the name, description or labels on the host.
Deactivating/Activating Hosts
Ssh V1 Vulnerability
Deactivating the host will put the host into an Inactive state. In this state, no new containers can be deployed. Any active containers on the host will continue to be active and you will still have the ability to perform actions on these containers (start/stop/restart). The host will still be connected to the Rancher server. Select Deactivate from the host’s dropdown menu.
When a host is in the Inactive state, you can bring the host back into an Active state by clicking on Activate from the host’s dropdown menu.
Note: If a host is down in Rancher (i.e. in
reconnecting
or inactive
state), you will need to implement a health check in order for Rancher to launch the containers on your service on to a different host.Removing Hosts
In order to remove a host from the server, you will need to do a couple of steps from the dropdown menu.
Select Deactivate. When the host has completed the deactivation, the host will display an Inactive state. Select Delete. The server will start the removal process of the host from the Rancher server instance. The first state that it will display after it’s finished deleting it will be Removed. It will continue to finalize the removal process and move to a Purged state before immediately disappearing from the UI.
If the host was created on a cloud provider using Rancher, the host will be deleted from the cloud provider. If the host was added by using the custom command, the host will remain on the cloud provider.
Notes: For custom hosts, all containers including the Rancher agent will continue to remain on the host. Also, the IP set on the
docker0
interface by the Rancher network driver will remain.Deleting Hosts outside of Rancher
Ssh V1 Putty
If your host is deleted outside of Rancher, then Rancher server will continue to show the host until it’s removed. After retrying the connection (Reconnecting), the host will show up in a Disconnected state. You will be able to Delete the host to remove them from the UI. You can also configure a delay in seconds, after which the host will automatically be removed. This setting is called
host.remove.delay.seconds
and can be found under Admin
-> Settings
-> Advanced Settings
.