Windows ssh config identityfile

Secure Shell (SSH) is a protocol used to securely connect to remote servers and devices over an unsecured network. An often overlooked but incredibly useful feature of SSH is the SSH configuration file, which streamlines the process of connecting to multiple servers by allowing you to define custom connection parameters. In this article, we will delve into how to effectively manage an SSH config file on both Windows and Linux, including its creation, structure, common options, and best practices.

Understanding SSH and the Config File

SSH is primarily used for remote access to servers. The SSH client on your local machine communicates with an SSH server on a remote machine, enabling secure communication. The SSH config file allows users to create shortcuts for connections. Instead of typing the full command every time, users can reference hosts using aliases defined in the config file.

Location of SSH Config File

For Linux and macOS, the SSH configuration file is typically located at:

~/.ssh/config

In contrast, Windows now provides a similar structure through various methods, including the Windows Subsystem for Linux (WSL) or third-party applications such as Git Bash or PuTTY.

1. Using WSL or Linux Tools on Windows: If using WSL or Git Bash, the configuration file will also be located at:

~/.ssh/config

1. Using PuTTY: PuTTY does not use an SSH config file like OpenSSH. Instead, it utilizes its own saved session profiles.

Creating the SSH Config File

For Linux and macOS

1. Open the Terminal: You can do this by searching for “Terminal” in your applications.

2. Create the .ssh Directory if it Doesn’t Exist:

   mkdir -p ~/.ssh

3. Create or Edit the Config File:

   nano ~/.ssh/config

4. Set Permissions: Ensure that the .ssh directory and config file have the right permissions:

   chmod 700 ~/.ssh
   chmod 600 ~/.ssh/config

For Windows Using WSL or Git Bash

• Follow the same steps as above, as WSL and Git Bash mimic the Linux environment.

Using PuTTY on Windows

1. Open PuTTY: Launch the application.

2. Create a New Session: Input the hostname and port number.

3. Save the Session: Before connecting, make sure to save the session with a recognizable name.

Basic Structure of the SSH Config File

The SSH config file consists of multiple sections where each section specifies a host and its related settings. Below is the basic syntax:

Host 
    HostName 
    User 
    Port 
    IdentityFile 

Example SSH Config File Entry

Host myserver
    HostName example.com
    User myusername
    Port 2222
    IdentityFile ~/.ssh/id_rsa

In this example, you can use the command ssh myserver instead of typing the full SSH command with all parameters.

Common SSH Config Options

Host

This is the alias for your connection. This can be anything you choose but is often a simple name that makes it easy to remember.

HostName

This is the actual domain name or IP address of the server you’re connecting to.

User

This specifies the username you wish to log in as on the remote system.

Port

By default, SSH operates on port 22, but if your server uses a different port for SSH connections, specify it here.

IdentityFile

If you’re using key-based authentication, use this option to point to your private key file.

Other Useful Options

• ForwardAgent: Allows SSH agent forwarding, which can be useful for using your local SSH key on a remote server.

  ForwardAgent yes

• ProxyCommand: This specifies a command to be executed to connect to the server, useful when dealing with jump servers.

  ProxyCommand ssh -q -W %h:%p [email protected]

• ServerAliveInterval: This option sets a timeout interval to send keepalive messages to the server, useful for preventing idle disconnections.

  ServerAliveInterval 60

Managing Multiple SSH Configurations

When managing multiple servers, keeping your SSH config organized is essential. Below are some strategies for better management.

Grouping Hosts

You can group similar hosts under a single block to avoid redundancy. For example, if you have multiple servers in the same project:

Host project1-server1
    HostName project1-server1.example.com
    User deploy
    IdentityFile ~/.ssh/project1_id_rsa

Host project1-server2
    HostName project1-server2.example.com
    User deploy
    IdentityFile ~/.ssh/project1_id_rsa

Using Wildcards

If you’re connecting to multiple hosts that share the same configuration, you can use wildcards:

Host droplet-*
    User root
    IdentityFile ~/.ssh/digitalocean_id_rsa

Comments for Clarity

Adding comments can aid in quick references when dealing with a large number of hosts.

