OpenSSH

来自 Arch Linux 中文维基

这篇文章或章节的翻译不反映原文。

原因：Partial translation, missing a huge chunk of the English page.（在 Talk:OpenSSH# 中讨论）

相关文章

OpenSSH（OpenBSD Secure Shell）是使用Secure Shell（SSH）协议，在计算机网络上提供加密通信会话的程序包。它是 SSH Communications Security 提供的专有 Secure Shell 软件的开源替代方案。OpenSSH 是 OpenBSD 项目的一部分，该项目由 Theo de Raadt 领导。

OpenSSH 有时候会与名字相似的 OpenSSL 相混淆；然而，它们的目的不同，开发团队也不同，名字相似只因为两者目标相似。

安装[编辑 | 编辑源代码]

安装 openssh包。

客户端用法[编辑 | 编辑源代码]

连接服务器： 

$ ssh -p 端口 用户名@服务器地址

如果服务器只允许公钥认证，参考 SSH 密钥。

配置[编辑 | 编辑源代码]

客户端可以配置一些通用的参数和主机信息。所有的参数都可以被声明为全局的或者限制为特定主机，例如： 

~/.ssh/config
# 全局选项
User 用户名

# 特定于主机的选项
Host myserver
    Hostname 服务器地址
    Port     端口

这样配置之后，下面的命令是等价的： 

$ ssh -p 端口 用户名@服务器地址
$ ssh myserver

参考 ssh_config(5) 可以获得更多的信息。

一些参数没有对应的命令行选项，但你可以在命令行中使用 -o 指定配置选项。例如 -oKexAlgorithms=+diffie-hellman-group1-sha1。

服务端用法[编辑 | 编辑源代码]

sshd 是 OpenSSH 服务器守护程序，通过 /etc/ssh/sshd_config 配置并由 sshd.service 管理。每次更改配置后，请在重新启动服务前在测试模式下运行 sshd 以确保它能够干净地启动。有效配置将不会产生输出。 

# sshd -t

配置[编辑 | 编辑源代码]

要仅允许某些用户访问，请添加以下一行： 

AllowUsers    用户1 用户2

要仅允许某些用户组访问： 

AllowGroups   用户组1 用户组2

要添加漂亮的欢迎消息（例如，输出 /etc/issue 文件），请配置 Banner 选项： 

Banner /etc/issue

sshdgenkeys 服务会自动在 /etc/ssh 中生成缺失的任何算法的公钥和私钥，即使 sshd_config 中的 HostKeyAlgorithms 选项只允许部分加密算法。OpenSSH 提供了三种基于 rsa、ecdsa 和 ed25519 算法的密钥对。要让 sshd 使用特定的密钥，请指定以下选项： 

HostKey /etc/ssh/ssh_host_rsa_key

如果服务器要暴露在 WAN 中，建议将默认端口从 22 更改为更高的随机端口，例如： 

Port 39901
提示：
  • 要选择尚未分配给常见服务的备用端口，请查看 TCP 和 UDP 端口号列表。还可以在本地的 /etc/services 中查找端口信息。更改 OpenSSH 所使用的端口有助于减少由攻击者使用自动程序尝试通过 SSH 登录你的服务器的情况（但无法彻底解决）。查看 Port knocking 了解相关内容。
  • 建议完全禁用密码登录。这将大大提高安全性，更多信息请参见#强制公钥认证。更多推荐的安全方法，请参阅#保护。
  • OpenSSH 可以监听多个端口，只需在配置文件中添加多个 Port 端口号。
  • 可以通过从 /etc/ssh 中删除要替换的主机密钥对并以 root 身份运行 ssh-keygen -A 来生成新的（或缺失的）主机密钥对。

管理守护程序[编辑 | 编辑源代码]

启动/启用 sshd.service。它将保持 SSH 守护程序始终处于活动状态，并为每个传入连接 fork。[1]

