之前为了方便连接到公网服务器，在本地SSH 客户端设置了socket代理。这样能加速访问服务器。
但是有一天，要访问局域网时，因为默认开了代理的缘故，本机SSH 无法连接到 局域网内的centos服务器。【其实是开了centos虚拟机，网络配置是桥接】
只要将本地的SSH取消socket代理就行了，这样就能访问局域网内的服务器了。
Category: 系统通用-ssh
SSH-用screen恢复会话
你是不是经常需要 SSH 或者 telent 远程登录到 Linux 服务器？你是不是经常为一些长时间运行的任务而头疼，比如系统备份、ftp 传输等等。通常情况下我们都是为每一个这样的任务开一个远程终端窗口，因为他们执行的时间太长了。必须等待它执行完毕，在此期间可不能关掉窗口或者断开连接，否则这个任务就会被杀掉，一切半途而废了。
screen : 退出销毁操作
screen -ls
There is a screen on:
30339.pyapi (Detached)
1 Socket in /var/run/screen/S-root.
screen -r 30339 //进入要中断的screen
exit //exit 或者 control +c 退出 screen
元凶：SIGHUP 信号
让我们来看看为什么关掉窗口/断开连接会使得正在运行的程序死掉。
在Linux/Unix中，有这样几个概念：
- 进程组（process group）：一个或多个进程的集合，每一个进程组有唯一一个进程组ID，即进程组长进程的ID。
- 会话期（session）：一个或多个进程组的集合，有唯一一个会话期首进程（session leader）。会话期ID为首进程的ID。
- 会话期可以有一个单独的控制终端（controlling terminal）。与控制终端连接的会话期首进程叫做控制进程（controlling process）。当前与终端交互的进程称为前台进程组。其余进程组称为后台进程组。
根据POSIX.1定义：
- 挂断信号（SIGHUP）默认的动作是终止程序。
- 当终端接口检测到网络连接断开，将挂断信号发送给控制进程（会话期首进程）。
- 如果会话期首进程终止，则该信号发送到该会话期前台进程组。
- 一个进程退出导致一个孤儿进程组中产生时，如果任意一个孤儿进程组进程处于STOP状态，发送SIGHUP和SIGCONT信号到该进程组中所有进程。
因此当网络断开或终端窗口关闭后，控制进程收到SIGHUP信号退出，会导致该会话期内其他进程退出。
我们来看一个例子。打开两个SSH终端窗口，在其中一个运行top命令。
[root@tivf09 root]# top
在另一个终端窗口，找到top的进程ID为5180，其父进程ID为5128，即登录shell。
[root@tivf09 root]# ps -ef|grep top root 5180 5128 0 01:03 pts/0 00:00:02 top root 5857 3672 0 01:12 pts/2 00:00:00 grep top
使用pstree命令可以更清楚地看到这个关系：
[root@tivf09 root]# pstree -H 5180|grep top |-sshd-+-sshd---bash---top
使用ps-xj命令可以看到，登录shell（PID 5128）和top在同一个会话期，shell为会话期首进程，所在进程组PGID为5128，top所在进程组PGID为5180，为前台进程组。
[root@tivf09 root]# ps -xj|grep 5128 5126 5128 5128 5128 pts/0 5180 S 0 0:00 -bash 5128 5180 5180 5128 pts/0 5180 S 0 0:50 top 3672 18095 18094 3672 pts/2 18094 S 0 0:00 grep 5128
关闭第一个SSH窗口，在另一个窗口中可以看到top也被杀掉了。
[root@tivf09 root]# ps -ef|grep 5128 root 18699 3672 0 04:35 pts/2 00:00:00 grep 5128
如果我们可以忽略SIGHUP信号，关掉窗口应该就不会影响程序的运行了。nohup命令可以达到这个目的，如果程序的标准输出/标准错误是终端，nohup默认将其重定向到nohup.out文件。值得注意的是nohup命令只是使得程序忽略SIGHUP信号，还需要使用标记&把它放在后台运行。
nohup <command> [argument…] &
虽然nohup很容易使用，但还是比较“简陋”的，对于简单的命令能够应付过来，对于复杂的需要人机交互的任务就麻烦了。
其实我们可以使用一个更为强大的实用程序screen。流行的Linux发行版（例如Red Hat Enterprise Linux 4）通常会自带screen实用程序，如果没有的话，可以从GNU screen的官方网站下载。
[root@tivf06 ~]# rpm -qa|grep screen xscreensaver-4.18-5.rhel4.11 screen-4.0.2-5
开始使用Screen
# 先在 服务器端 安装 screen [root@ttsdy ~]# yum install screen
简单来说，Screen是一个可以在多个进程之间多路复用一个物理终端的窗口管理器。Screen中有会话的概念，用户可以在一个screen会话中创建多个screen窗口，在每一个screen窗口中就像操作一个真实的telnet/SSH连接窗口那样。在screen中创建一个新的窗口有这样几种方式：
1．直接在命令行键入screen命令
[bash] [root@tivf06 ~]# screen [/bash] Screen将创建一个执行shell的全屏窗口。你可以执行任意shell程序，就像在ssh窗口中那样。在该窗口中键入exit退出该窗口，如果这是该screen会话的唯一窗口，该screen会话退出，否则screen自动切换到前一个窗口。 2．Screen命令后跟你要执行的程序。[root@tivf06 ~]# screen vi test.cScreen创建一个执行vi test.c的单窗口会话，退出vi将退出该窗口/会话。
3．以上两种方式都创建新的screen会话。我们还可以在一个已有screen会话中创建新的窗口。在当前screen窗口中键入
C-a c，即Ctrl键+a键，之后再按下c键，screen 在该会话内生成一个新的窗口并切换到该窗口。screen还有更高级的功能。你可以不中断screen窗口中程序的运行而暂时断开（detach）screen会话，并在随后时间重新连接（attach）该会话，重新控制各窗口中运行的程序。例如，我们打开一个screen窗口编辑/tmp/abc文件：
[root@tivf06 ~]# screen vi /tmp/abc之后我们想暂时退出做点别的事情，比如出去散散步，那么在screen窗口键入
C-a d，Screen会给出detached提示：暂时中断会话
半个小时之后回来了，找到该screen会话：
[root@tivf06 ~]# screen -ls There is a screen on: 16582.pts-1.tivf06 (Detached) 1 Socket in /tmp/screens/S-root.重新连接会话：
[root@tivf06 ~]# screen -r 16582看看出现什么了，太棒了，一切都在。继续干吧。
你可能注意到给screen发送命令使用了特殊的键组合C-a。这是因为我们在键盘上键入的信息是直接发送给当前screen窗口，必须用其他方式向screen窗口管理器发出命令，默认情况下，screen接收以C-a开始的命令。这种命令形式在screen中叫做键绑定（key binding），C-a叫做命令字符（command character）。
可以通过
C-a ?来查看所有的键绑定，常用的键绑定有：Screen常用选项
使用键绑定C-a ?命令可以看到, 默认的命令字符（Command key）为C-a，转义C-a（literal ^a）的字符为a：
Screen 常用选项
因为screen把C-a看作是screen命令的开始，所以如果你想要screen窗口接收到C-a字符，就要输入C-a a。Screen也允许你使用-e选项设置自己的命令字符和转义字符，其格式为：
-exy x为命令字符，y为转义命令字符的字符
下面命令启动的screen会话指定了命令字符为C-t，转义C-t的字符为t，通过C-t ?命令可以看到该变化。
[root@tivf18 root]# screen -e^tt自定义命令字符和转义字符
其他常用的命令选项有：
下例显示当前有两个处于detached状态的screen会话，你可以使用screen -r <screen_pid>重新连接上：
[root@tivf18 root]# screen –ls There are screens on: 8736.pts-1.tivf18 (Detached) 8462.pts-0.tivf18 (Detached) 2 Sockets in /root/.screen. [root@tivf18 root]# screen –r 8736如果由于某种原因其中一个会话死掉了（例如人为杀掉该会话），这时screen -list会显示该会话为dead状态。使用screen -wipe命令清除该会话：
[root@tivf18 root]# kill -9 8462 [root@tivf18 root]# screen -ls There are screens on: 8736.pts-1.tivf18 (Detached) 8462.pts-0.tivf18 (Dead ???) Remove dead screens with 'screen -wipe'. 2 Sockets in /root/.screen. [root@tivf18 root]# screen -wipe There are screens on: 8736.pts-1.tivf18 (Detached) 8462.pts-0.tivf18 (Removed) 1 socket wiped out. 1 Socket in /root/.screen. [root@tivf18 root]# screen -ls There is a screen on: 8736.pts-1.tivf18 (Detached) 1 Socket in /root/.screen. [root@tivf18 root]#-d –m 选项是一对很有意思的搭档。他们启动一个开始就处于断开模式的会话。你可以在随后需要的时候连接上该会话。有时候这是一个很有用的功能，比如我们可以使用它调试后台程序。该选项一个更常用的搭配是：-dmS sessionname
启动一个初始状态断开的screen会话：
[root@tivf06 tianq]# screen -dmS mygdb gdb execlp_test连接该会话：
[root@tivf06 tianq]# screen -r mygdb管理你的远程会话
先来看看如何使用screen解决SIGHUP问题，比如现在我们要ftp传输一个大文件。如果按老的办法，SSH登录到系统，直接ftp命令开始传输，之后。。如果网络速度还可以，恭喜你，不用等太长时间了；如果网络不好，老老实实等着吧，只能传输完毕再断开SSH连接了。让我们使用screen来试试。
SSH登录到系统，在命令行键入screen。
[root@tivf18 root]# screen在screen shell窗口中输入ftp命令，登录，开始传输。不愿意等了？OK，在窗口中键入C-a d：
管理你的远程会话
然后。。退出SSH登录？随你怎样，只要别杀掉screen会话。
是不是很方便？更进一步，其实我们可以利用screen这种功能来管理你的远程会话，保存你所有的工作内容。你是不是每次登录到系统都要开很多窗口，然后每天都要重复打开关闭这些窗口？让screen来帮你“保存”吧，你只需要打开一个ssh窗口，创建需要的screen窗口，退出的时候C-a d“保存”你的工作，下次登录后直接screen -r <screen_pid>就可以了。
最好能给每个窗口起一个名字，这样好记些。使用C-a A给窗口起名字。使用C-a w可以看到这些窗口名字，可能名字出现的位置不同。使用putty：
putty
使用telnet：
telnet
更多Screen功能
Screen提供了丰富强大的定制功能。你可以在Screen的默认两级配置文件/etc/screenrc和$HOME/.screenrc中指定更多，例如设定screen选项，定制绑定键，设定screen会话自启动窗口，启用多用户模式，定制用户访问权限控制等等。如果你愿意的话，也可以自己指定screen配置文件。
以多用户功能为例，screen默认是以单用户模式运行的，你需要在配置文件中指定multiuser on 来打开多用户模式，通过acl*（acladd,acldel,aclchg...）命令，你可以灵活配置其他用户访问你的screen会话。更多配置文件内容请参考screen的man页。
参考资料
- “Advanced Programming in the UNIX® Environment: Second Edition” W. Richard Stevens, Stephen A. Rago 提供了更多关于Linux/Unix进程关系、信号的知识。
- GNU Screen的官方网站：http://www.gnu.org/software/screen/
- Screen的man page提供了最详细的信息：http://www.slac.stanford.edu/comp/unix/package/epics/extensions/iocConsole/screen.1.html
转载自：https://www.ibm.com/developerworks/cn/linux/l-cn-screen/
SSH-解决连接自动断开
在使用SSH客户端进行连接管理的时候如果长时间不输入命令，服务器会自动断开连接，尤其是利用代理进行SSH连接时情况更突出。
Bad packet length 2165930639. padding error: need -2129036657 block 8 mod 7 ssh_dispatch_run_fatal: Connection to UNKNOWN: message authentication code incorrect
——————————————————————————-
这样连接上去，利用代理，会经常掉线。
后来，我提权 ，用sudo ，以root 身份运行就 不会掉线了，奇怪了啊。
记得 用 root 身份连接 +
打开服务器 /etc/ssh/sshd_config，我在最后增加一行
ClientAliveInterval 60
ClientAliveCountMax 1
(可能我在 ~/.ssh/ssh_config 文件里配置了
TCPKeepAlive yes
ServerAliveInterval 30
前一个参数是说要保持连接，后一个参数表示每过30秒发一个数据包到服务器表示“我还活着”。可能这地方也需要配置下吧。)
这样实际使用中 的确 可以 保持 很长的连接。
（操作 环境 mac下 使用root账户 操作 SSH ， 并以root用户登入到远程 centos 主机中 ）
重要信息：经过测试：
# 在 ~/.ssh/ssh_config 文件(即当前用户的SSH配置文件中) 配置了下面参数 #1、保持 tcp 连接 TCPKeepAlive yes #2、每过30秒发一个数据包到服务器表示"我还活着" ServerAliveInterval 30 # 经过测试，用本机当前用户 进行 SSH远程连接操作 也没有问题。不会掉线了。
其他方法也有，比如用 screen 恢复 ssh 会话。
*********************************************************************
后面提到的方法都已经单独试过了，感觉 没有 效果。
——————————————————————————-
针对这种情况，我在网上搜集了可以让 SSH 保持连接的方法与大家分享
在服务器端， 可以让服务器发送“心跳”信号测试提醒客户端进行保持连接
通过修改 sshd 的配置文件，能够让 SSH Server 发送“心跳”信号来维持持续连接，下面是设置的内容
打开服务器 /etc/ssh/sshd_config，我在最后增加一行
ClientAliveInterval 60
ClientAliveCountMax 1
这 样，SSH Server 每 60 秒就会自动发送一个信号给 Client，而等待 Client 回应，（注意：是服务器发心跳信号，不是客户端，这个有别于一些 FTP Client 发送的 KeepAlives 信号哦～～～），如果客户端没有回应，会记录下来直到记录数超过 ClientAliveCountMax 的值时，才会断开连接。
如果你没有服务器端管理权限， 在客户端进行设置也可以实现
只要在/etc/ssh/ssh_config文件里加两个参数就行了
1 TCPKeepAlive yes
2 ServerAliveInterval 300
前一个参数是说要保持连接，后一个参数表示每过5分钟发一个数据包到服务器表示“我还活着”
如果你没有root权限，修改或者创建~/.ssh/ssh_config也是可以的
在这种方法中， 如果你只想针对某一个ssh连接进行持续， 你可以将上述配置文件复制一下进行修改然后在连接的时候使用 -F参数进行配置文件的指定。 当然因为只需要修改两个参数， 你也可以直接在连接命令中进行设定即：
ssh -o TCPKeepAlive=yes -o ServerAliveInterval=300 [email protected] -p 12345678
——————————————————————————-
有可能是 网络问题，杀毒软件导致 端口被占，收到的 数据包 出错
Found the cause for my problem by accident. I tried to use an old trick and started a System Recovery to undo my Git installation. It failed because of my Virus Scanner. After uninstalling Bitdefender Antivirus Free Edition it worked. Incoming SSH2 messages were blocked (got Windows 8 Pro) which caused the bad packet length error. Anyway, thanks for your support!
——————————————————————————–
有可能是 一开始 验证密钥文件 时，密钥文件 默认名字可能是其他服务器的密钥 ，所以尽量重命名，指定服务器需要的密钥
save the keys in C:\Users\myUserName\.ssh\keyName
Your local ssh command would look for ssh keys in %HOME%\.ssh\id_rsa(.pub).
So you need to either:
rename the local files representing your ssh (public and private) keys
or reference those through a %HOME%\.ssh\config which can reference the exact name of your private key (with an IdentityFile directive).
Host gitlab
user git
hostname your.gitlab.server.com
IdentityFile C:\user\YourUsername\.ssh\keyName
SSH-端口转发总结
第一部分 概述
端口转发概述
让我们先来了解一下端口转发的概念吧。我们知道，SSH 会自动加密和解密所有 SSH 客户端与服务端之间的网络数据。但是，SSH 还同时提供了一个非常有用的功能，这就是端口转发。它能够将其他 TCP 端口的网络数据通过 SSH 链接来转发，并且自动提供了相应的加密及解密服务。这一过程有时也被叫做“隧道”（tunneling），这是因为 SSH 为其他 TCP 链接提供了一个安全的通道来进行传输而得名。例如，Telnet，SMTP，LDAP 这些 TCP 应用均能够从中得益，避免了用户名，密码以及隐私信息的明文传输。而与此同时，如果您工作环境中的防火墙限制了一些网络端口的使用，但是允许 SSH 的连接，那么也是能够通过将 TCP 端口转发来使用 SSH 进行通讯。总的来说 SSH 端口转发能够提供两大功能：
1、加密 SSH Client 端至 SSH Server 端之间的通讯数据。
2、突破防火墙的限制完成一些之前无法建立的 TCP 连接。
图 1. SSH 端口转发
如上图所示，使用了端口转发之后，TCP 端口 A 与 B 之间现在并不直接通讯，而是转发到了 SSH 客户端及服务端来通讯，从而自动实现了数据加密并同时绕过了防火墙的限制。
第二部分 本地转发与远程转发
在选择端口号时要注意非管理员帐号是无权绑定 1-1023 端口的，所以一般是选用一个 1024-65535 之间的并且尚未使用的端口号即可。
假设:
墙内客户端 A 128.128.128.128
墙外代理服务器 B 138.138.138.138
目标服务器 C 158.158.158.158
如果 A不能直接访问C ，B能访问C ， A能访问B。
可以采用 本地端口转发：
绑定A上的一个端口如2233 ，A向B发起建立SSH隧道连接请求，然后B再访问 C上的端口如5566
这样：访问A上的2233端口 就等于 在访问 C上5566端口
# root@root@B的IP地址 以root用户 登录 B 服务器 #-v 冗详模式. 使打印关于运行情况的调试信息. 在调试连接, 认证和配置问题时非常有用. #并联的 -v 选项能够增加冗详程度. 最多为三个. #-C 要求进行数据压缩 (包括 stdin, stdout, stderr以及转发X11和TCP/IP连接的数据) #-L port:host:hostport 将本地机[主机A]的某个端口[port]转发到远端指定机器[主机C别名host]的指定端口[hostport] # 工作原理是这样的,本地机器[主机A]上分配了一个 socket 侦听 port 端口, 一旦这个端口上有了连接, # 该连接就经过安全通道转发出去, 同时远程主机[主机B]和 host[主机C] 的 hostport 端口建立连接. # 可以在配置文件中指定端口的转发. 只有 root 才能转发特权端口. IPv6 地址用另一种格式说明: port/host/hostport ssh -v -C -L 2233:C的IP地址:5566 root@B的IP地址 -p B的ssh端口号
那么这个端口转发可以被其他机器使用么？比如能否新增加一台 [主机X] 来直接连接 [主机A] 的 2233 端口？答案是不行的，在主流 SSH 实现中，本地端口转发绑定的是 lookback 接口，这意味着只有 localhost 或者 127.0.0.1 才能使用本机的端口转发 , 其他机器发起的连接只会得到“ connection refused. ”。好在 SSH 同时提供了 GatewayPorts 关键字，我们可以通过指定它与其他机器共享这个本地端口转发。
ssh -g -L 主机A的端口如5901:主机C:主机C的端口如5901 通过SSH连接的主机B
特殊情况下：C的IP地址:5566 可以变成 localhost:5566
localhost:5566 是针对 中间的代理服务器 来说的
这相当于A访问自己的2233端口时 等价于 直接访问B内部的5566端口[若5566端口没有暴露给别的主机,就可规避B上的防火墙]
ssh -v -C -L 2233:localhost:5566 root@B的IP地址 -p B的ssh端口号
假设:
墙内客户端 A 128.128.128.128
墙外代理服务器 B 138.138.138.138
目标服务器 C 158.158.158.158
如果 A不能直接访问C ，B能访问C ， B能访问A。
可以采用 远程端口转发：
绑定A上的一个端口如2233 ，B向A发起建立SSH隧道连接请求，然后B再访问C上的端口如5566
这样：访问A上的2233端口 就等于 在访问 C上5566端口
#-R port:host:hostport 将客户机[主机A]的某个端口[port]转发到远端指定机器[主机C别名host]的指定端口[hostport] # 工作原理是这样的, 远程主机[主机A]上分配了一个 socket 侦听 port 端口, 一旦这个端口上有了连接, # 该连接就经过安全通道转向出去, 同时本地主机[主机B]和 host[主机C] 的 hostport 端口建立连接. # 可在配置文件中指定端口的转发.只有root登录远程主机[主机A]才能转发特权端口. # IPv6 地址用另一种格式说明: port/host/hostport ssh -v -C -R 2233:C的IP地址:5566 root@A的IP地址 -p A的ssh端口号
特殊情况下：C的IP地址:5566 可以变成 localhost:5566
localhost:5566 是针对 中间的代理服务器 来说的
这相当于A访问自己的2233端口时 等价于 直接访问B内部的5566端口[若5566端口没有暴露给别的主机,就可规避B上的防火墙]
ssh -v -C -R 2233:localhost:5566 root@A的IP地址 -p A的ssh端口号
总之，port:host:hostport 这三个参数，是按照，实际操作中，谁是代理服务器，来进行区分配置的。
第三部分 其他类型的转发
动态转发实例分析
恩，动态转发，听上去很酷。当你看到这里时，有没有想过我们已经讨论过了本地转发，远程转发，但是前提都是要求有一个固定的应用服务端的端口号，例如前面例子中的 主机C 的 5566 端口。那如果没有这个端口号怎么办？等等，什么样的应用会没有这个端口号呢？嗯，比如说用浏览器进行 Web 浏览，比如说 MSN 等等。
当我们在一个不安全的 WiFi 环境下上网，用 SSH 动态转发来保护我们的网页浏览及 MSN 信息无疑是十分必要的。让我们先来看一下动态转发的命令格式：
|
1
|
$ ssh -D <local port> <SSH Server> |
例如：
|
1
|
$ ssh -D 7001 <SSH Server> |
图 5. 动态端口转发
似乎很简单，我们选择了 7001 作为本地的端口号，其实在这里 SSH 是创建了一个 SOCKS 代理服务。来看看帮助文档中对 -D 参数的描述：
|
1
2
3
4
5
6
7
8
9
|
-D port This works by allocating a socket to listen to port on the local side, and whenever a connection is made to this port, the con- nection is forwarded over the secure channel, and the applica- tion protocol is then used to determine where to connect to from the remote machine. Currently the SOCKS4 and SOCKS5 protocols are supported, and ssh will act as a SOCKS server. Only root can forward privileged ports. Dynamic port forwardings can also be specified in the configuration file. |
之后的使用就简单了，我们可以直接使用 localhost:7001 来作为正常的 SOCKS 代理来使用，直接在浏览器或 MSN 上设置即可。在 SSH Client 端无法访问的网站现在也都可以正常浏览。而这里需要值得注意的是，此时 SSH 所包护的范围只包括从浏览器端（SSH Client 端）到 SSH Server 端的连接，并不包含从 SSH Server 端 到目标网站的连接。如果后半截连接的安全不能得到充分的保证的话，这种方式仍不是合适的解决方案。
X 协议转发实例分析
好了，让我们来看最后一个例子 – X 协议转发。
我们日常工作当中，可能会经常会远程登录到 Linux/Unix/Solaris/HP 等机器上去做一些开发或者维护，也经常需要以 GUI 方式运行一些程序，比如要求图形化界面来安装 DB2/WebSphere 等等。这时候通常有两种选择来实现：VNC 或者 X 窗口，让我们来看看后者。
使用 X 窗口通常需要分别安装：X Client 和 X Server 。在本例中我们的 X Client 就是所访问的远程 Linux/Unix/Solaris/HP，而我们的 X Server 则是发起访问的本地机器（例如你面前正在使用的笔记本或台式机）。把 X Client 端的 X 窗口显示在 X Server 端需要先行在 X Client 端指定 X Server 的位置，命令格式如下：
|
1
|
export DISPLAY=<X Server IP>:<display #>.<virtual #> |
例如：
|
1
|
export DISPLAY=myDesktop:1.0 |
然后直接运行 X 应用即可，X 窗口就会自动在我们的本地端打开。
一切运行正常，但是，这时候 IT 部门突然在远程 Linux/Unix/Solaris/HP 前面加了一道防火墙。非常不幸的是，X 协议并不在允许通过的列表之内。怎么办？只能使用 VNC 了么？不，其实只要使用了 SSH 端口转发即可通过，同时也对 X 通讯数据做了加密，真是一举两得。（当然，使用此方法前最好先咨询相关 IT 部门是否符合相应的安全条例，以免造成违规操作。）
建立命令也很简单，直接从本地机器（X Server 端）发起一个如下的 SSH 连接即可：
|
1
|
$ ssh -X <SSH Server> |
图 5. X 转发
建立连接之后就可以直接运行远程的 X 应用。注意建立 X 转发之后会自动设置 DISPLAY 环境变量，通常会被设置成localhost:10.0，我们无需也不应该在连接之后再进行修改此环境变量。
一个比较常见的场景是，我们的本地机器是 Windows 操作系统，这时可以选择开源的 XMing 来作为我们的 XServer，而 SSH Client 则可以任意选择了，例如 PuTTY，Cygwin 均可以配置 访问 SSH 的同时建立 X 转发。
第四部分 总结
至此，我们已经完成了本地端口转发，远程端口转发，动态端口转发以及 X 转发的介绍。回顾起来，总的思路是通过将 TCP 连接转发到 SSH 通道上以解决数据加密以及突破防火墙的种种限制。对一些已知端口号的应用，例如 Telnet/LDAP/SMTP，我们可以使用本地端口转发或者远程端口转发来达到目的。动态端口转发则可以实现 SOCKS 代理从而加密以及突破防火墙对 Web 浏览的限制。对于 X 应用，无疑是 X 转发最为适用了。虽然每一部分我们都只是简单的介绍了一下，但如果能灵活应用这些技巧，相信对我们的日常生活 / 工作也是会有所帮助的。
SSH-设置代理服务器
简单设置SSH代理：
如果 由于网络和谐，SSH 无法连接到远程服务器(time out 神马的)，可以设置代理服务器。
找到ssh的配置文件。(可能需要自己手动创建txt文件，文件全名:config)
socket 代理 软件 配置
可复制以下代码到文件 ~/.ssh/config
Host * ProxyCommand=nc -X 5 -x localhost:1086 %h %p
SSH设置代理详解：
配置: ProxyCommand ，总得来说代理 方式 大致可分为两种。 参数 %h 指最终目标主机 %p 指最终目标主机端口
一、在客户端主机 和 中间人主机 上面 建立起 SSH隧道，然后通过操作中间人主机 通过SSH 远程登录目标主机。
举例：
+-------+ +----------+ +-----------+
| Laptop| <---> | Jumphost | <--> | FooServer |
+-------+ +----------+ +-----------+
OR
+-------+ +----------+ +-----------+
| Laptop| <---> | Firewall | <--> | FooServer |
+-------+ +----------+ +-----------+
192.168.1.5 121.1.2.3 10.10.29.68
直接尝试 连续登录 两个服务器。
I can can only access a remote server named ‘FooServer’ via ssh by first login into an intermediary server called ‘Jumphost’.
First, login to Jumphost:
$ ssh vivek@Jumphost
Next, I must ssh through the intermediary system as follows:
$ ssh vivek@FooServer
Passing through a gateway or two
Instead of typing two ssh command, I can type the following all-in-one command. This is useful for connecting to FooServer via firewall called ‘Jumphost’ as the jump host:
$ ssh -tt Jumphost ssh -tt FooServer $ ssh -tt vivek@Jumphost ssh -tt vivek@FooServer # 下面这句 command1 代表的是 登录终端服务器后，就直接进行的 shell 命令 command1 $ ssh -tt vivek@Jumphost ssh -tt vivek@FooServer command1 arg1 arg2 # Run htop over ssh via single command # ssh [email protected] 'htop' # Error opening terminal: unknown. # Use the -t flag with SSH; test OK ! # This will force a TTY allocation (ssh doesn't allocate a TTY if it's not necessary, normally only for interactive shells). # ssh [email protected] -t 'htop' $ ssh -tt vivek@Jumphost ssh -tt vivek@FooServer htop $ ssh -tt vivek@Jumphost ssh -tt vivek@FooServer screen -dR
-t option passed to the ssh command force pseudo-tty allocation. This can be used to execute arbitrary screen-based programs on a remote machine. Multiple -tt options force tty allocation, even if ssh has no local tty. -t 强制分配伪终端. 可以在远程机器上执行任何全屏幕(screen-based)程序, 所以非常有用, 例如菜单服务. 并联的 -t 选项强制分配终端, 即使 没有本地终端.
更好的办法是 调用 命令 ProxyCommand
$ ssh -o ProxyCommand='ssh vivek@Jumphost nc FooServer 22' vivek@FooServer ########################################## ## -t option is needed to run commands ### ########################################## $ ssh -t -o ProxyCommand='ssh vivek@Jumphost nc FooServer 22' vivek@FooServer htop
The netcat (nc) command is needed to set and establish a TCP pipe between Jumphost (or firewall) and FooServer. Now, my laptop (local system) is connected to Jumphost it now connected FooServer. In this example, the utility netcat (nc) is for reading and writing network connections directly. It can be used to pass connections to a 2nd server such as FooServer.
或者使用 配置文件
# Edit the $HOME/.ssh/config file using a text editor such as vim, enter: $ vim ~/.ssh/config
# Append the following configuration: Host fooserver #（随便取一个[昵称名] , 用户 客户端 直接 ssh [昵称名]） HostName FooServer #(远程目标主机) User vivek #（远程目标主机登入用户名） ProxyCommand ssh vivek@Jumphost nc %h %p
Save and close the file. Where,
1.Host fooserver : Set nickname of your choice.
2.HostName FooServer : Set the real remote server/host name.
3.User vivek : Set the real user name for remote server/host.
4.ProxyCommand ssh vivek@Jumphost nc %h %p : Specifies the command to use to connect to the server. In this example, I’m using nc command. Any occurrence of %h will be substituted by the host name to connect, %p by the port, and %r by the remote user name.
To test enter:
$ ssh fooserver
To see the details, pass the -v option to the ssh command. Here is another snippet:
Host server1 HostName v.server1 User root Port 22 ProxyCommand ssh [email protected] nc %h %p %r
Now, run:
$ ssh -v server1
Sample outputs:
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011 debug1: Reading configuration data /Users/veryv/.ssh/config debug1: /Users/veryv/.ssh/config line 1: Applying options for server1 debug1: Reading configuration data /etc/ssh_config debug1: /etc/ssh_config line 20: Applying options for * debug1: /etc/ssh_config line 102: Applying options for * debug1: Executing proxy command: exec ssh [email protected] nc v.server1 22 root ................
On the outside (ssh -W uses a special channel rather than using a normal session channel), it is equivalent to ssh’ing to the ssh_jump_host and calling netcat:
# 下面的两条命令 其实是 差不多的 ，只是 -W 建立的隧道不是普通的 SSH 隧道罢了 ProxyCommand ssh ssh_jump_host "nc %h %p" ProxyCommand ssh -W %h:%p ssh_jump_host
其他补充：
ProxyCommand 选项值形式为
ssh -W C:CPort -l USER -i PRIVATE_KEY -p BPort B
原理：ssh命令自提供的代理机制，在机器A上 建立与B的SSH连接
（使用”-l USER -i PRIVATE_KEY -p BPort B”这些参数）
该SSH连接的B端侧与机器C上的SSH Server端口（即“C:CPort”）建立连接，
该SSH连接的A端侧与机器A上的SSH Client
（即“最终欲建立‘间接SSH连接’在机器A上的SSH Client”）建立连接。
假定A上ssh_config配置文件内容如下：
Host B
HostName %h
User dsl
Port 1046
IdentityFile ~/.ssh/id_dsa
Host C
HostName %h
User dsl
Port 1046
IdentityFile ~/.ssh/id_rsa
ProxyCommand ssh -W %h:%p B
在A上执行ssh C命令，发现A与C成功建立SSH连接。根据以上所述，此时在A上应该有两个SSH进程，一个对应于“A与B的SSH连接”，另外一个对应于“A与C的SSH连接”。在A上执行ps -ef | grep ‘ssh’命令，得到如下结果，得证。
7851 7689 15:55 S pts/10 ssh C 7852 7851 15:55 S pts/10 ssh -W C:1046 B
二、利用外界现有的代理服务器。
“ProxyCommand”选项值形式为“nc -X 5 -x B:BPort C CPort”，
原理：利用“nc”命令，在机器A上使用“nc”命令与代理服务器
（即“-x B:BPort”，通过“-X 5”参数来指定与代理服务器的通信协议为“SOCKS4/SOCKS5/HTTPS”）建立代理连接，
该代理服务器连接的B端侧与机器C上的SSH Server端口（即“C CPort”）建立连接，
该代理服务器连接的A端侧与机器A上的SSH Client
（即“最终欲建立‘间接SSH连接’在机器A上的SSH Client”）建立连接。
假定A上ssh_config配置文件内容如下：
Host C
HostName %h
User dsl
Port 1046
IdentityFile ~/.ssh/id_rsa
ProxyCommand nc -X 5 -x B:8989 %h %p
在A上执行ssh C命令，发现A与C成功建立SSH连接。根据以上所述，此时在A上应该有一个NC进程和一个SSH进程，前者对应于“A与B的代理连接”，后者对应于“A与C的SSH连接”。在A上执行ps -ef | grep -e ‘ssh’ -e ‘nc’命令，得到如下结果，得证。
8816 8089 16:08 S pts/10 ssh C 8817 8816 16:08 S pts/10 nc -X 5 -x B:8989 C 1046
ProxyCommand -X 参数含义 -x 参数含义 :
-X proxy_protocol Requests that nc should use the specified protocol when talking to the proxy server. Supported protocols are “4” (SOCKS v.4), “5” (SOCKS v.5) and “connect” (HTTPS proxy). If the protocol is not specified, SOCKS version 5 is used. -x proxy_address[:port] Requests that nc should connect to destination using a proxy at proxy_address and port. If port is not specified, the well-known port for the proxy protocol is used (1080 for SOCKS, 3128 for HTTPS). An IPv6 address can be specified unambiguously by enclosing proxy_address in square brackets.
补充：关于SSH配置的问题：
ssh_config(5)
~/.ssh/config This is the per-user configuration file. The file format and configuration options are described in ssh_config(5). Because of the potential for abuse, this file must have strict permissions: read/write for the user, and not writable by others. /etc/ssh/ssh_config Systemwide configuration file. The file format and configuration options are described in ssh_config(5).
SSH-只用密钥登录
补充更新：
centos更新openssh后不再支持ssh 第一版协议，所以第一版协议的配置信息也不需要了。
#这些配置信息都属于第一版协议，现在已经不需要了。 RSAAuthentication yes #指定公钥数据库文件 AuthorsizedKeysFile .ssh/authorized_keys
提示：
密钥会生成两个文件 [私钥 (id_rsa) 与公钥 (id_rsa.pub)] ，建议设置并牢记passphrase密码短语。
Linux：
ssh-keygen -t rsa
Windows：SecurCRT/Xshell/PuTTY
SSH-2 RSA 2048
一、创建密钥
#生成SSH密钥对 ssh-keygen -t rsa Generating public/private rsa key pair. #建议直接回车使用默认路径 Enter file in which to save the key (/root/.ssh/id_rsa): #输入密码短语（留空则直接回车） Enter passphrase (empty for no passphrase): #重复密码短语 Enter same passphrase again: Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: aa:8b:61:13:38:ad:b5:49:ca:51:45:b9:77:e1:97:e1 [email protected] The key's randomart image is: +--[ RSA 2048]----+ | .o. | | .. . . | | . . . o o | | o. . . o E | |o.= . S . | |.*.+ . | |o.* . | | . + . | | . o. | +-----------------+
二、复制密钥对
#复制公钥到无密码登录的服务器上,22端口改变可以使用下面的命令
#ssh-copy-id -i ~/.ssh/id_rsa.pub “-p 10022 user@server”
ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]
或者也可以手动在服务器端建立目录和authorized_keys，注意修改权限。
也或者, you can paste in the keys using SSH （下面是一行命令）
cat ~/.ssh/id_rsa.pub | ssh [email protected] "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
No matter which command you chose, you should see something like:
The authenticity of host ‘12.34.56.78 (12.34.56.78)’ can’t be established.
RSA key fingerprint is b1:2d:33:67:ce:35:4d:5f:f3:a8:cd:c0:c4:48:86:12.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘12.34.56.78’ (RSA) to the list of known hosts.
[email protected]’s password:
Now try logging into the machine, with “ssh ‘[email protected]′”, and check in:
~/.ssh/authorized_keys
to make sure we haven’t added extra keys that you weren’t expecting.
三、修改SSH配置文件 （测试效果 成功）
提示:
1、RSAAuthentication yes;这个配置好像没有了
2、PermitRootLogin yes; 表示 root 用户 可以 通过 SSH 登录：不是一定要修改的。
#编辑sshd_config文件 vim /etc/ssh/sshd_config #禁用密码验证 PasswordAuthentication no #启用密钥验证 RSAAuthentication yes PubkeyAuthentication yes #指定公钥数据库文件 AuthorsizedKeysFile .ssh/authorized_keys
其实可以直接用命令行 来修改 ssh 的配置值。
sed -i "s/^PasswordAuthentication.*/PasswordAuthentication no/g" /etc/ssh/sshd_config sed -i "s/^#RSAAuthentication.*/RSAAuthentication yes/g" /etc/ssh/sshd_config sed -i "s/^#PubkeyAuthentication.*/PubkeyAuthentication yes/g" /etc/ssh/sshd_config sed -i "s/^#AuthorizedKeysFile.*/AuthorizedKeysFile .ssh\/authorized_keys/g" /etc/ssh/sshd_config
SSH-修改服务器默认端口
centos 下：
首先修改配置文件 vim /etc/ssh/sshd_config
(注意 网页 复制代码的 时候 vim和/etc中间的 空格有问题，导致shell 终端 无法识别 vim空格 命令)
重新总结一下：
step1 修改/etc/ssh/sshd_config
vi /etc/ssh/sshd_config
#Port 22 //这行去掉#号
Port 20000 //下面添加这一行
step2 修改SELinux
（这一步 centos 好像 不需要啊，有些版本好像还是需要的）
另外需要注意一点就是，如果selinux没有关闭，那么端口会绑定失败， 使用 systemctl status sshd.service 命令查看状态时 会发现error: Bind to port 2223 on 0.0.0.0 failed: Permission denied,的错误， 这种情况改下，要关闭selinux，然后再次重新启动ssh服务，新的端口才可以生效
如果忽略这一步，发现端口修改无效，可以看看systemctl status sshd.service
semanage 命令如果找不到，
-bash: semanage: command not found
就先查找，哪个软件提供这条命令
yum provides /usr/sbin/semanage # 也可以用 下面这条命令 yum whatprovides /usr/sbin/semanage
可能输出：
Loaded plugins: fastestmirror Determining fastest mirrors * base: mirror.nbrc.ac.in * extras: mirror.nbrc.ac.in * updates: mirror.nbrc.ac.in policycoreutils-python-2.2.5-11.el7.x86_64 : SELinux policy core python : utilities Repo : base Matched from: Filename : /usr/sbin/semanage policycoreutils-python-2.2.5-11.el7_0.1.x86_64 : SELinux policy core python : utilities Repo : updates Matched from: Filename : /usr/sbin/semanage
As you see in the above output, we need to install the package policycoreutils-python-2.2.5-11.el7_0.1.x86_64 in order to use ‘semanage’ command.
so, let us install policycoreutils-python-2.2.5-11.el7_0.1.x86_64 package using command:
yum install policycoreutils-python
使用以下命令查看当前SElinux 允许的ssh端口：
semanage port -l | grep ssh
添加20000端口到 SELinux
semanage port -a -t ssh_port_t -p tcp 20000
然后确认一下是否添加进去
semanage port -l | grep ssh
如果成功会输出
ssh_port_t tcp 20000, 22
step3 重启ssh
systemctl restart sshd.service
step4 配置防火墙端口号
centos7 防火墙 改成了 firewalld 替换 原来的 iptable 了。
firewall-cmd --permanent --add-port=12588/tcp (ssh改用的端口号) firewall-cmd --reload（重新加载防火墙配置） 因为 ssh 默认端口改了 所以 开放 ssh 使用 的端口吧 (结果没有用) firewall-cmd --permanent --zone=public --add-service ssh
课外补充: 使用 防火墙 屏蔽 ip 地址
firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='128.128.128.128' reject"
参考：
https://www.cnblogs.com/freeweb/p/5667166.html
Linux Troubleshooting – semanage command not found in CentOS 7/RHEL 7
SSH-远程连接入门
quick start（快速上手）：
查看SSH服务是否开启
[root@localhost ~]# sudo ps -e | grep ssh 1128 ? 00:00:00 sshd [root@localhost ~]#
如果没有反应或者其他结果，再试着开启SSH服务。
使用命令 sudo /etc/init.d/ssh start来开启服务
如果没有安装SSH服务，此时需要安装 SSH服务。
yum install openssh-server -y
启动sshd服务
如果没有启动，则需要启动该服务： systemctl start sshd.service 其实.service可不写，直接 systemctl restart sshd 重启 sshd 服务： systemctl restart sshd.service 设置服务开启自启： systemctl enable sshd.service
使用ssh
### -p 后面是端口号 | 再后面是 用户名@服务器地址 | -v 是 输出连接信息，方便查找连接失败原因 ssh -p 22 [email protected] -v
详情介绍：
mac下利用 终端 Terminal ，调用 shell 的新建远程 连接 方法，进行 SSH 连接。
普通连接方式:
直接用 ssh 登录 远程服务器
# root是远程服务器的默认管理员账户，所以用root登录，登录完成后，可以分配其他用户账号。 # 128.128.128.128 是远程 服务器ip地址 # -p 是指定 远程ssh服务器 端口后，默认22端口，如果 不是22 端口 需要设置 -p 参数 # -v 是打印 ssh 运行过程中的 日志文件，方便发现错误，可以不设置 ssh [email protected] -p 12880 -v
也可以参看：
https://www.cnblogs.com/ftl1012/p/ssh.html
https://www.cnblogs.com/jiarenanhao/p/9938280.html
NAME
ssh — OpenSSH SSH client (remote login program)
SYNOPSIS
| ssh | [-46AaCfGgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec] [-D[bind_address:]port] [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11] [-iidentity_file] [-J destination] [-L address] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-ooption] [-p port] [-Q query_option] [-R address] [-S ctl_path] [-W host:port] [-wlocal_tun[:remote_tun]] destination [command] |
DESCRIPTION
ssh (SSH client) is a program for logging into a remote machine and for executing commands on a remote machine. It is intended to provide secure encrypted communications between two untrusted hosts over an insecure network. X11 connections, arbitrary TCP ports and UNIX-domain sockets can also be forwarded over the secure channel.
ssh connects and logs into the specified destination, which may be specified as either [user@]hostname or a URI of the form ssh:// [user@]hostname[:port]. The user must prove his/her identity to the remote machine using one of several methods (see below).
If a command is specified, it is executed on the remote host instead of a login shell.
The options are as follows:
- -4
- Forces ssh to use IPv4 addresses only.
- -6
- Forces ssh to use IPv6 addresses only.
- -A
- Enables forwarding of the authentication agent connection. This can also be specified on a per-host basis in a configuration file.
Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent’s UNIX-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.
- -a
- Disables forwarding of the authentication agent connection.
- -b bind_address
- Use bind_address on the local machine as the source address of the connection. Only useful on systems with more than one address.
- -C
- Requests compression of all data (including stdin, stdout, stderr, and data for forwarded X11, TCP and UNIX-domain connections). The compression algorithm is the same used by gzip(1). Compression is desirable on modem lines and other slow connections, but will only slow down things on fast networks. The default value can be set on a host-by-host basis in the configuration files; see theCompression option.
- -c cipher_spec
- Selects the cipher specification for encrypting the session. cipher_spec is a comma-separated list of ciphers listed in order of preference. See the Cipherskeyword in ssh_config(5) for more information.
- -D [bind_address:]port
- Specifies a local “dynamic” application-level port forwarding. This works by allocating a socket to listen to port on the local side, optionally bound to the specified bind_address. Whenever a connection is made to this port, the connection is forwarded over the secure channel, and the application protocol is then used to determine where to connect to from the remote machine. Currently the SOCKS4 and SOCKS5 protocols are supported, and ssh will act as a SOCKS server. Only root can forward privileged ports. Dynamic port forwardings can also be specified in the configuration file.
IPv6 addresses can be specified by enclosing the address in square brackets. Only the superuser can forward privileged ports. By default, the local port is bound in accordance with the GatewayPorts setting. However, an explicitbind_address may be used to bind the connection to a specific address. Thebind_address of “localhost” indicates that the listening port be bound for local use only, while an empty address or ‘*’ indicates that the port should be available from all interfaces.
- -E log_file
- Append debug logs to log_file instead of standard error.
- -e escape_char
- Sets the escape character for sessions with a pty (default: ‘
~’). The escape character is only recognized at the beginning of a line. The escape character followed by a dot (‘.’) closes the connection; followed by control-Z suspends the connection; and followed by itself sends the escape character once. Setting the character to “none” disables any escapes and makes the session fully transparent. - -F configfile
- Specifies an alternative per-user configuration file. If a configuration file is given on the command line, the system-wide configuration file (/etc/ssh/ssh_config) will be ignored. The default for the per-user configuration file is ~/.ssh/config.
- -f
- Requests ssh to go to background just before command execution. This is useful if ssh is going to ask for passwords or passphrases, but the user wants it in the background. This implies -n. The recommended way to start X11 programs at a remote site is with something like ssh -f host xterm.
If the ExitOnForwardFailure configuration option is set to “yes”, then a client started with -f will wait for all remote port forwards to be successfully established before placing itself in the background.
- -G
- Causes ssh to print its configuration after evaluating Host and Match blocks and exit.
- -g
- Allows remote hosts to connect to local forwarded ports. If used on a multiplexed connection, then this option must be specified on the master process.
- -I pkcs11
- Specify the PKCS#11 shared library ssh should use to communicate with a PKCS#11 token providing the user’s private RSA key.
- -i identity_file
- Selects a file from which the identity (private key) for public key authentication is read. The default is ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and~/.ssh/id_rsa. Identity files may also be specified on a per-host basis in the configuration file. It is possible to have multiple -i options (and multiple identities specified in configuration files). If no certificates have been explicitly specified by the CertificateFile directive, ssh will also try to load certificate information from the filename obtained by appending -cert.pub to identity filenames.
- -J destination
- Connect to the target host by first making a ssh connection to the jump host described by destination and then establishing a TCP forwarding to the ultimate destination from there. Multiple jump hops may be specified separated by comma characters. This is a shortcut to specify a ProxyJump configuration directive.
- -K
- Enables GSSAPI-based authentication and forwarding (delegation) of GSSAPI credentials to the server.
- -k
- Disables forwarding (delegation) of GSSAPI credentials to the server.
- -L [bind_address:]port:host:hostport
- -L [bind_address:]port:remote_socket
- -L local_socket:host:hostport
- -L local_socket:remote_socket
- Specifies that connections to the given TCP port or Unix socket on the local (client) host are to be forwarded to the given host and port, or Unix socket, on the remote side. This works by allocating a socket to listen to either a TCP port on the local side, optionally bound to the specified bind_address, or to a Unix socket. Whenever a connection is made to the local port or socket, the connection is forwarded over the secure channel, and a connection is made to either host port hostport, or the Unix socket remote_socket, from the remote machine.
Port forwardings can also be specified in the configuration file. Only the superuser can forward privileged ports. IPv6 addresses can be specified by enclosing the address in square brackets.
By default, the local port is bound in accordance with the GatewayPorts setting. However, an explicit bind_address may be used to bind the connection to a specific address. The bind_address of “localhost” indicates that the listening port be bound for local use only, while an empty address or ‘*’ indicates that the port should be available from all interfaces.
- -l login_name
- Specifies the user to log in as on the remote machine. This also may be specified on a per-host basis in the configuration file.
- -M
- Places the ssh client into “master” mode for connection sharing. Multiple -Moptions places ssh into “master” mode with confirmation required before slave connections are accepted. Refer to the description of ControlMaster inssh_config(5) for details.
- -m mac_spec
- A comma-separated list of MAC (message authentication code) algorithms, specified in order of preference. See the MACs keyword for more information.
- -N
- Do not execute a remote command. This is useful for just forwarding ports.
- -n
- Redirects stdin from /dev/null (actually, prevents reading from stdin). This must be used when ssh is run in the background. A common trick is to use this to run X11 programs on a remote machine. For example, ssh -n shadows.cs.hut.fi emacs & will start an emacs on shadows.cs.hut.fi, and the X11 connection will be automatically forwarded over an encrypted channel. The ssh program will be put in the background. (This does not work if ssh needs to ask for a password or passphrase; see also the -f option.)
- -O ctl_cmd
- Control an active connection multiplexing master process. When the -O option is specified, the ctl_cmd argument is interpreted and passed to the master process. Valid commands are: “check” (check that the master process is running), “forward” (request forwardings without command execution), “cancel” (cancel forwardings), “exit” (request the master to exit), and “stop” (request the master to stop accepting further multiplexing requests).
- -o option
- Can be used to give options in the format used in the configuration file. This is useful for specifying options for which there is no separate command-line flag. For full details of the options listed below, and their possible values, seessh_config(5).
AddKeysToAgent AddressFamily BatchMode BindAddress CanonicalDomains CanonicalizeFallbackLocal CanonicalizeHostname CanonicalizeMaxDots CanonicalizePermittedCNAMEs CertificateFile ChallengeResponseAuthentication CheckHostIP Ciphers ClearAllForwardings Compression ConnectionAttempts ConnectTimeout ControlMaster ControlPath ControlPersist DynamicForward EscapeChar ExitOnForwardFailure FingerprintHash ForwardAgent ForwardX11 ForwardX11Timeout ForwardX11Trusted GatewayPorts GlobalKnownHostsFile GSSAPIAuthentication GSSAPIDelegateCredentials HashKnownHosts Host HostbasedAuthentication HostbasedKeyTypes HostKeyAlgorithms HostKeyAlias HostName IdentitiesOnly IdentityAgent IdentityFile Include IPQoS KbdInteractiveAuthentication KbdInteractiveDevices KexAlgorithms LocalCommand LocalForward LogLevel MACs Match NoHostAuthenticationForLocalhost NumberOfPasswordPrompts PasswordAuthentication PermitLocalCommand PKCS11Provider Port PreferredAuthentications ProxyCommand ProxyJump ProxyUseFdpass PubkeyAcceptedKeyTypes PubkeyAuthentication RekeyLimit RemoteCommand RemoteForward RequestTTY SendEnv ServerAliveInterval ServerAliveCountMax StreamLocalBindMask StreamLocalBindUnlink StrictHostKeyChecking TCPKeepAlive Tunnel TunnelDevice UpdateHostKeys UsePrivilegedPort User UserKnownHostsFile VerifyHostKeyDNS VisualHostKey XAuthLocation
- -p port
- Port to connect to on the remote host. This can be specified on a per-host basis in the configuration file.
- -Q query_option
- Queries ssh for the algorithms supported for the specified version 2. The available features are: cipher (supported symmetric ciphers), cipher-auth(supported symmetric ciphers that support authenticated encryption), mac(supported message integrity codes), kex (key exchange algorithms), key (key types), key-cert (certificate key types), key-plain (non-certificate key types), and protocol-version (supported SSH protocol versions).
- -q
- Quiet mode. Causes most warning and diagnostic messages to be suppressed.
- -R [bind_address:]port:host:hostport
- -R [bind_address:]port:local_socket
- -R remote_socket:host:hostport
- -R remote_socket:local_socket
- -R [bind_address:]port
- Specifies that connections to the given TCP port or Unix socket on the remote (server) host are to be forwarded to the local side.
This works by allocating a socket to listen to either a TCP port or to a Unix socket on the remote side. Whenever a connection is made to this port or Unix socket, the connection is forwarded over the secure channel, and a connection is made from the local machine to either an explicit destination specified by host porthostport, or local_socket, or, if no explicit destination was specified, ssh will act as a SOCKS 4/5 proxy and forward connections to the destinations requested by the remote SOCKS client.
Port forwardings can also be specified in the configuration file. Privileged ports can be forwarded only when logging in as root on the remote machine. IPv6 addresses can be specified by enclosing the address in square brackets.
By default, TCP listening sockets on the server will be bound to the loopback interface only. This may be overridden by specifying a bind_address. An emptybind_address, or the address ‘
*’, indicates that the remote socket should listen on all interfaces. Specifying a remote bind_address will only succeed if the server’s GatewayPorts option is enabled (see sshd_config(5)).If the port argument is ‘
0’, the listen port will be dynamically allocated on the server and reported to the client at run time. When used together with -O forward the allocated port will be printed to the standard output. - -S ctl_path
- Specifies the location of a control socket for connection sharing, or the string “none” to disable connection sharing. Refer to the description of ControlPathand ControlMaster in ssh_config(5) for details.
- -s
- May be used to request invocation of a subsystem on the remote system. Subsystems facilitate the use of SSH as a secure transport for other applications (e.g. sftp(1)). The subsystem is specified as the remote command.
- -T
- Disable pseudo-terminal allocation.
- -t
- Force pseudo-terminal allocation. This can be used to execute arbitrary screen-based programs on a remote machine, which can be very useful, e.g. when implementing menu services. Multiple -t options force tty allocation, even if sshhas no local tty.
- -V
- Display the version number and exit.
- -v
- Verbose mode. Causes ssh to print debugging messages about its progress. This is helpful in debugging connection, authentication, and configuration problems. Multiple -v options increase the verbosity. The maximum is 3.
- -W host:port
- Requests that standard input and output on the client be forwarded to host onport over the secure channel. Implies -N, -T, ExitOnForwardFailure andClearAllForwardings, though these can be overridden in the configuration file or using -o command line options.
- -w local_tun[:remote_tun]
- Requests tunnel device forwarding with the specified tun(4) devices between the client (local_tun) and the server (remote_tun).
The devices may be specified by numerical ID or the keyword “any”, which uses the next available tunnel device. If remote_tun is not specified, it defaults to “any”. See also the Tunnel and TunnelDevice directives in ssh_config(5). If theTunnel directive is unset, it is set to the default tunnel mode, which is “point-to-point”.
- -X
- Enables X11 forwarding. This can also be specified on a per-host basis in a configuration file.
X11 forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the user’s X authorization database) can access the local X11 display through the forwarded connection. An attacker may then be able to perform activities such as keystroke monitoring.
For this reason, X11 forwarding is subjected to X11 SECURITY extension restrictions by default. Please refer to the ssh -Y option and the ForwardX11Trusted directive in ssh_config(5) for more information.
- -x
- Disables X11 forwarding.
- -Y
- Enables trusted X11 forwarding. Trusted X11 forwardings are not subjected to the X11 SECURITY extension controls.
- -y
- Send log information using the syslog(3) system module. By default this information is sent to stderr.
ssh may additionally obtain configuration data from a per-user configuration file and a system-wide configuration file. The file format and configuration options are described inssh_config(5).
AUTHENTICATION
The OpenSSH SSH client supports SSH protocol 2.
The methods available for authentication are: GSSAPI-based authentication, host-based authentication, public key authentication, challenge-response authentication, and password authentication. Authentication methods are tried in the order specified above, thoughPreferredAuthentications can be used to change the default order.
Host-based authentication works as follows: If the machine the user logs in from is listed in /etc/hosts.equiv or /etc/shosts.equiv on the remote machine, and the user names are the same on both sides, or if the files ~/.rhosts or ~/.shosts exist in the user’s home directory on the remote machine and contain a line containing the name of the client machine and the name of the user on that machine, the user is considered for login. Additionally, the server must be able to verify the client’s host key (see the description of /etc/ssh/ssh_known_hostsand ~/.ssh/known_hosts, below) for login to be permitted. This authentication method closes security holes due to IP spoofing, DNS spoofing, and routing spoofing. [Note to the administrator: /etc/hosts.equiv, ~/.rhosts, and the rlogin/rsh protocol in general, are inherently insecure and should be disabled if security is desired.]
Public key authentication works as follows: The scheme is based on public-key cryptography, using cryptosystems where encryption and decryption are done using separate keys, and it is unfeasible to derive the decryption key from the encryption key. The idea is that each user creates a public/private key pair for authentication purposes. The server knows the public key, and only the user knows the private key. ssh implements public key authentication protocol automatically, using one of the DSA, ECDSA, Ed25519 or RSA algorithms. The HISTORY section of ssl(8) contains a brief discussion of the DSA and RSA algorithms.
The file ~/.ssh/authorized_keys lists the public keys that are permitted for logging in. When the user logs in, the ssh program tells the server which key pair it would like to use for authentication. The client proves that it has access to the private key and the server checks that the corresponding public key is authorized to accept the account.
The server may inform the client of errors that prevented public key authentication from succeeding after authentication completes using a different method. These may be viewed by increasing the LogLevel to DEBUG or higher (e.g. by using the -v flag).
The user creates his/her key pair by running ssh-keygen(1). This stores the private key in ~/.ssh/id_dsa (DSA), ~/.ssh/id_ecdsa (ECDSA), ~/.ssh/id_ed25519 (Ed25519), or~/.ssh/id_rsa (RSA) and stores the public key in ~/.ssh/id_dsa.pub (DSA),~/.ssh/id_ecdsa.pub (ECDSA), ~/.ssh/id_ed25519.pub (Ed25519), or ~/.ssh/id_rsa.pub(RSA) in the user’s home directory. The user should then copy the public key to~/.ssh/authorized_keys in his/her home directory on the remote machine. The authorized_keys file corresponds to the conventional ~/.rhosts file, and has one key per line, though the lines can be very long. After this, the user can log in without giving the password.
A variation on public key authentication is available in the form of certificate authentication: instead of a set of public/private keys, signed certificates are used. This has the advantage that a single trusted certification authority can be used in place of many public/private keys. See the CERTIFICATES section of ssh-keygen(1) for more information.
The most convenient way to use public key or certificate authentication may be with an authentication agent. See ssh-agent(1) and (optionally) the AddKeysToAgent directive inssh_config(5) for more information.
Challenge-response authentication works as follows: The server sends an arbitrary “challenge” text, and prompts for a response. Examples of challenge-response authentication include BSD Authentication (see login.conf(5)) and PAM (some non-OpenBSD systems).
Finally, if other authentication methods fail, ssh prompts the user for a password. The password is sent to the remote host for checking; however, since all communications are encrypted, the password cannot be seen by someone listening on the network.
ssh automatically maintains and checks a database containing identification for all hosts it has ever been used with. Host keys are stored in ~/.ssh/known_hosts in the user’s home directory. Additionally, the file /etc/ssh/ssh_known_hosts is automatically checked for known hosts. Any new hosts are automatically added to the user’s file. If a host’s identification ever changes, ssh warns about this and disables password authentication to prevent server spoofing or man-in-the-middle attacks, which could otherwise be used to circumvent the encryption. The StrictHostKeyChecking option can be used to control logins to machines whose host key is not known or has changed.
When the user’s identity has been accepted by the server, the server either executes the given command in a non-interactive session or, if no command has been specified, logs into the machine and gives the user a normal shell as an interactive session. All communication with the remote command or shell will be automatically encrypted.
If an interactive session is requested ssh by default will only request a pseudo-terminal (pty) for interactive sessions when the client has one. The flags -T and -t can be used to override this behaviour.
If a pseudo-terminal has been allocated the user may use the escape characters noted below.
If no pseudo-terminal has been allocated, the session is transparent and can be used to reliably transfer binary data. On most systems, setting the escape character to “none” will also make the session transparent even if a tty is used.
The session terminates when the command or shell on the remote machine exits and all X11 and TCP connections have been closed.
ESCAPE CHARACTERS
When a pseudo-terminal has been requested, ssh supports a number of functions through the use of an escape character.
A single tilde character can be sent as ~~ or by following the tilde by a character other than those described below. The escape character must always follow a newline to be interpreted as special. The escape character can be changed in configuration files using theEscapeChar configuration directive or on the command line by the -e option.
The supported escapes (assuming the default ‘~’) are:
- ~.
- Disconnect.
- ~^Z
- Background ssh.
- ~#
- List forwarded connections.
- ~&
- Background ssh at logout when waiting for forwarded connection / X11 sessions to terminate.
- ~?
- Display a list of escape characters.
- ~B
- Send a BREAK to the remote system (only useful if the peer supports it).
- ~C
- Open command line. Currently this allows the addition of port forwardings using the -L, -R and -D options (see above). It also allows the cancellation of existing port-forwardings with -KL[bind_address:]port for local, -KR[bind_address:]port for remote and -KD[bind_address:]port for dynamic port-forwardings. !commandallows the user to execute a local command if the PermitLocalCommand option is enabled in ssh_config(5). Basic help is available, using the -h option.
- ~R
- Request rekeying of the connection (only useful if the peer supports it).
- ~V
- Decrease the verbosity (LogLevel) when errors are being written to stderr.
- ~v
- Increase the verbosity (LogLevel) when errors are being written to stderr.
TCP FORWARDING
Forwarding of arbitrary TCP connections over the secure channel can be specified either on the command line or in a configuration file. One possible application of TCP forwarding is a secure connection to a mail server; another is going through firewalls.
In the example below, we look at encrypting communication between an IRC client and server, even though the IRC server does not directly support encrypted communications. This works as follows: the user connects to the remote host using ssh, specifying a port to be used to forward connections to the remote server. After that it is possible to start the service which is to be encrypted on the client machine, connecting to the same local port, and sshwill encrypt and forward the connection.
The following example tunnels an IRC session from client machine “127.0.0.1” (localhost) to remote server “server.example.com”:
$ ssh -f -L 1234:localhost:6667 server.example.com sleep 10 $ irc -c '#users' -p 1234 pinky 127.0.0.1
This tunnels a connection to IRC server “server.example.com”, joining channel “#users”, nickname “pinky”, using port 1234. It doesn’t matter which port is used, as long as it’s greater than 1023 (remember, only root can open sockets on privileged ports) and doesn’t conflict with any ports already in use. The connection is forwarded to port 6667 on the remote server, since that’s the standard port for IRC services.
The -f option backgrounds ssh and the remote command “sleep 10” is specified to allow an amount of time (10 seconds, in the example) to start the service which is to be tunnelled. If no connections are made within the time specified, ssh will exit.
X11 FORWARDING
If the ForwardX11 variable is set to “yes” (or see the description of the -X, -x, and -Y options above) and the user is using X11 (the DISPLAY environment variable is set), the connection to the X11 display is automatically forwarded to the remote side in such a way that any X11 programs started from the shell (or command) will go through the encrypted channel, and the connection to the real X server will be made from the local machine. The user should not manually set DISPLAY. Forwarding of X11 connections can be configured on the command line or in configuration files.
The DISPLAY value set by ssh will point to the server machine, but with a display number greater than zero. This is normal, and happens because ssh creates a “proxy” X server on the server machine for forwarding the connections over the encrypted channel.
ssh will also automatically set up Xauthority data on the server machine. For this purpose, it will generate a random authorization cookie, store it in Xauthority on the server, and verify that any forwarded connections carry this cookie and replace it by the real cookie when the connection is opened. The real authentication cookie is never sent to the server machine (and no cookies are sent in the plain).
If the ForwardAgent variable is set to “yes” (or see the description of the -A and -a options above) and the user is using an authentication agent, the connection to the agent is automatically forwarded to the remote side.
VERIFYING HOST KEYS
When connecting to a server for the first time, a fingerprint of the server’s public key is presented to the user (unless the option StrictHostKeyChecking has been disabled). Fingerprints can be determined using ssh-keygen(1):
$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_keyIf the fingerprint is already known, it can be matched and the key can be accepted or rejected. If only legacy (MD5) fingerprints for the server are available, the ssh-keygen(1) -Eoption may be used to downgrade the fingerprint algorithm to match.
Because of the difficulty of comparing host keys just by looking at fingerprint strings, there is also support to compare host keys visually, using random art. By setting the VisualHostKeyoption to “yes”, a small ASCII graphic gets displayed on every login to a server, no matter if the session itself is interactive or not. By learning the pattern a known server produces, a user can easily find out that the host key has changed when a completely different pattern is displayed. Because these patterns are not unambiguous however, a pattern that looks similar to the pattern remembered only gives a good probability that the host key is the same, not guaranteed proof.
To get a listing of the fingerprints along with their random art for all known hosts, the following command line can be used:
$ ssh-keygen -lv -f ~/.ssh/known_hostsIf the fingerprint is unknown, an alternative method of verification is available: SSH fingerprints verified by DNS. An additional resource record (RR), SSHFP, is added to a zonefile and the connecting client is able to match the fingerprint with that of the key presented.
In this example, we are connecting a client to a server, “host.example.com”. The SSHFP resource records should first be added to the zonefile for host.example.com:
$ ssh-keygen -r host.example.com.
The output lines will have to be added to the zonefile. To check that the zone is answering fingerprint queries:
$ dig -t SSHFP host.example.comFinally the client connects:
$ ssh -o "VerifyHostKeyDNS ask" host.example.com [...] Matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)?
See the VerifyHostKeyDNS option in ssh_config(5) for more information.
SSH-BASED VIRTUAL PRIVATE NETWORKS
ssh contains support for Virtual Private Network (VPN) tunnelling using the tun(4) network pseudo-device, allowing two networks to be joined securely. The sshd_config(5)configuration option PermitTunnel controls whether the server supports this, and at what level (layer 2 or 3 traffic).
The following example would connect client network 10.0.50.0/24 with remote network 10.0.99.0/24 using a point-to-point connection from 10.1.1.1 to 10.1.1.2, provided that the SSH server running on the gateway to the remote network, at 192.168.1.15, allows it.
On the client:
# ssh -f -w 0:1 192.168.1.15 true # ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252 # route add 10.0.99.0/24 10.1.1.2
On the server:
# ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252 # route add 10.0.50.0/24 10.1.1.1
Client access may be more finely tuned via the /root/.ssh/authorized_keys file (see below) and the PermitRootLogin server option. The following entry would permit connections ontun(4) device 1 from user “jane” and on tun device 2 from user “john”, if PermitRootLogin is set to “forced-commands-only”:
tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john
Since an SSH-based setup entails a fair amount of overhead, it may be more suited to temporary setups, such as for wireless VPNs. More permanent VPNs are better provided by tools such as ipsecctl(8) and isakmpd(8).
ENVIRONMENT
ssh will normally set the following environment variables:
DISPLAY- The
DISPLAYvariable indicates the location of the X11 server. It is automatically set by ssh to point to a value of the form “hostname:n”, where “hostname” indicates the host where the shell runs, and ‘n’ is an integer ≥ 1. ssh uses this special value to forward X11 connections over the secure channel. The user should normally not setDISPLAYexplicitly, as that will render the X11 connection insecure (and will require the user to manually copy any required authorization cookies). HOME- Set to the path of the user’s home directory.
LOGNAME- Synonym for
USER; set for compatibility with systems that use this variable. MAIL- Set to the path of the user’s mailbox.
PATH- Set to the default
PATH, as specified when compiling ssh. SSH_ASKPASS- If ssh needs a passphrase, it will read the passphrase from the current terminal if it was run from a terminal. If ssh does not have a terminal associated with it but
DISPLAYandSSH_ASKPASSare set, it will execute the program specified bySSH_ASKPASSand open an X11 window to read the passphrase. This is particularly useful when calling ssh from a .xsession or related script. (Note that on some machines it may be necessary to redirect the input from /dev/null to make this work.) SSH_AUTH_SOCK- Identifies the path of a UNIX-domain socket used to communicate with the agent.
SSH_CONNECTION- Identifies the client and server ends of the connection. The variable contains four space-separated values: client IP address, client port number, server IP address, and server port number.
SSH_ORIGINAL_COMMAND- This variable contains the original command line if a forced command is executed. It can be used to extract the original arguments.
SSH_TTY- This is set to the name of the tty (path to the device) associated with the current shell or command. If the current session has no tty, this variable is not set.
SSH_TUNNEL- Optionally set by sshd(8) to contain the interface names assigned if tunnel forwarding was requested by the client.
SSH_USER_AUTH- Optionally set by sshd(8), this variable may contain a pathname to a file that lists the authentication methods successfully used when the session was established, including any public keys that were used.
TZ- This variable is set to indicate the present time zone if it was set when the daemon was started (i.e. the daemon passes the value on to new connections).
USER- Set to the name of the user logging in.
Additionally, ssh reads ~/.ssh/environment, and adds lines of the format “VARNAME=value” to the environment if the file exists and users are allowed to change their environment. For more information, see the PermitUserEnvironment option in sshd_config(5).
FILES
- ~/.rhosts
- This file is used for host-based authentication (see above). On some machines this file may need to be world-readable if the user’s home directory is on an NFS partition, because sshd(8) reads it as root. Additionally, this file must be owned by the user, and must not have write permissions for anyone else. The recommended permission for most machines is read/write for the user, and not accessible by others.
- ~/.shosts
- This file is used in exactly the same way as .rhosts, but allows host-based authentication without permitting login with rlogin/rsh.
- ~/.ssh/
- This directory is the default location for all user-specific configuration and authentication information. There is no general requirement to keep the entire contents of this directory secret, but the recommended permissions are read/write/execute for the user, and not accessible by others.
- ~/.ssh/authorized_keys
- Lists the public keys (DSA, ECDSA, Ed25519, RSA) that can be used for logging in as this user. The format of this file is described in the sshd(8) manual page. This file is not highly sensitive, but the recommended permissions are read/write for the user, and not accessible by others.
- ~/.ssh/config
- This is the per-user configuration file. The file format and configuration options are described in ssh_config(5). Because of the potential for abuse, this file must have strict permissions: read/write for the user, and not writable by others.
- ~/.ssh/environment
- Contains additional definitions for environment variables; see ENVIRONMENT, above.
- ~/.ssh/id_dsa
- ~/.ssh/id_ecdsa
- ~/.ssh/id_ed25519
- ~/.ssh/id_rsa
- Contains the private key for authentication. These files contain sensitive data and should be readable by the user but not accessible by others (read/write/execute).ssh will simply ignore a private key file if it is accessible by others. It is possible to specify a passphrase when generating the key which will be used to encrypt the sensitive part of this file using AES-128.
- ~/.ssh/id_dsa.pub
- ~/.ssh/id_ecdsa.pub
- ~/.ssh/id_ed25519.pub
- ~/.ssh/id_rsa.pub
- Contains the public key for authentication. These files are not sensitive and can (but need not) be readable by anyone.
- ~/.ssh/known_hosts
- Contains a list of host keys for all hosts the user has logged into that are not already in the systemwide list of known host keys. See sshd(8) for further details of the format of this file.
- ~/.ssh/rc
- Commands in this file are executed by ssh when the user logs in, just before the user’s shell (or command) is started. See the sshd(8) manual page for more information.
- /etc/hosts.equiv
- This file is for host-based authentication (see above). It should only be writable by root.
- /etc/shosts.equiv
- This file is used in exactly the same way as hosts.equiv, but allows host-based authentication without permitting login with rlogin/rsh.
- /etc/ssh/ssh_config
- Systemwide configuration file. The file format and configuration options are described in ssh_config(5).
- /etc/ssh/ssh_host_key
- /etc/ssh/ssh_host_dsa_key
- /etc/ssh/ssh_host_ecdsa_key
- /etc/ssh/ssh_host_ed25519_key
- /etc/ssh/ssh_host_rsa_key
- These files contain the private parts of the host keys and are used for host-based authentication.
- /etc/ssh/ssh_known_hosts
- Systemwide list of known host keys. This file should be prepared by the system administrator to contain the public host keys of all machines in the organization. It should be world-readable. See sshd(8) for further details of the format of this file.
- /etc/ssh/sshrc
- Commands in this file are executed by ssh when the user logs in, just before the user’s shell (or command) is started. See the sshd(8) manual page for more information.
EXIT STATUS
ssh exits with the exit status of the remote command or with 255 if an error occurred.
SEE ALSO
scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), ssh-keyscan(1), tun(4),ssh_config(5), ssh-keysign(8), sshd(8)
STANDARDS
S. Lehtinen and C. Lonvick, The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4250,January 2006.
T. Ylonen and C. Lonvick, The Secure Shell (SSH) Protocol Architecture, RFC 4251, January 2006.
T. Ylonen and C. Lonvick, The Secure Shell (SSH) Authentication Protocol, RFC 4252,January 2006.
T. Ylonen and C. Lonvick, The Secure Shell (SSH) Transport Layer Protocol, RFC 4253,January 2006.
T. Ylonen and C. Lonvick, The Secure Shell (SSH) Connection Protocol, RFC 4254, January 2006.
J. Schlyter and W. Griffin, Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints, RFC 4255, January 2006.
F. Cusack and M. Forssen, Generic Message Exchange Authentication for the Secure Shell Protocol (SSH), RFC 4256, January 2006.
J. Galbraith and P. Remaker, The Secure Shell (SSH) Session Channel Break Extension, RFC 4335, January 2006.
M. Bellare, T. Kohno, and C. Namprempre, The Secure Shell (SSH) Transport Layer Encryption Modes, RFC 4344, January 2006.
B. Harris, Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol, RFC 4345, January 2006.
M. Friedl, N. Provos, and W. Simpson, Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol, RFC 4419, March 2006.
J. Galbraith and R. Thayer, The Secure Shell (SSH) Public Key File Format, RFC 4716,November 2006.
D. Stebila and J. Green, Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer, RFC 5656, December 2009.
A. Perrig and D. Song, Hash Visualization: a New Technique to improve Real-World Security,1999, International Workshop on Cryptographic Techniques and E-Commerce (CrypTEC ’99).
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 and Dug 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.