SSH

  1. SSH 为 Secure Shell 的缩写,由 IETF 的网络小组(Network Working Group)所制定;
    SSH 为建立在应用层基础上的安全协议。SSH 是目前较可靠,
    专为远程登录会话和其他网络服务提供安全性的协议。
    利用 SSH 协议可以有效防止远程管理过程中的信息泄露问题。SSH最初是UNIX系统上的一个程序,
    后来又迅速扩展到其他操作平台。SSH在正确使用时可弥补网络中的漏洞。SSH客户端适用于多种平台。
    几乎所有UNIX平台—包括HP-UX、Linux、AIX、Solaris、Digital UNIX、Irix,以及其他平台,
    都可运行SSH。

  2. 传统的网络服务程序,如:ftp、pop和telnet在本质上都是不安全的,
    因为它们在网络上用明文传送口令和数据,别有用心的人非常容易就可以截获这些口令和数据。
    而且,这些服务程序的安全验证方式也是有其弱点的, 就是很容易受到“中间人”(man-in-the-middle)
    这种方式的攻击。所谓“中间人”的攻击方式, 就是“中间人”冒充真正的服务器接收你传给服务器的数据,
    然后再冒充你把数据传给真正的服务器。服务器和你之间的数据传送被“中间人”一转手做了手脚之后,
    就会出现很严重的问题。通过使用SSH,你可以把所有传输的数据进行加密,
    这样"中间人"这种攻击方式就不可能实现了,而且也能够防止DNS欺骗和IP欺骗。
    使用SSH,还有一个额外的好处就是传输的数据是经过压缩的,所以可以加快传输的速度。
    SSH有很多功能,它既可以代替Telnet,又可以为FTP、PoP、甚至为PPP提供一个安全的"通道"

  3. 从客户端来看,SSH提供两种级别的安全验证。

  • 第一种级别(基于口令的安全验证)
    只要你知道自己帐号和口令,就可以登录到远程主机。所有传输的数据都会被加密,
    但是不能保证你正在连接的服务器就是你想连接的服务器。
    可能会有别的服务器在冒充真正的服务器,也就是受到“中间人”这种方式的攻击。
  • 第二种级别(基于密匙的安全验证)
    需要依靠密匙,也就是你必须为自己创建一对密匙,并把公用密匙放在需要访问的服务器上。
    如果你要连接到SSH服务器上,客户端软件就会向服务器发出请求,请求用你的密匙进行安全验证。
    服务器收到请求之后,先在该服务器上你的主目录下寻找你的公用密匙,
    然后把它和你发送过来的公用密匙进行比较。如果两个密匙一致,
    服务器就用公用密匙加密“质询”(challenge)并把它发送给客户端软件。
    客户端软件收到“质询”之后就可以用你的私人密匙解密再把它发送给服务器。
    用这种方式,你必须知道自己密匙的口令。但是,与第一种级别相比,
    第二种级别不需要在网络上传送口令。
    第二种级别不仅加密所有传送的数据,而且“中间人”这种攻击方式也是不可能的
    (因为他没有你的私人密匙)。但是整个登录的过程可能需要10秒
  1. SSH 主要由三部分组成:
  • 传输层协议 [SSH-TRANS]
  • 用户认证协议 [SSH-USERAUTH]
  • 连接协议 [SSH-CONNECT]
  1. SSH是由客户端和服务端的软件组成的
  • 服务端是一个守护进程(daemon),他在后台运行并响应来自客户端的连接请求。
    服务端一般是sshd进程,提供了对远程连接的处理,
    一般包括公共密钥认证、密钥交换、对称密钥加密和非安全连接。
  • 客户端包含ssh程序以及像scp(远程拷贝)、slogin(远程登陆)、sftp(安全文件传输)
    等其他的应用程序。
    本地的客户端发送一个连接请求到远程的服务端,
    服务端检查申请的包和IP地址再发送密钥给SSH的客户端,本地再将密钥发回给服务端,
    自此连接建立。
    SSH被设计成为工作于自己的基础之上而不利用超级服务器(inetd),
    虽然可以通过inetd上的tcpd来运行SSH进程,但是这完全没有必要。
    启动SSH服务器后,sshd运行起来并在默认的22端口进行监听
    (你可以用 # ps -waux | grep sshd 来查看sshd是否已经被正确的运行了)
    如果不是通过inetd启动的SSH,那么SSH就将一直等待连接请求。
    当请求到来的时候SSH守护进程会产生一个子进程,该子进程进行这次的连接处理

上述摘自百度百科:SSH

  1. 为什么要远程连接Linux系统?
    在实际的工作场景中,虚拟机界面或物理服务器本地的窗口都是很少能够接触到的,
    因为服务器装完系统后,都要拉到IDC机房托管,如果是购买了云主机,
    更碰不到服务器本地显示器了,此时,只能通过远程连接的方式管理Linux系统。
    因此,在装好linux系统后,学习Linux运维的第一步应该是配置好客户端软件远程
    (通过ssh软件进行连接)连接Linux系统进行管理
    telnet连接服务器是明文的,非加密的; 默认为23端口
    SSH连接服务器是加密的连接; 默认为22端口

  2. SSH连接示意
    服务器端===>通过ssh协议提供===>守护进程sshd监听22端口(不断的监听是否有人需要服务)
    客户端(客户):ssh协议,ip地址,端口号(需要什么服务),用户名,密码


    secureCRT
  3. CRT远程连接的基本原理
    我们在前几节中提到过,sshd这个服务,实际上是服务器的一个守护进程。
    正是因为存在这个守护进程,因此服务器的22端口才会持续不断的被监听(监视)
    当CRT通过ssh协议访问服务器的22端口的时候,服务器的sshd服务才会马上回应这个访问,
    因此才能进行远程连接
    故,当服务器不存在sshd(把进程kill掉)这个服务时,xshell是无法通过ssh协议进行远程访问的。

上述摘自:远程SSH连接服务与基本排错经验总结
第五节 远程SSH连接服务与基本排错

  1. Linux下关于SSH的文件在/root/.ssh路径下
  2. .ssh路径下有四个相关文件
  • authorized_keys

将A的公钥加入到B的authorized_keys,这样A连接到B就不需要密码
参考:ssh-keygen的使用方法及配置authorized_keys两台linux机器相互认证
ssh配置authorized_keys后仍然需要输入密码的问题

  • known_hosts
    ssh会把你每个你访问过计算机的公钥(public key)都记录在~/.ssh/known_hosts。
    当下次访问相同计算机时,OpenSSH会核对公钥。如果公钥不同,OpenSSH会发出警告,
    避免你受到DNS Hijack之类的攻击。我在上面列出的情况,就是这种情况。
    参考:ssh登陆之忽略known_hosts文件
    该档案是纪录连到对方时,对方给的 host key。每次连线时都会检查目前对方给的
    host key 与纪录的 host key 是否相同,可以简单验证连结是否又被诈骗等相关事宜。

  • id_rsa
    ssh-keygen -t [rsa|dsa],将会生成密钥文件和私钥文件 id_rsa,id_rsa.pub或id_dsa,id_dsa.pub
    id_rsa 为私钥

  • id_rsa.pub
    id_rsa.pub为公钥

  • SSH基本用法

  1. 假定你要以用户名user,登录远程主机host,只要一条简单命令就可以了。
      $ ssh user@host 如:ssh pika@192.168.0.111
    如果本地用户名与远程用户名一致,登录时可以省略用户名。
      $ ssh host
    SSH的默认端口是22,也就是说,你的登录请求会送进远程主机的22端口。使用p参数,可以修改这个端口。
      $ ssh -p 2222 user@host
    上面这条命令表示,ssh直接连接远程主机的2222端口。
    如果你是第一次登录对方主机,系统会出现下面的提示:
      $ ssh user@host
      The authenticity of host 'host (12.18.429.21)' can't be established.
      RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
      Are you sure you want to continue connecting (yes/no)?
    这段话的意思是,无法确认host主机的真实性,只知道它的公钥指纹,问你还想继续连接吗?
    所谓"公钥指纹",是指公钥长度较长(这里采用RSA算法,长达1024位),很难比对,所以对其进行MD5计算,将它变成一个128位的指纹。上例中是98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d,再进行比较,就容易多了。
    很自然的一个问题就是,用户怎么知道远程主机的公钥指纹应该是多少?回答是没有好办法,远程主机必须在自己的网站上贴出公钥指纹,以便用户自行核对。
    假定经过风险衡量以后,用户决定接受这个远程主机的公钥。
      Are you sure you want to continue connecting (yes/no)? yes
    系统会出现一句提示,表示host主机已经得到认可。
      Warning: Permanently added 'host,12.18.429.21' (RSA) to the list of known hosts.
    然后,会要求输入密码。
      Password: (enter password)
    如果密码正确,就可以登录了。
    当远程主机的公钥被接受以后,它就会被保存在文件$HOME/.ssh/known_hosts之中。下次再连接这台主机,系统就会认出它的公钥已经保存在本地了,从而跳过警告部分,直接提示输入密码。
    每个SSH用户都有自己的known_hosts文件,此外系统也有一个这样的文件,通常是/etc/ssh/ssh_known_hosts,保存一些对所有用户都可信赖的远程主机的公钥。
  2. 公钥登录
    使用密码登录,每次都必须输入密码,非常麻烦。好在SSH还提供了公钥登录,可以省去输入密码的步骤。
所谓"公钥登录",原理很简单,就是用户将自己的公钥储存在远程主机上。登录的时候,远程主机会向用户发送一段随机字符串,用户用自己的私钥加密后,再发回来。远程主机用事先储存的公钥进行解密,如果成功,就证明用户是可信的,直接允许登录shell,不再要求密码。

这种方法要求用户必须提供自己的公钥。如果没有现成的,可以直接用ssh-keygen生成一个:
  $ ssh-keygen
运行上面的命令以后,系统会出现一系列提示,可以一路回车。其中有一个问题是,要不要对私钥设置口令(passphrase),如果担心私钥的安全,这里可以设置一个。
运行结束以后,在$HOME/.ssh/目录下,会新生成两个文件:id_rsa.pub和id_rsa。前者是你的公钥,后者是你的私钥。
这时再输入下面的命令,将公钥传送到远程主机host上面:
  $ ssh-copy-id user@host
好了,从此你再登录,就不需要输入密码了。
如果还是不行,就打开远程主机的/etc/ssh/sshd_config这个文件,检查下面几行前面"#"注释是否取掉。
  RSAAuthentication yes
  PubkeyAuthentication yes
  AuthorizedKeysFile .ssh/authorized_keys
然后,重启远程主机的ssh服务。
  // ubuntu系统
  service ssh restart
  // debian系统
  /etc/init.d/ssh restart
authorized_keys文件
远程主机将用户的公钥,保存在登录后的用户主目录的$HOME/.ssh/authorized_keys文件中。公钥就是一段字符串,只要把它追加在authorized_keys文件的末尾就行了。
这里不使用上面的ssh-copy-id命令,改用下面的命令,解释公钥的保存过程:
  $ ssh user@host 'mkdir -p .ssh && cat >> .ssh/authorized_keys' < ~/.ssh/id_rsa.pub
这条命令由多个语句组成,依次分解开来看:(1)"$ ssh user@host",表示登录远程主机;(2)单引号中的mkdir .ssh && cat >> .ssh/authorized_keys,表示登录后在远程shell上执行的命令:(3)"$ mkdir -p .ssh"的作用是,如果用户主目录中的.ssh目录不存在,就创建一个;(4)'cat >> .ssh/authorized_keys' < /.ssh/id_rsa.pub的作用是,将本地的公钥文件/.ssh/id_rsa.pub,重定向追加到远程文件authorized_keys的末尾。
写入authorized_keys文件后,公钥登录的设置就完成了。
上述摘自:ssh用法及命令

  1. 与ssh有关的文件目录还有/etc/ssh
    下面有文件
  • moduli
  • ssh_config
  • sshd_config
  • ssh_host_dsa_key
  • ssh_host_dsa_key.pub
  • ssh_host_key
  • ssh_host_key.pub
  • ssh_host_rsa_key
  • ssh_host_rsa_key.pub
  1. 关于公钥格式的问题,请参考:https://www.jianshu.com/p/2b250309dba4
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,271评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,275评论 2 380
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,151评论 0 336
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,550评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,553评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,559评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,924评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,580评论 0 257
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,826评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,578评论 2 320
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,661评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,363评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,940评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,926评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,156评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,872评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,391评论 2 342

推荐阅读更多精彩内容

  • 1、远程连接服务器 远程连接服务器对于管理员来说,是一个很有用的操作。它使得对服务器的管理更为方便。不过方便归方便...
    Zhang21阅读 39,477评论 0 20
  • ** SSH(安全外壳协议) **为 Secure Shell 的缩写,由 IETF 的网络小组(Network ...
    linfree阅读 834评论 4 7
  • ssh在程序员的生活中还是非常常见的,ssh具有很多种功能,也可以用在很多种场合。 什么是SSH SSH是一种网络...
    你期待的花开阅读 527评论 0 4
  • SSH原理与应用 ssh在程序员的生活中还是非常常见的,ssh具有很多种功能,也可以用在很多种场合。 什么是SSH...
    关玮琳linSir阅读 866评论 1 10
  • SSH全称Secure SHell,顾名思义就是非常安全的shell的意思,SSH协议是IETF(Internet...
    StarShift阅读 2,492评论 0 7