注意： 因 sshd.socket 易受到拒绝服务攻击的影响，openssh包 8.0p1-3 删除了它. 点击 FS#62248 查看详情。如果在更新到 openssh包 8.0p1-3 时启用了 sshd.socket，则 sshd.socket 和 sshd@.service 单元将被复制到 /etc/systemd/system/ 并重新启用。这样做只是为了不破坏现有设置；仍然建议用户迁移到 sshd.service。
警告： 如果你继续使用 sshd.socket, 请注意下列问题:
  • sshd.socket units 可能会失败 (例如：在内存耗尽的情况下) 并且 Restart=always 不能用于 socket units. 点击 systemd issue 11553 了解更多内容.
  • 使用套接字激活会导致拒绝服务，因为太多的连接会导致拒绝进一步激活服务。见 FS#62248.
注意： sshd.socket 使得 ListenAddress 设置失效，因此它会允许连接任意地址。为了使 ListenAddress 设置起作用，你必须编辑 sshd.socket 来为ListenStream 指定端口"和"IP (例如 ListenStream=192.168.1.100:22) 。你还必须在 [Socket] 添加 FreeBind=true ，否则设置IP地址会有 ListenAddress设置一样的缺点：如果网络没有及时启动，套接字会启动失败。
提示：当使用套接字激活时，每个连接(不同的实例名称)都会启动一个sshd@.service的瞬态实例，同时，不论是sshd.socket还是常规守护进程sshd.service都会允许在日志中监控连接尝试。通过root运行journalctl -u "sshd@*"或者journalctl /usr/bin/sshd可以查看SSH套接字激活实例的日志。

保护[编辑 | 编辑源代码]

允许通过 SSH 远程登录有利于管理，但可能会威胁服务器的安全。由于 SSH 访问通常是暴力攻击的目标，因此需要适当限制 SSH 访问以防止第三方访问服务器。

ssh-audit包 提供对服务端和客户端配置的自动分析。关于这个主题，还有其他几个很好的指南和工具，例如：

强制公钥认证[编辑 | 编辑源代码]

如果客户端无法通过公钥进行身份验证，SSH 服务端默认会退回到使用密码进行身份验证，从而允许恶意用户尝试通过暴力穷举密码来获取访问权限。防止这种攻击的最有效方法之一是完全禁用密码登录，并强制使用 SSH 密钥。这可以通过在守护程序配置文件中设置以下选项来完成： 

/etc/ssh/sshd_config
PasswordAuthentication no
AuthenticationMethods publickey
警告： 在将此添加到配置之前，请确保所有需要 SSH 访问的帐户都在相应的 authorized_keys 文件中设置了公钥身份验证。详细信息请参阅 SSH 密钥#将公钥复制到远程服务器上。

双重身份认证[编辑 | 编辑源代码]

SSH 可以被设置成需要多重验证。你可以通过 AuthenticationMethods 选项指定使用哪些验证方式。它将启用使用公钥作为两步验证。

身份验证提供程序[编辑 | 编辑源代码]

查看 Google Authenticator 去设置 Google 身份验证器. 对于 Duo，安装 提供 pam_duo.so 模块的包 duo_unixAUR 。阅读Duo Unix说明文件以了解如何设置Duo凭据(Integration Key, Secret Key, API Hostname)。

PAM 设置[编辑 | 编辑源代码]

要在 OpenSSH 中使用 PAM 请编辑下列文件： 

/etc/ssh/sshd_config
KbdInteractiveAuthentication yes
AuthenticationMethods publickey keyboard-interactive:pam

然后你可以通过公钥 或 在 PAM 中设置的用户身份验证方法登录： 另一方面，如果您想要根据 PAM 设置的要求在公钥 和 用户身份验证上对用户进行身份验证，请使用逗号而不是空格来分隔 AuthenticationMethods： 

/etc/ssh/sshd_config
KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactive:pam

为了必需使用 pubkey 和 pam 身份验证，您可能希望禁用密码登录： 

/etc/pam.d/sshd
auth      required  pam_securetty.so     #disable remote root
#Require google authenticator
auth      required  pam_google_authenticator.so
#But not password
#auth      include   system-remote-login
account   include   system-remote-login
password  include   system-remote-login
session   include   system-remote-login

防止暴力穷举攻击[编辑 | 编辑源代码]

限制root用户登录[编辑 | 编辑源代码]

拒绝[编辑 | 编辑源代码]
限制[编辑 | 编辑源代码]

对 authorized_keys 文件加锁[编辑 | 编辑源代码]

Tips and tricks[编辑 | 编辑源代码]

