User Tools

Site Tools


quickreference:ssh

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
quickreference:ssh [2019/08/03 19:41] – created - external edit 127.0.0.1quickreference:ssh [2025/01/05 01:45] (current) rodolico
Line 118: Line 118:
  
 You can now open an rdp client on your local machine to connect to localhost:3389. Any traffic for that will be forwarded to jane, which will then forward to john, who will then forward to 192.168.1.10. You can now open an rdp client on your local machine to connect to localhost:3389. Any traffic for that will be forwarded to jane, which will then forward to john, who will then forward to 192.168.1.10.
 +
 +===== Shared ssh configuration =====
 +
 +The simplest way to share ssh configurations with a group is to have a shared group of ssh configuration files. You might go so far as to have one file per client, with each file containing the config information to make an ssh connection to various machines within a client's LAN.
 +
 +In this example, we will have multiple files with a .ssh suffix. A sample file would be
 +<code sshconfig>
 +# acme.ssh
 +# ssh configuration file for client Acme
 +Host     acme.server1
 +Hostname 192.168.100.3
 +User     tech
 +
 +Host     acme.router
 +Hostname 192.168.100.1
 +User     administrator
 +Port     2222
 +</code>
 +A second file might be
 +<code sshconfig>
 +# hal.ssh
 +# ssh configuration file for client HAL
 +Host     hal.router
 +Hostname 192.168.55.1
 +User     root
 +Port     22
 +
 +Host     hal.fileserver
 +Hostname fileserver.hal.local
 +Port     22
 +</code>
 +Save these two files in a location shared with the relevant technicians who require access. This can be done via an NFS share, a local directory on a terminal server, or even sync'ing software like NextCloud.
 +
 +On each system, modify the system wide ssh configuration to include all files matching *.ssh. NOTE: This could also be achieved by adding the Include into individual users .ssh/config files.
 +<code bash>
 +echo 'Include /path/to/shared/ssh/configs/*.ssh' >> /etc/ssh/ssh_config
 +</code>
 +
 +==== Discussion ====
 +
 +  * Permissions should be fairly strict, though it is not as strictly enforced as some aspects of the ssh system.
 +    * All directories and files should be owned by root
 +    * files should be 644 (rw_rw_rw_)
 +    * directories 755 (rwxr_xr_x).
 +    * This allows all users to read the files but only root can modify them.
 +  * The .ssh suffix is only one convention; not a requirement or any kind of magic. By using "*.ssh", you are able to place other files as needed, and disable files by changing the suffix
 +  * Users can still have their own .ssh/config files for private configurations
 +  * Adding a client prefix with a period in between is simply convenient. In the example, you see that both hal and acme have a connection named router. **Host** is what you type, **Hostname**, **Port** and **User** is what you get. Host is just a convenient alias for the connection.
 +  * Host and Hostname are the only required fields. If no user is specified in the configuration, the current user is assumed. If no port is used, the default (port 22) is used. There are several other options you can include if you need.
 +  * The example of having one file per client/department/whatever is just organizational. You could easily have all of your entries in one file, or break it down by function. It all depends on your needs.
 +
 +===== Shared authorized_keys file =====
 +
 +Similar and complementary to the shared configuration above is the ability to have the same set of authorized_keys files available across multiple machines. This is especially important in clusters of servers, where all members of the cluster need to have the same basic set of public keys which are allowed to access them without a password.
 +
 +Again, share a single file across all machines with the public keys that are allowed to access all machines in the cluster. It does **not** hurt to have the public key of the current machine in this file, so no modification is necessary to ensure a machine does not have its own public key.
 +
 +An NFS mount is likely the best way for to set this up. I'm going to assume it is mounted at /srv/common_config, with a subdirectory of ssh.
 +
 +Add/replace the AuthorizedKeysFile directive in /etc/sshd_config. On some systems, you can simply create a file /etc/ssh/sshd_config.d
 +<code bash>
 +# Debian style
 +echo 'AuthorizedKeysFile .ssh/authorized_keys /srv/common_config/ssh/authorized_keys' >> \
 +   /etc/ssh/sshd_config.d/authorized_keys.conf
 +</code>
 +
 +Reload the sshd daemon.
 +
 +==== Discussion ====
 +  * Permissions very important here.
 +    * All files and directories must be owned by root
 +    * Directories must be 755, and if possible, 700
 +    * Files must be 644, and if possible, 600
 +  * Users may still have a personal .ssh/authorized_keys file.
 +  * Some systems are set for .ssh/authorized_keys2 as a second file. You can add this as a third option in the /etc/ssh/sshd_config.d/authorized_keys.conf file
 +  * This does **not** include the known_hosts file, so the initial connection must still be made. However, the documentation in sshd_config implies this can be accomplished somehow.
 +
 +===== Links =====
 +
 +  * https://www.ssh.com/academy/ssh/authorized-keys-openssh
quickreference/ssh.1564879264.txt.gz · Last modified: 2019/08/03 19:41 by 127.0.0.1