# Web servers
Host webserver1
    HostName web1.example.com
    User deploy

Host webserver2
    HostName web2.example.com
    User deploy

Including Additional Configurations

If you have a large number of connections and configurations, consider breaking them into multiple files using the Include directive (supported in OpenSSH 7.3 and later):

Include ~/.ssh/config.d/*

You can then put configuration snippets in separate files under ~/.ssh/config.d/.

Testing Your Configuration

After setting up your ~/.ssh/config, you can test your connections to ensure everything works as intended. Use the following command:

ssh -G 

This command shows the effective options for the given alias. If you encounter any issues, the output will help identify what might be wrong, including missing keys or misconfigured options.

Common Errors and Troubleshooting

Even after correctly setting up the SSH config file, you might encounter some issues. Here are a few common problems and their solutions:

Permission Denied (Publickey)

This error often occurs when the SSH server cannot find the correct key for authentication. Ensure that:

1. The private key specified in the configuration exists and has the right permissions (chmod 600).

2. The public key is added to the ~/.ssh/authorized_keys file on the server.

Host Key Verification Failed

If you see this error, it means the host key stored in your known_hosts file does not match the server’s current host key. This may indicate a man-in-the-middle attack or simply that the server’s key has changed.

• To resolve, you can remove the old key from your ~/.ssh/known_hosts file using the following command:

ssh-keygen -R 

Then attempt to reconnect, and you’ll be prompted to add the new key.

Connection Timed Out

This indicates that your SSH request is not reaching the server. Ensure that:

1. The server is running and accessible over the network.
2. You are connecting to the right IP address.

Security Best Practices

When managing SSH config files, keep security in mind to minimize risks.

Use Key-Based Authentication

Using SSH keys instead of passwords can significantly enhance your security posture. Generate a new key pair:

ssh-keygen -t rsa -b 4096 -C "[email protected]"

Don’t forget to add your public key to the server’s ~/.ssh/authorized_keys file.

Disable Root Login

To reduce the risk of unauthorized access, disable root login in your SSH configuration on the server:

PermitRootLogin no

Use Strong Passwords

If you must use passwords (for instance, two-factor authentication), ensure they are strong and unique.

Keep Software Updated

Regular updates to your SSH client and server software are crucial for protecting against vulnerabilities. Check for software updates regularly.

Managing SSH Configurations in Windows with PuTTY

While PuTTY doesn’t use a config file per se, it allows for saving profiles that function similarly. Here’s how you can manage SSH connections in PuTTY.

Saving Sessions

1. Open PuTTY.
2. In the Session category, enter the hostname or IP address in the «Host Name» field.
3. Choose a port, typically 22 for SSH.
4. Under «Connection» -> «SSH», you can configure options like the username and authentication method.
5. Return to the Session category, type a name for your session, and click «Save.»

Loading Sessions

To connect later, simply open PuTTY, select the session name, and click «Load,» followed by «Open.»

Exporting and Backing Up Profiles

There’s no built-in feature for exporting configurations like an SSH config file, but you can manually back up the settings by exporting the Windows registry keys PuTTY uses.

1. Open the Command Prompt and run:

   reg export HKCUSoftwareSimonTathamPuTTY C:pathtoyourbackup_file.reg

Managing Keys in PuTTY with Pageant

Pageant is an SSH authentication agent for PuTTY, allowing you to manage your private keys securely. It keeps keys loaded and can save you from entering passphrases repeatedly.

1. Start Pageant from the programs list.
2. Right-click the Pageant icon in the system tray.
3. Click “Add Key” and select your private key (e.g., id_rsa).

Using Third-Party Tools

You can also consider third-party tools that offer easier SSH management, such as:

• MobaXterm: A feature-rich SSH client that includes a built-in X server, file transfer capabilities, and the ability to save SSH configurations.

• WinSCP: Primarily a file transfer tool but provides SSH access and can be used to manage configurations efficiently.

Conclusion

Managing SSH config files is an essential skill for system administrators, developers, and anyone who frequently interacts with remote systems. Both Windows and Linux provide robust mechanisms for configuring SSH connections, enhancing usability and productivity.

By following best practices, organizing configurations efficiently, and ensuring robust security policies, you can streamline your workflow while maintaining a secure environment.

With this comprehensive guide, you should now have a solid understanding of how to create, manage, and troubleshoot SSH config files on both Windows and Linux systems. Embrace these practices, and you’ll find managing remote connections much easier and far more secure.

bsara / git-ssh-auth-win-setup.md

Setup SSH Authentication for Git Bash on Windows

1. Create a folder at the root of your user home folder (Example: C:/Users/uname/ ) called .ssh .
2. Create the following files if they do not already exist (paths begin from the root of your user home folder):
   • .ssh/config
   • .bash_profile
   • .bashrc

Create a New SSH Key

Follow the steps in the section named «Generating a new SSH Key» found in the following documentation from GitHub: Generating a new SSH key and adding it to the ssh-agent

Configure SSH for Git Hosting Server

Add the following text to .ssh/config ( .ssh should be found in the root of your user home folder):

Enable SSH Agent Startup Whenever Git Bash is Started

First, ensure that following lines are added to .bash_profile , which should be found in your root user home folder:

Now, add the following text to .bashrc , which should be found in your root user home folder:

pensebien commented Nov 28, 2017 •

Thank you for the gist. But I found it easy to just add to my

./profile file
localUser@mycomputer MINGw64 / notepad /.profile
then I Paste this

I also took time to read about ssh-agent

rianquinn commented Feb 27, 2018

This worked perfectly, Thanks

leoreeves commented Mar 6, 2018 •

@emmaakin, thanks that works great. FYI, there’s a backtick at the start and end your code snippet that will cause an error.

pauljohn32 commented Mar 18, 2018

The part that launches the ssh agent is valuable. However, I’m not persuaded there is a benefit in the git config file. The Default key name is «id_rsa» and that is what ssh will look for. I think the config file is not having an effect. At least for me.

In my case, the name of the key is different for every server and, for reasons I cannot understand, the ssh system only wants to look for «id_rsa». On Linux, this is a symptom of a permissions problem, permissions should be 700. But in Windows, it appears not possible to set permissions at all. In the Git bash shell, permissions always have g+r and o+r.

The config file is ignores, at least for me. You can see same result if you name your key in another file, put in

And it wont work. If it does work, I’d love to hear from you.

smutel commented Mar 22, 2018

If you use an old dsa key, put this in config PubkeyAcceptedKeyTypes=+ssh-dss

gregbown commented May 14, 2018

Wow! First of all, thank you! I am astonished as to why none of this presented anywhere on GitHub? I spent a couple of hours looking for the missing steps, All they say is paste your public key here with no mention of how GitHub is supposed to find the private key on Windows, where it should be stored, what else is required, etc.

The only thing I would add to this is that if you are generating you keys with PuTTY Key Generator, you must select from the menu -> Conversions -> Export SSH key(force new file format) and save the private key as just «id_rsa» NOT id_rsa.ppk the default PuTTY format

Thank you again Brandon

demiters commented Aug 27, 2018

fushenghua commented Sep 4, 2018

bonovski commented Sep 13, 2018

Thank you, works perfectly!
bitbucket and github are really missing these crucial steps, lost almost 8 hours setting it up on windows.

surjikal commented Sep 15, 2018

I added this to /etc/ssh/ssh_config so that I could use a shared deployment key for all users on my server. Thanks for the info!

Tri125 commented Jan 2, 2019

If you want to add multiple keys to the agent simply replace the line ssh-add

/.ssh/id_rsa; with the following block:

This will add every ssh key that start with id_
The inconvenience is that when the ssh-agent start, it’s going to prompt you to enter the password for every keys even if you don’t necessarily use them. I haven’t found a solution for this.

You might want to use that with git for windows if, say, you have a different github account: 1 for your personal work and another for your professional work. Github won’t let you re-use the same ssh key for both accounts so you need 2 keys.

To make this work, you will need to do 2 more steps. in $/.ssh create the config file with the following content:

In this example, we have the secondary ssh key named id_rsa_corpo .

If you already cloned the repo for the secondary key, change the remote to point to github-corpo .
If not, then just clone by replacing the host :

Источник

Файл конфигурации SSH

Using the SSH Config File

Это руководство охватывает основы файла конфигурации клиента SSH и объясняет некоторые из наиболее распространенных параметров конфигурации.

Если вы регулярно подключаетесь к нескольким удаленным системам через SSH, вы обнаружите, что запомнить все удаленные IP-адреса, разные имена пользователей, нестандартные порты и различные параметры командной строки сложно, если не невозможно.

Один из вариантов — создать псевдоним bash для каждого подключения к удаленному серверу. Однако есть другое, гораздо лучшее и более простое решение этой проблемы. OpenSSH позволяет вам настроить файл конфигурации для каждого пользователя, где вы можете хранить различные параметры SSH для каждого удаленного компьютера, к которому вы подключаетесь.

Мы предполагаем, что вы используете систему Linux или macOS с установленным клиентом OpenSSH.

Расположение файла конфигурации SSH

Файл конфигурации OpenSSH на стороне клиента имеет имя config и хранится в .ssh каталоге в домашнем каталоге пользователя.

/.ssh каталог создается автоматически, когда пользователь запускает ssh команду в первый раз. Если каталог не существует в вашей системе, создайте его с помощью команды ниже:

По умолчанию файл конфигурации SSH может не существовать, поэтому вам может потребоваться создать его с помощью сенсорной команды :

Этот файл должен быть доступен для чтения и записи только пользователю и недоступен для других:

Структура и шаблоны файлов SSH Config

Файл конфигурации SSH имеет следующую структуру:

Содержимое файла конфигурации клиента SSH организовано в разделы (разделы). Каждый раздел начинается с Host директивы и содержит конкретные параметры SSH, которые используются при установлении соединения с удаленным сервером SSH.

Отступы не требуются, но рекомендуется, поскольку они облегчают чтение файла.

Host Директива может содержать один шаблон или разделенных пробелами список шаблонов. Каждый шаблон может содержать ноль или более непробельных символов или один из следующих спецификаторов шаблона:

• * — Соответствует нулю или более символов. Например, Host * сопоставляет все узлы, а 192.168.0.* сопоставляет узлы в 192.168.0.0/24 подсети.
• ? — соответствует ровно одному персонажу. Шаблон, Host 10.10.0.? соответствует всем хостам в 10.10.0.[0-9] диапазоне.
• ! — При использовании в начале паттерна он отменяет совпадение. Например, Host 10.10.0.* !10.10.0.5 соответствует любому хосту в 10.10.0.0/24 подсети, кроме 10.10.0.5 .

Клиент SSH считывает раздел файла конфигурации по разделу, и, если совпадают несколько шаблонов, параметры из первого соответствующего раздела имеют приоритет. Поэтому в начале файла должны быть даны более специфичные для хоста объявления, а в конце файла — более общие переопределения.

Вы можете найти полный список доступных опций ssh, набрав man ssh_config в своем терминале или посетив страницу справки ssh_config .

Файл конфигурации SSH также читается другими программами , такими как scp , sftp и rsync .

Пример файла конфигурации SSH

Теперь, когда мы рассмотрели основы файла конфигурации SSH, давайте рассмотрим следующий пример.

Обычно при подключении к удаленному серверу через SSH вы указываете имя удаленного пользователя, имя хоста и порт. Например, чтобы войти в систему под именем пользователя с именем john хоста, вызываемого через dev.example.com порт 2322 из командной строки, введите:

Чтобы подключиться к серверу, используя те же параметры, что и в приведенной выше команде, просто набрав ssh dev , поместите в «

/.ssh/config файл следующие строки :

Теперь, когда вы ssh dev печатаете, клиент ssh будет читать файл конфигурации и использовать сведения о соединении, которые указаны для dev хоста:

Пример общего файла конфигурации SSH

Этот пример дает более подробную информацию о шаблонах хостов и приоритетах опций.

Давайте возьмем следующий пример файла:

Когда вы ssh targaryen печатаете, клиент ssh читает файл и применяет параметры из первого совпадения, которое есть Host targaryen . Затем он проверяет следующие строфы один за другим на соответствие шаблону. Следующий соответствующий Host * !martell (это означает, что все хосты, кроме martell ), и он будет применять параметр подключения из этого раздела. Последнее определение Host * также совпадает, но клиент ssh выберет только Compression опцию, потому что эта User опция уже определена в разделе Host targaryen .

Полный список параметров, используемых при вводе, ssh targaryen выглядит следующим образом:

При работе ssh tyrell в соответствующие структуры хозяева: Host tyrell , Host *ell , Host * !martell и Host * . Варианты, используемые в этом случае:

Если вы бежите ssh martell , шаблоны соответствия хозяева: Host martell , Host *ell и Host * . Варианты, используемые в этом случае:

Для всех других соединений, клиент SSH будет использовать параметры , указанные в Host * !martell и Host * разделах.

Переопределить опцию файла конфигурации SSH

Клиент ssh считывает свою конфигурацию в следующем порядке приоритета:

1. Параметры, указанные в командной строке.
2. Параметры, определенные в

/.ssh/config .

Если вы хотите переопределить один параметр, вы можете указать его в командной строке. Например, если у вас есть следующее определение:

и вы хотите использовать все остальные параметры, кроме как для подключения в качестве пользователя, root а не john просто указать пользователя в командной строке:

Опция -F ( configfile ) позволяет вам указать альтернативный файл конфигурации для каждого пользователя.

Чтобы указать ssh клиенту игнорировать все параметры, указанные в файле конфигурации ssh, используйте:

Вывод

Мы показали, как настроить пользовательский конфигурационный файл ssh. Вы также можете настроить аутентификацию на основе ключей SSH и подключаться к серверам Linux без ввода пароля.

По умолчанию SSH прослушивает порт 22. Изменение порта SSH по умолчанию добавляет дополнительный уровень безопасности вашему серверу, снижая риск автоматических атак.

Источник

SSH config file for OpenSSH client

The ssh program on a host receives its configuration from either the command line or from configuration files

/.ssh/config and /etc/ssh/ssh_config .

Command-line options take precedence over configuration files. The user-specific configuration file

/.ssh/config is used next. Finally, the global /etc/ssh/ssh_config file is used. The first obtained value for each configuration parameter will be used.

Contents

Commonly used configuration options

There are many configuration options available. In practice, only a few of them are ever changed, and user-specific configuration files are rarely used. In most cases, just /etc/ssh/ssh_config is edited.

Enabling X11 forwarding and agent forwarding

Developers, students, and researchers often want to enable X11 forwarding and SSH agent forwarding. These allow running graphical applications remotely and eliminate the need for typing a password whenever moving from one server to another, respectively. Setting these options in /etc/ssh/ssh_config makes life easier for end users, saves overhead, and reduces support load. However, they increase the risk of an attack spreading from a compromised server to a user’s desktop, so the most security-critical environments may want to leave them disabled. There is generally no reason to enable them on production servers in enterprises.

Port forwarding

Local and remote port forwarding can be used for tunneling applications, accessing intranet web services from home, tunneling database access, and many other purposes. For instructions on configuring port forwarding, see the port forwarding configuration page . Note, however, that port forwarding can also be used to tunnel traffic from the external Internet into a corporate intranet. Employees sometimes do this to be able to work from home even when company policy does not permit it. Hackers use it to leave permanent backdoor. See the page on SSH tunneling for more information.

Configuring public key authentication

Public authentication is used for passwordless logins between systems. It is often used for automated processes, such as backups, configuration management, and file transfers. It is also used by sophisticated end users and system administrators for single sign-on. See the public key authentication for configuring it.

When a user has created more than one SSH key for authentication, the -i command line option may be helpful for specifying which key to use. In the client configuration file, this can be specified using the IdentityFile options.

Certificate-based authentication

OpenSSH certificates can be used for authentication either using ssh-agent or by specifying the CertificateFile option in the client configuration file. See SSH certificates for more information.

Format of SSH client config file ssh_config

The ssh_config client configuration file has the following format. Both the global /etc/ssh/ssh_config and per-user

/ssh/config have the same format.

Empty lines and lines starting with ‘#’ are comments.

Each line begins with a keyword, followed by argument(s).

Configuration options may be separated by whitespace or optional whitespace and exactly one =.

Arguments may be enclosed in double quotes («) in order to specify arguments that contain spaces.

Listing of client configuration options

The following keywords can be used in SSH client configuration files. Keywords are case-insensitive and arguments are case-sensitive. Any algorithm or method names that include an at sign (@) are for experimental use only and not recommended for production.

Restricts the following declarations to be only for those hosts that match one of the patterns given after the keyword. The pattern is matched against the host name given on the command line.

Restricts the following declarations to apply only for hosts that match the specified criteria. For detailed information, see SSH man page .

Specifies which address family to use when connecting. Valid arguments are: any , inet , inet6 .

If set to yes , passphrase/password querying will be disabled. This is useful for running the ssh client from shell script that do not have an interactive user, and prevents accidentally blocking on a password prompt.

Specifies to use the specified address on the local machine as the source address of the connection.

Specifies whether to use challenge-response authentication. This is mostly a legacy method and has been replaced by KbdInteractiveAuthentication .

Directs ssh to additionally check the host IP address in the known_hosts file.

Specifies the cipher to use for encrypting the session in protocol version 1. Note that use of protocol 1 is not recommended.

Specifies the ciphers allowed for protocol version 2 in order of preference. Multiple ciphers must be comma-separated. The ssh -Q cipher command can be used to query supported ciphers. The following list is supported in OpenSSH 6.7:

Specifies that all local, remote, and dynamic port forwardings specified in the configuration files or on the command line be cleared.

Specifies whether to use compression. yes enables compression.

Specifies the compression level to use if compression is enabled.

Specifies the number of attempts to make before exiting.

Specifies the timeout (in seconds) used when connecting to the SSH server, instead of using the default system TCP timeout.

Enables the sharing of multiple sessions over a single network connection.

Specify the path to the control socket used for connection sharing as described in the ControlMaster section above or the string none to disable connection sharing.

Specifies that a TCP port on the local machine be forwarded over the secure channel, and the application protocol is then used to determine where to connect to from the remote machine.

Sets the escape character.

Specifies whether ssh should terminate the connection if it cannot set up all requested dynamic, tunnel, local, and remote port forwardings.

Specifies whether the connection to the authentication agent will be forwarded to the remote machine.

Specifies whether X11 connections will be automatically redirected over the secure channel and DISPLAY set.

If this option is set to yes , remote X11 clients will have full access to the original X11 display.

Specifies whether remote hosts are allowed to connect to local forwarded ports.

Specifies a file to use for the global host key database instead of /etc/ssh/ssh_known_hosts .

Specifies whether user authentication based on GSSAPI is allowed. GSSAPI is typically used for Kerberos authentication, e.g., with Active Directory .

Specifies whether key exchange based on GSSAPI may be used.

If set, specifies the GSSAPI client identity that ssh should use when connecting to the server.

Forward (delegate) credentials to the server.

If set to yes then renewal of the client’s GSSAPI credentials will force the rekeying of the ssh connection.

Set to yes to indicate that the DNS is trusted to securely canonicalize the name of the host being connected to. If no , the hostname entered on the command line will be passed untouched to the GSSAPI library.

Indicates that ssh should hash host names and addresses when they are added to

/.ssh/known_hosts . These hashed names may be used normally by ssh and sshd , but they do not reveal identifying information should the file’s contents be disclosed.

Specifies whether to try rhosts based authentication with public key authentication, using the .rhosts or .shosts files in the user’s home directory and /etc/hosts.equiv and /etc/shosts.equiv in global configuration.

Specifies the protocol version 2 host key algorithms that the client wants to use in order of preference. The following values are supported in OpenSSH 6.7:

ssh-ed25519 ssh-ed25519-cert-v01@openssh.com ssh-rsa ssh-dss ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 ssh-rsa-cert-v01@openssh.com ssh-dss-cert-v01@openssh.com ecdsa-sha2-nistp256-cert-v01@openssh.com ecdsa-sha2-nistp384-cert-v01@openssh.com ecdsa-sha2-nistp521-cert-v01@openssh.com ssh-rsa-cert-v00@openssh.com ssh-dss-cert-v00@openssh.com

Specifies an alias that should be used instead of the real host name when looking up or saving the host key in the host key database files.

Specifies the real host name to log into. This can be used to specify nicknames or abbreviations for hosts. The default is the name given on the command line. Numeric IP addresses are also permitted (both on the command line and in HostName specifications).

Specifies that ssh should only use the identity keys configured in the ssh_config files, even if ssh-agent offers more identities.

Specifies a file from which the user’s identity key is read when using public key authentication . The default for protocol version 1 is

/.ssh/id_dsa for protocol version 2.

Specifies whether to use keyboard-interactive authentication. This is a common method for password authentication, one-time passwords, and multi-factor authentication.

Specifies the list of methods to use in keyboard-interactive authentication.

Specifies a command to execute on the local machine after successfully connecting to the server.

Specifies that a TCP port on the local machine be forwarded over the secure channel to the specified host and port from the remote machine. The first argument must be [bind_address:]port and the second argument must be host:port .

Specifies the verbosity level of logging messages from ssh. The possible values are: QUIET , FATAL , ERROR , INFO , VERBOSE , DEBUG , DEBUG1 , DEBUG2 , and DEBUG3 .

Specifies the MAC (message authentication code) algorithms in order of preference. The ssh -Q mac command can be used to query supported MAC algorithms. The following list is supported in OpenSSH 6.7:

This option can be used if the home directory is shared across machines. In this case localhost will refer to a different machine on each of the machines and the user will get many warnings about changed host keys.

Specifies the order in which the client should try protocol 2 authentication methods.

Specifies the protocol versions in order of preference. The possible values are ‘1’ and ‘2’. Multiple versions must be comma-separated. Use of protocol version 1 is NOT RECOMMENDED for security reasons. There is reason to believe it may be susceptible to man-in-the-middle attacks .

Specifies the command to use to connect to the server. The SSH client communicates with the proxy command using its standard input and standard output, and the proxy command should pass the communication to an SSH server .

Specifies whether to try public key authentication using SSH keys . Valid values are yes and no . When public key authentication is used in a production environment, a proper SSH key management system should also be put in place.

Specifies that a TCP port on the remote machine be forwarded over the secure channel to the specified host and port from the local machine. The first argument must be: [bind_address:]port and the second argument must be host:port . SSH tunneling is a powerful tool, but see security considerations on SSH tunneling .

Specifies whether to try rhosts based authentication with RSA host authentication. This is for protocol version 1 only and is deprecated.

Specifies whether to try RSA authentication. This is for protocol version 1 only and is deprecated.

Specifies what environment variables should be sent to the server.

Sets the number of keepalive messages that may be sent by the client without the client receiving any messages back from the server. When this threshold is reached the client will terminate the session.

Specifies interval for sending keepalive messages to the server. The messages are sent through the encrypted channel, and serve to detect if the server has crashed or the network has gone down.

Specifies which smartcard device to use.

Specifies if ssh should never automatically add host keys to the

/.ssh/known_hosts file, and refuses to connect to hosts whose host key has changed.

Specifies whether to send TCP keepalives to the other side. These operate on the level of the TCP protocol. Sending keepalives helps properly close the socket when the network or server goes down. On the other hand, without it, the connection may stay alive and any windows open, even if the network is down for a while.

If yes , request tun device forwarding between the client and the server. This used for implementing a VPN over SSH.

Specifies the tun devices to open on the client (local_tun) and the server (remote_tun).

Specifies whether or not to use a privileged port for outgoing connections. The client must run as root to use a privileged port. A privileged port is required for host-based authentication.

Specifies a file to use for per-user known host key database instead of the default

Specifies whether to verify the remote key using DNS and SSHFP resource records.

Specifies whether an ASCII art representation of the remote host key fingerprint is printed in addition to the hex fingerprint string at login and for unknown host keys.

Together with our customers, our mission is to secure their digital business on on-premises, cloud, and hybrid ecosystems cost-efficiently, at scale, and without disruptions to their operations or business continuity.

Источник

Note: If the directory does not exist, create it with the mkdir command:

mkdir ~/.ssh

Note: The parameters and arguments are case-sensitive.

Was this article helpful?

YesNo