使用加密的SOCKS隧道[编辑 | 编辑源代码]

本文或本章节的语言、语法或风格需要改进。参考：Help:Style

原因：Written like a blog post.（在Talk:OpenSSH讨论）

这对连接到各种不安全无线连接的笔记本电脑用户非常有用。你唯一需要的是在一个有点安全的地方运行的SSH服务器，比如你的家或工作地点。使用动态DNS服务可能很有用，如DynDNS，这样你就不必记住你的IP地址。

步骤 1：开始连接[编辑 | 编辑源代码]

你只需要执行这一条命令就可以开始连接： 

$ ssh -TND 4711 user@host

其中 user 是你在 host 上运行的 SSH 服务器的用户名。它将询问你的密码，然后连接将被建立。N标志禁用了交互式提示，D标志指定了监听的本地端口（如果你愿意，可以选择任何端口号）。 T标志禁用伪终端分配。

添加 verbose（-v）标志是很好的，因为这样你就可以从该输出中验证它是否真的连接。

步骤 2 (方法 A)：配置你的浏览器(或者其它程序)[编辑 | 编辑源代码]

上述步骤仅在与使用新创建的socks隧道的web浏览器或其他程序结合使用时有用。因为SSH现在同时支持SOCKS v4和SOCKS v5，你可以选择他们中的任意一种。

  • 对于Firefox：在首选项 > 通用 找到页面底部并点击设置...，它在网络设置右边。接下来，在新的小窗口，选中 手动代理配置 并在SOCKS主机名框内输入localhost，在旁边的 端口框 输入端口(上述例子4711)。
Firefox不会自动通过socks隧道发出DNS请求，这种潜在的问题可以通过往下翻，使用SOCKS v5输入代理DNS来解决。很明显，这只有在选择SOCKS v5而不是v4时才有效。
  • 对于Chromium：可以设置SOCKS作为环境变量或者通过命令行，我建议在.bashrc添加以下函数：
function secure_chromium {
    port=4711
    export SOCKS_SERVER=localhost:$port
    export SOCKS_VERSION=5
    chromium &
    exit
}

或者 

function secure_chromium {
    port=4711
    chromium --proxy-server="socks://localhost:$port" &
    exit
}

现在打开命令行仅需这样做： 

$ secure_chromium

Enjoy your secure tunnel!

步骤 2 (方法 B)：配置本地TUN接口[编辑 | 编辑源代码]

这种方法在前期稍微复杂，但后期是你不必逐个手动配置每个应用程序来使用SOCKS代理。它涉及到建立一个本地TUN接口并通过该接口路由流量。

查看 VPN over SSH#Set up badvpn and tunnel interface.

X11 转发[编辑 | 编辑源代码]

X11 转发是一种机制，它允许运行在远程系统的X11程序的图形界面显示在本地客户端上。对于X11转发，远程主机不需要有完整安装的X11系统；但是，至少需要安装xauth，xauth是维护Xauthority配置的实用工具，这个配置用于X11会话服务端和客户端的认证(source)。

警告： X11 转发有很强的安全性，至少要通过阅读ssh(1), sshd_config(5), 和 ssh_config(5) 手册可以承认这一点。也可看 this StackExchange question.

设置[编辑 | 编辑源代码]

服务端[编辑 | 编辑源代码]
  • 安装 xorg-xauth包
  • 在 /etc/ssh/sshd_config:
    • 设置 X11Forwarding 为 yes
    • 检查 AllowTcpForwarding 和 X11UseLocalhost 选项为 yes, 并且 X11DisplayOffset 设为 10 (这是默认值除非被修改过，参考 sshd_config(5))
  • 然后重启这个 sshd daemon.
客户端[编辑 | 编辑源代码]
提示：如果GUI绘制不好或者显示错误，你可以启动 ForwardX11Trusted 选项 (-Y 切换为命令行)，这会防止X11转发受到 X11 SECURITY extension 的影响。如果你需要这样做，在开始这部分之前确保你已经阅读 the warning 。

Usage[编辑 | 编辑源代码]

正常登录到远程机器，如果客户端的配置文件中没有启用 ForwardX11，则指定 -X 开关： 

$ ssh -X user@host

如果你在试图运行图形应用程序时收到错误，请尝试用 ForwardX11Trusted 代替： 

$ ssh -Y user@host

如果获得输出 X11 forwarding request failed，则需要为你的远程机器重新进行设置。一旦X11转发请求成功，你可以在远程服务器上启动任何 X 程序，它将被转发到你的本地会话。 

$ xclock

包含 Can't open display 的错误输出表示 DISPLAY 设置不正确。 对一些应用程序要小心，因为它们会检查本地机器上是否有正在运行的实例。 Firefox 是一个例子：要么关闭正在运行的 Firefox 实例，要么使用下面的启动参数在本地机器上启动一个远程实例。 

$ firefox --no-remote

如果你在连接时得到 "X11 forwarding request failed on channel 0"（并且服务器 /var/log/errors.log 显示 "Failed to allocate internet-domain X11 display socket"），确保软件包 xorg-xauth包 已经安装。If its installation is not working, try to either:

  • 在 sshd_config 的 server 中启用 AddressFamily any 选项，或者
  • 在 sshd_config 中的 server 中设置 AddressFamily 选项设置为 inet。

将其设置为 inet 可能会解决 Ubuntu 客户端在 IPv4 上的问题。

对于在 SSH 服务器上以另一个用户身份运行 X 应用程序，you need to xauth add the authentication line taken from xauth list of the SSH logged in user.

提示：这里有一些排除 X11 转发 问题的有用链接：

转发其他端口[编辑 | 编辑源代码]

除了SSH对X11的内置支持外，它还可以通过使用本地转发或远程转发来安全地隧道传输任何TCP连接。 本地转发打开本地计算机上的一个端口，连接将被转发到远程主机，并从那里转发到给定的目的地。通常，转发目的地将与远程主机相同，从而为同一机器提供安全外壳，例如安全VNC连接。本地转发是通过-L交换机实现的，它是以-L交换机形式附带的转发规范，也是以<隧道端口>:<目的地地址>:<目标端口>形式附带的发送规范。

因此: 

$ ssh -L 1000:mail.google.com:25 192.168.0.100

将使用SSH登录并打开上的shell192.168.0.100, 并且还将创建从本地机器的TCP端口1000到端口25上的mail.google.com的隧道。一旦建立，连接到.google.com的25端口. 一旦建立, 连接到localhost:1000 将连接到Gmail SMTP端口。对于谷歌，任何这样的连接都会出现 (尽管不一定是通过连接传输的数据) 来源于192.168.0.100, 并且这样的数据在本地机器和192.168.0.100之间是安全的，但在192.168.0.100 和谷歌之间不是安全的，除非采取其他措施。

类似地: 

$ ssh -L 2000:192.168.0.100:6001 192.168.0.100

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.

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 -R switch and a forwarding specification in the form of <tunnel port>:<destination address>:<destination port>.

Thus: 

$ ssh -R 3000:irc.libera.chat:6667 192.168.0.200

will bring up a shell on 192.168.0.200, and connections from 192.168.0.200 to itself on port 3000 (the remote host's localhost:3000) will be sent over the tunnel to the local machine and then on to irc.libera.chat 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.

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. <tunnel address>:<tunnel port>:<destination address>:<destination port>. The <tunnel address> can be any address on the machine at the start of the tunnel. The address localhost allows connections via the localhost or loopback interface, and an empty address or * allow connections via any interface. By default, forwarding is limited to connections from the machine at the "beginning" of the tunnel, i.e. the <tunnel address> is set to localhost. Local forwarding requires no additional configuration; however, remote forwarding is limited by the remote server's SSH daemon configuration. See the GatewayPorts option in sshd_config(5) and -L address option in ssh(1) for more information about remote forwarding and local forwarding, respectively.

Jump hosts[编辑 | 编辑源代码]

有时，可能无法直接连接到目标的SSH守护程序，因而需要使用一个跳转服务器（或堡垒服务器）。为此，我们试图将两个或更多的 SSH 隧道连接在一起，并假设你的本地密钥对链上的每个服务器都有授权。这可以通过 SSH 代理转发（-A）和伪终端分配（-t）来实现，伪终端分配以下列语法转发你的本地密钥。 

$ ssh -A -t -l user1 bastion1 \
  ssh -A -t -l user2 intermediate2 \
  ssh -A -t -l user3 target

一个更简单的方法是使用-J： 

$ ssh -J user1@bastion1,user2@intermediate2 user3@target

-J 指令中的多个主机可以用逗号隔开；它们将按照列出的顺序被连接到。user...@ 部分不是必须的，但可以使用。The host specifications for -J use the ssh configuration file, so specific per-host options can be set there, if needed.

-J标志相当于配置文件中ProxyJump选项。详情见ssh_config(5)。

Reverse SSH through a relay[编辑 | 编辑源代码]

本文或本章节的语言、语法或风格需要改进。参考：Help:Style

原因：The idea of SSH tunneling is classic, so some references for detailed explanation would be nice. E.g. [2] which includes other scenarios.（在Talk:OpenSSH讨论）

The idea is that the client connects to the server via another relay while the server is connected to the same relay using a reverse SSH tunnel. This is useful when the server is behind a NAT, and the relay is a publicly accessible SSH server used as a proxy to which the user has access. Therefore, the prerequisite is that the client's keys are authorized against both the relay and the server, and the server needs to be authorized against the relay as well for the reverse SSH connection.

The following configuration example assumes that user1 is the user account used on client, user2 on relay and user3 on server. First, the server needs to establish the reverse tunnel with: 

ssh -R 2222:localhost:22 -N user2@relay

Which can also be automated with a startup script, systemd service or autossh.

这篇文章的某些内容需要扩充。

原因： Explain why ssh user3@relay -p 2222 is not sufficient. (在 Talk:OpenSSH 中讨论)

At the client side, the connection is established with: 

ssh -t user2@relay ssh user3@localhost -p 2222

The remote command to establish the connection to reverse tunnel can also be defined in relay's ~/.ssh/authorized_keys by including the command field as follows: 

command="ssh user3@localhost -p 2222" ssh-rsa KEY2 user1@client

In this case the connection is established with: 

ssh user2@relay

Note that SCP's autocomplete function in client's terminal is not working and even the SCP transfers themselves are not working under some configurations.

Multiplexing[编辑 | 编辑源代码]

SSH守护进程通常监听 22 端口。然而，许多公共互联网热点地区通常会屏蔽所有不在常规HTTP/S端口（分别为80和443）的流量，从而阻止了SSH连接。最直接解决这个问题的办法是让 sshd 额外监听白名单中的一个端口。 

/etc/ssh/sshd_config
Port 22
Port 443

然而，443 端口很可能已经被提供 HTTPS 服务器使用，在这种情况下，可以使用一个多路复用器，如 sslh包，它监听多路复用端口，可以智能地将数据包转发给许多服务。

Speeding up SSH[编辑 | 编辑源代码]

There are several client configuration options which can speed up connections either globally or for specific hosts. See ssh_config(5) for full descriptions of these options.

  • Use a faster cipher: on modern CPUs with AESNI instructions, aes128-gcm@openssh.com and aes256-gcm@openssh.com should offer significantly better performance over openssh's default preferred cipher, usually chacha20-poly1305@openssh.com. Cipher can be selected with the -c flag. For a permanent effect, put Ciphers option in your ~/.ssh/config with ciphers in new preferred order, e.g.:
    Ciphers aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
  • Enable or disable compression: compression can increase speed on slow connections; it is enabled with the Compression yes option or the -C flag. However, the compression algorithm used is the relatively slow gzip(1) which becomes the bottleneck on fast networks. In order to speed up the connection, one should use the Compression no option on local or fast networks.
  • Connection sharing: you can make all sessions to the same host share a single connection using these options:
    ControlMaster auto
ControlPersist yes
ControlPath ~/.ssh/sockets/socket-%r@%h:%p
where ~/.ssh/sockets can be any directory not writable by other users.

ControlPersist specifies how long the master should wait in the background for new clients after the initial client connection has been closed. Possible values are either:

    • no to close the connection immediately after the last client disconnects,
    • a time in seconds,
    • yes to wait forever, the connection will never be closed automatically.
  • Login time can be shortened by bypassing IPv6 lookup using the AddressFamily inet option or -4 flag.
  • Last, if you intend to use SSH for SFTP or SCP, High Performance SSH/SCP can significantly increase throughput by dynamically raising the SSH buffer sizes. Install the package openssh-hpn-gitAUR to use a patched version of OpenSSH with this enhancement.

使用 SSHFS 挂载一个远程的文件系统[编辑 | 编辑源代码]

请查看 SSHFS 文章，将 SSH 可访问的远程系统安装到本地目录。这样您就可以使用任何工具对安装的文件执行任何操作（复制、重命名、使用 vim 编辑等）。sshfs 一般优于 shfs，后者自 2004 年以来一直没有更新。

保活[编辑 | 编辑源代码]

默认情况下，如果 SSH 会话已经空闲了一段时间，它将自动注销。 为了保持会话，如果在一段时间内没有收到数据，客户端可以向服务器发送保持活动的信号，或者如果服务器没有收到客户端的消息，则可以对称地定期发送消息。

  • 在 'server 端，ClientAliveInterval 以秒为单位设置超时，如果没有从客户端接收到数据，sshd 将发送响应请求。默认值为 0，不发送消息。例如，要每 60 秒从客户端请求一次响应，请在 server configuration 中设置 ClientAliveInterval 60 选项。另见 ClientAliveCountMax 和 TCPKeepAlive 选项。
  • 在 'client 端，ServerAliveInterval 控制从客户端发送到服务器的响应请求之间的间隔。例如，要请求服务器每 120 秒响应一次，请将 ServerAliveInterval 120 选项添加到 client configuration。另请参见 ServerAliveCountMax 和 TCPKeepAlive 选项。


注意： 为了确保会话保持活动状态，客户机或服务器中只有一个需要发送 keep alive 请求。 如果同时控制服务器和客户机，一个合理的选择是只配置需要持久会话的客户机，并使其他客户机和服务器保持默认配置。

Automatically restart SSH tunnels with systemd[编辑 | 编辑源代码]

systemd can automatically start SSH connections on boot/login and restart them when they fail. This makes it a useful tool for maintaining SSH tunnels.

The following service can start an SSH tunnel on login using the connection settings in your ssh configuration. If the connection closes for any reason, it waits 10 seconds before restarting it: 

~/.config/systemd/user/tunnel.service
[Unit]
Description=SSH tunnel to myserver

[Service]
Type=simple
Restart=always
RestartSec=10
ExecStart=/usr/bin/ssh -F %h/.ssh/config -N myserver

Then enable and start the Systemd/User service. See #Keep alive for how to prevent the tunnel from timing out. If you wish to start the tunnel on boot, you might want to rewrite the unit as a system service.

Autossh - automatically restarts SSH sessions and tunnels[编辑 | 编辑源代码]

When a session or tunnel cannot be kept alive, for example due to bad network conditions causing client disconnections, you can use autossh包 to automatically restart them.

Usage examples: 

$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" username@example.com

Combined with SSHFS: 

$ sshfs -o reconnect,compression=yes,transform_symlinks,ServerAliveInterval=45,ServerAliveCountMax=2,ssh_command='autossh -M 0' username@example.com: /mnt/example

Connecting through a SOCKS-proxy set by Proxy settings: 

$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" -NCD 8080 username@example.com

With the -f option autossh can be made to run as a background process. Running it this way however means the passphrase cannot be entered interactively.

The session will end once you type exit in the session, or the autossh process receives a SIGTERM, SIGINT of SIGKILL signal.

Run autossh automatically at boot via systemd[编辑 | 编辑源代码]

If you want to automatically start autossh, you can create a systemd unit file: 

/etc/systemd/system/autossh.service
[Unit]
Description=AutoSSH service for port 2222
After=network.target

[Service]
Environment="AUTOSSH_GATETIME=0"
ExecStart=/usr/bin/autossh -M 0 -NL 2222:localhost:2222 -o TCPKeepAlive=yes foo@bar.com

[Install]
WantedBy=multi-user.target

Here AUTOSSH_GATETIME=0 is an environment variable specifying how long ssh must be up before autossh considers it a successful connection, setting it to 0 autossh also ignores the first run failure of ssh. This may be useful when running autossh at boot. Other environment variables are available at autossh(1). Of course, you can make this unit more complex if necessary (see the systemd documentation for details), and obviously you can use your own options for autossh, but note that the -f implying AUTOSSH_GATETIME=0 does not work with systemd.

Remember to start and/or enable the service afterwards.

You may also need to disable ControlMaster e.g. 

ExecStart=/usr/bin/autossh -M 0 -o ControlMaster=no -NL 2222:localhost:2222 -o TCPKeepAlive=yes foo@bar.com
提示：It is also easy to maintain several autossh processes, to keep several tunnels alive. Just create multiple service files with different names.

Alternative service should SSH daemon fail[编辑 | 编辑源代码]

For remote or headless servers which rely exclusively on SSH, a failure to start the SSH daemon (e.g., after a system upgrade) may prevent administration access. systemd offers a simple solution via OnFailure option.

Let us suppose the server runs sshd and telnet is the fail-safe alternative of choice. Create a file as follows. Do not enable telnet.socket! 

/etc/systemd/system/sshd.service.d/override.conf
[Unit]
OnFailure=telnet.socket

That's it. Telnet is not available when sshd is running. Should sshd fail to start, a telnet session can be opened for recovery.

Terminal background color based on host[编辑 | 编辑源代码]

为了更好地区分在不同主机上的情况，可以设置 基于主机类型的不同背景颜色 。 这种解决方案仅限于 ZSH。

Network specific configuration[编辑 | 编辑源代码]

You can use host configuration specific to the network you are connected to using a Match exec.

For example, when using nmcli, and the connection is configured (manually or through DHCP) to use a search-domain: 

Match exec "nmcli | grep domains: | grep example.com"
  CanonicalDomains example.com
  # Should you use a different username on this network
  #User username
  # Use a different known_hosts file (for private network or synchronisation)
  #UserKnownHostsFile <network>_known_hosts

Private networks hostkeys verification[编辑 | 编辑源代码]

Because different servers on different networks are likely to share a common private IP address, you might want to handle them differently.

本文或本章节的事实准确性存在争议。

原因： The best solution would not need a warning to use something else in practice.（在 Talk:OpenSSH 中讨论）


The best solution is to use the #Network specific configuration to use a different UserKnownHostsFile depending on the network you are on. The second solution, best used as default when you are working on new/prototype networks, would be to simply ignore hostkeys for private networks: 

Host 10.* 192.168.*.* 172.31.* 172.30.* 172.2?.* 172.1?.*
    # Disable HostKey verification
    # Trust HostKey automatically
    StrictHostKeyChecking no
    # Do not save the HostKey
    UserKnownHostsFile=/dev/null
    # Do not display: "Warning: Permanently Added ..."
    LogLevel Error

本文或本章节的事实准确性存在争议。

原因： The known_hosts file records an IP address even when you use hostname to access the server.（在 Talk:OpenSSH 中讨论）


警告： In a production environment, make sure to either use the hostname to access the host and/or to use network specific known_hosts files.

在登录时运行命令[编辑 | 编辑源代码]

如果你使用的是交互式会话，有多种方法可以在登录时执行一个命令：

  • 使用远程主机上的 authorized_keys 文件（见AUTHORIZED_KEYS FILE FORMAT，见sshd(8)）
  • 如果服务器启用了 ~/.ssh/rc 选项，则使用远程主机上的 PermitUserRC
  • 使用远程主机上的 shell 配置文件，例如 .bashrc。

转发代理[编辑 | 编辑源代码]

SSH代理转发允许你在连接到一个服务器时使用你的本地密钥。建议只对选定的主机启用代理转发。 

~/.ssh/config
Host myserver.com
    ForwardAgent yes

接下来，配置 SSH代理 并使用 ssh-add 添加你的本地密钥。

如果你现在连接到一个远程服务器，你将能够使用你的本地密钥连接到其他服务。

生成新的密钥对[编辑 | 编辑源代码]

新的服务器私钥可以通过以下方式生成:

  1. 删除已有的所有密钥, e.g.: 
    # rm /etc/ssh/ssh_host_*_key*
  2. Restarting sshdgenkeys.service 或者以 root 身份运行 ssh-keygen -A.

参见[编辑 | 编辑源代码]

取自“https://wiki.archlinuxcn.org/wzh/index.php?title=OpenSSH&oldid=25930”