postfix虚拟网域[转]

近年来,用同一台主机来搭建多个网域,已经蔚然成风。举个实例来说,oreillynet.com和onlamp.com其实位于同一台主机,但是从外界的观点来看,它们似乎分别位于两台完全不同的主机上。一个系统通常有一个最具代表性的网域名称,称为正式网域,除此之外的其他网域,则被视为虚拟网域。每个虚拟网域都可以提供自己的网络与邮件服务,且外界看不出正式网域与虚拟网域的差别。
postfix如何投递虚拟网域的邮件,决定了你需要哪些技术。有两个重要因素影响你的postfix如何支持多个虚拟网域:
网域之间要有单独的命名空间吗?比方说,写给info@oreilly.com和info@ora.com这两个地址的邮件,是放在同一个邮箱还是各自单独的邮箱?对于使用相同邮箱的情况,我们称之为共享网域;而另一种情况则称为独立网域。
每位用户都需要系统账户吗?我们将区别“系统账户”与“虚拟账户”的不同。前者是真正的unix账户,可用来登录服务器系统;后者纯粹用于辨识邮箱,不能登录系统,在/etc/passwd里也没有对应记录。
我们将探讨postfix对于虚拟网域邮件的四种处理方式:
共享网域搭配系统账户
独立网域搭配系统账户
独立网域搭配虚拟账户
虚拟网域搭配非postfix控制管理的特殊格式邮箱
应该挑选哪一种技术,主要决定因素是你所使用的POP/IMAP server。如果你的POP/IMAP server不能辨别虚拟网域,那么,很可能所有邮件地址需要系统账户。某些POP/IMAP servers天生就是为了支持多重网域而设计,而且邮件是存放在本地文件系统的某个特定目录结构下,还有些POP/IMAP server使用自己专属的邮箱格式。对于posfix不支持的邮箱格式,postfix可使用LMTP将邮件交给POP/IMAP server。
不管采用哪一种技术,你的正式网域的DNS是怎么设定的,所有虚拟网域的DNS都必须“依样画葫芦”。
共享网域搭配系统账户
最简单的虚拟网域模式,是每位用户都可以收到每个网域的邮件。就用户的感受而言,就好像同一个邮箱有多个地址一样。这种模式的设定方法最简单,只要将所有虚拟网域名称都列在mydestination参数,并像平常一样为每一位用户都创建自己的系统账户,他们就可以收到写给任何网域的邮件。
这种模式使用LOCAL MDA来执行投递操作,因此,正式网域该有的功能,虚拟网域同样一应俱全,所有网域共享同一个别名文件,每位用户都可以创建自己的.forward文件。举例来说,假设我们希望oreillynet.com网域的邮件服务器兼任ora.com与oreilly.com这两个网域的邮件交换站。第一步是设定那两个虚拟网域的DNS,将它们的mx都指向此服务器;第二步是修改此服务器的mydestination参数,完成修改之后,记得要让postfix重新读取其配置文件,让你所做的改变生效;用户现在可以收到寄给mydestination所列的任一网域的邮件。外界写给info@ora.com或 info@oreilly.com的邮件,都会被投递到同一个系统账户的邮箱。
独立网域搭配系统账户
如果每个虚拟网域都要有自己的命名空间,设定方法就稍微复杂些。在独立网域模式下,写给info@ora.com的邮件不应该被放在 info@oreilly.com的邮箱中。在这种情况下,虚拟网域不应该被列在mydestination参数中,而应该被列在 virtual_alias_domains参数中;你必须为每一个邮件地址分别创建对应的系统账户。每一个系统账户的名称都必须独一无二,但是不要求一定要与邮件地址的人名部分相同,因为我们可以另外准备一个查询表来定义两者之间的对应关系。若要区别账户所属网域,同时又要避免账户名称重复,最简单的方法是将网域名称当成账户名称的一部分。一种可行的命名法则,是使用类似info.ora.com和info.oreilly.com这样的名称来创建系统账户。不过,某些系统平台的账户名称被限制在8个字符以下,如果你的平台不支持长名称,就不能使用这种命名法则。
在postfix知道它应该收下哪些网域的邮件,而你也为每一个地址都准备好对应的系统账户之后,下一步就是将virtual_ailas_maps指向虚拟别名表:
virtual_alias_maps = hash:/etc/postfix/virtual_alias
此查询表定义了每一个虚拟网域邮件地址所对应的实际邮件地址。
每当你修改虚拟别名表后,别忘了使用postmap将该文件转换成postfix可直接查询的格式:
postmap virtual_alias
如果helene和frank能够登录服务器系统,直接从服务器寄信出去,你可能还需要另外准备一个规范映射表,好让他们寄出去的邮件的寄件人地址被改写成正确的地址。例如:
canoniacl_maps = hash:/etc/postfix/canonical
再次提醒,规范映射表也必须经过postmap的转换
独立网域搭配虚拟账户
前两种模式最大的缺点,就是每一个邮件地址都必须在服务器上有对应的系统账户。虽然事前的设定过程不难,但是事后维护工作却很麻烦。尤其当虚拟网域的数量增加时,系统账户的维护工作更是苦不堪言。此外,从系统安全的角度来看,如果绝大部分用户都只是利用服务器来收信而已,实在没有必要赋予他们能够登录系统的能力。比较务实的做法,应该是要求postfix将邮件投递到本地系统上的一个虚拟邮箱目录,在此目录下,每一个虚拟邮件都有自己的邮箱文件,而用户可通过支持虚拟邮箱的POP/IMAP server来取信。虚拟邮箱与一般邮箱的差别之处,在于邮件文件与系统账户之间不要求存在一比一的对应关系。
使用虚拟邮箱模式时,你必须在virtual_mailbox_domains参数列出每一个虚拟网域的名称:
virtual_mailbox_domains = ora.com, oreilly.com
如果你有许多虚拟网域,不妨将它们列在一个文件,然后将virtual_mailbox_domains指向该文件:
virtual_mailbox_domains = /etc/postfix/virtual_domains
/etc/postfix/virtual_domains文件的每一行,各包含一个虚拟网域的名称。
每当postfix收到写给virtual_mailbox_domains所列的虚拟网域的邮件时,就交由virtual MDA执行投递操作。virtual的实质是local MDA的“小型版本”,它以一种安全而且高效率的程序来进行投递,其代价是牺牲了本地别名文件、forward文件、MLM饿支持。不过,这不是什么大缺点,因为我们仍可使用virtual_alias_maps参数来达到同样的效果。
设定虚拟邮箱时,你应该妥善安排邮件目录的结构,使其符合POP/IMAP server的预期要求。支持虚拟邮箱的POP/IMAP server,多半假设所有虚拟邮箱都位于某一个基础目录下,在此目录下,每一个虚拟网域都有一个与其网域名称同名的子目录。因此,如果有两个虚拟网域,则它们的虚拟邮箱应该分别被放在两个子目录下;
定义虚拟邮箱基础目录的参数是virtual_mailbox_base,你必须给出完整的目录路径;
virtual_mailbox_base = /var/vmail
virtual_mailbox_maps参数定义虚拟邮箱查询表的位置;此查询表描述每一位虚拟邮箱用户的邮件地址以及对应的邮箱文件的相对路径文件名。邮箱文件的格式可以是mbox或maildir。如果你选择maildir格式,邮箱文件名末端必须加一个“/”符合。
info@ora.com            ora.com/info
info@oreilly.com         oreilly.com/info
完成上述设定后,外界写到info@ora.com和info@oreilly.com的邮件,就不会存放在同一个邮箱了。
邮箱文件的拥有权
Unix系统上的每一个文件都有主人,虚拟邮箱文件也不例外--虽然虚拟邮箱的“用户”没有系统账户。因此,用户如何访问邮箱文件,决定呢邮箱文件拥有权的归属。通常,POP/IMAP server的运行权限继承于某个专属的系统虚账户,并假设其权限足以访问所有邮箱文件。因此,邮箱文件的拥有者应该是POP/IMAP server所有的那个虚账户。但是,如果必要的话,postfix也容许你自己决定文件的拥有者。你可以让每个邮箱文件都有自己的拥有者或是让同网域的所有邮箱文件都同属于一个拥有者,但不同网域的邮箱分属不同的拥有者。
virtual_uid_maps于virtual_gid_maps参数决定了postfix的virtual MDA投递邮件到虚拟邮箱时,应该继承的系统账户。假设所有虚拟邮箱都属于同一个账户,则你可以使用static映射方式,直接指定virtual所要继承的UID与GID;
virtual_uid_maps = static:1003
virtual_gid_maps = static:1005
这会使得virtual MDA以UID 1003、GID 1005的身份来访问任何邮箱文件。如果你希望virtual以不同的UID身份来访问不同的邮箱文件,你必须另外准备一个查询表,定义各个虚拟邮箱地址与UID之间的对应关系,然后将virtual_uid_maps指向 此查询表;
virtual_uid_maps = hash:/etc/postfix/virtual_uids
如果大部分的虚拟邮箱文件属于固定的拥有者,但也有某些是属于不同的UID,你可以混合使用static与查询表:
virtual_uid_maps = hash:/etc/postfix/virtual_uids static:1003
virtual_gid_maps参数的用法与virtual_uid_maps完全相同。
定义邮箱文件与拥有者对应关系的/etc/postfix/virtual_uids文件,其索引键是邮箱文件所属的邮件地址,而对应值是邮箱文件拥有者的UID(或GID)。举例来说,如果我们希望ora.com网域的所有邮箱都属于同一个UID,而oreilly.com的邮箱属于另一个UID。
虚拟别名
即使是虚拟网域,postfix也能将其邮件投递到本地邮箱,或是转寄到其他站点。既然所有类型的收件地址都会被检查是否为虚拟别名,所以,只要把转寄地址放在virtual_alias_maps所指的文件即可。请确定virtual_alias_maps参数指向一个虚拟别名表:
virtual_alias_maps = hash:/etc/postfix/virtual_alias
/etc/postfix/virtual_alias文件包含了要被转寄到他处的虚拟地址:
kdent@oreilly.com      kyle.dent@onlamp.com
不要将同一个网域同时列在virtual_mailbox_domains和virtual_alias_domains中。对于同时含有邮箱与别名的虚拟网域,请使用virtual_mailbox_domains。如果所有地址都是别名,请使用virtual_alias_domains。
无限别名地址
无论是虚拟别名还是虚拟邮箱,它们的查询表都可以含有一个“无限别名地址”--只有网域部分没有人名部分的邮件地址。无限别名地址所对应的邮箱(如果是虚拟邮箱的话)或转寄地址(如果是虚拟别名的话),用来承接外界寄到该网域的不明用户的邮件。无限别名地址应该谨慎使用,因为它们一定会收到大量垃圾邮件。发送垃圾邮件者常用“字典攻击法”来滥发垃圾邮件,所以你的邮件服务器会时常收到寄信给不明用户的要求。如果设定了无限别名地址,等于是让这些发送垃圾邮件者有机会塞爆你的邮箱。
无限别名虚拟邮箱
第一步是找出一个邮箱来承接所有寄给不明用户的邮件。你可以使用现有的邮箱,或是另外创建一个新邮箱。决定好邮箱之后,在virtual_mailbox_maps所指的查询表增加一笔无限别名地址记录;
@ora.com         ora.com/service
无限别名虚拟别名
无限别名虚拟别名的设定步骤,很类似无限别名虚拟邮箱。第一步,先选定一个邮箱地址来接收所有寄到不明别名等邮件,然后在virtual_alias_maps所指的查询表定义无限别名所对应的地址:
@ora.com         customer.service@onlamp.com
除非你的系统没有任何虚拟邮箱,否则不应该设置无限别名虚拟别名。因为postfix会先展开虚拟别名,然后才检查虚拟邮箱;如果你设置了无限别名虚拟别名,它将拦截掉所有的邮件,包括原本应该投递到虚拟邮箱的邮件。
在设置了无限别名的情况下,如果还希望虚拟邮箱能够收到邮件,唯一办法是将虚拟别名展开成虚拟邮箱地址。举例来说,假设下面是虚拟邮箱查询表的内容:
info@ora.com         ora.com/info
info@oreilly.com      oreilly.com/info
那么,含有无限别名的虚拟别名表,应该要含有上述虚拟邮箱的别名地址:
info@ora.com      info@ora.com
info@oreilly.com      info@oreilly.com
kdent@oreilly.com      kyle.dent@onlamp.com
@ora.com      customer.service@onlamp.com
如此一来,寄到info@oreilly.com的邮件,就不至于被@ora.com无限别名拦截掉了。
虚拟网域搭配特殊格式的邮箱
我们要讨论的最后一种操作模式,是在一个使用特殊邮箱格式的系统上假设虚拟网域。在这类系统上,postfix本身不做投递工作,而是使用LMTP协议将邮件托付给知道如何访问特殊邮箱的程序。
因为postfix必须先收下邮件后才转交给LMTP server,所以postfix必须知道它要收下哪些虚拟网域名称的邮件。请将这些网域的名称列于virtual_mailbox_domains参数:
virtual_mailbox_domains = ora.com, oreilly.com
你还必须逐一列出每一个邮件地址,这样postfix才能够知道哪些收件地址是有效的,并拒收不明用户的邮件。请将virual_mailbox_maps参数指向有效地址查询表:
virtual_mailbox_maps = hash:/etc/postfix/virtual
因为postfix只需要知道地址的有效性而不参与投递工作,所以/etc/postfix/virtual查询表只有索引键的部分有意义,对应值的部分没有作用。然而,查询表的格式不容许我们省略对应值,所以仍必须随便填入数据;
为了让postfix能将虚拟网域的邮件交给POP/IMAP server,我们还必须在main.cf的virtual_transport参数中指定正确的传送方法,也就是LMTP server的socket是何种形式。假设LMTP server与postfix都位于同一台机器,而且LMTP server使用unix-domain socket,其文件位置是/var/imap/socket/lmtp,则virtual_transport应该这样设定:
virtual_transport = lmtp:unix:/var/imap/socket/lmtp
现在,每当postfix收到寄给virtual_mailbox_domains所列的任一网域的邮件,都会通过LMTP协议交给同机器上的POP/IMAP server来执行投递操作。
投递到外部程序
先前说过,virtual MDA不能处理系统别名文件与个人的.forward文件。虽然使用virtual_alias_maps可弥补虚拟网域的地址别名问题,但是.forward文件的一项重要功能--传递邮件内容给外部程序,还没解决。这表示虚拟网域的地址没有自动回信功能,也不能假设邮递列表管理系统。本节将示范如何利用postfix的其他机制,让寄到虚拟地址的邮件也可以传给外部程序。第一个例子示范如何投递邮件到一个自动回复程序,第二个例子以majordomo MLM来做示范。
自动回信程序的作用,主要是在没有任何人员接入操作的情况下,自动处理外来邮件、储存或处理来信信息,然后回信给原寄信人。回信程序可以是简单的脚步,也可以是以C或任何语言写成的复杂程序。
假设我们要提供一个供客户请求信息的服务,只要客户寄信到特定地址,就回复一封含有请求信息的回信。我们不希望使用人工处理这种千篇一律的机械工作,所以,最好的办法是写一个自动回复程序。
将虚拟网域的邮件传给自动回信程序
虚拟网域的邮件不能通过.forward机制传给外部程序,因此,若想让自动回信程序能收到虚拟地址的邮件,我们必须在master.cf中增加一个能投递邮件到外部程序的特殊MDA,然后使用传输表将特定地址的邮件交给这个特殊的MDA处理。
许多自动回信程序一次只能处理一封来信,而且一次只能回一封信。对于每一种MDA,都有一个限制收件人数量的mda_destination_recipient_limit参数,其中的mda是MDA在master.cf里的服务名称。
自动回信程序的设计
如果你想设计自己的自动回信程序,有些重要考虑事项必须注意。首先,同时也可能是最重要的事项,就是程序的数据来源是网络--一种不可信赖的数据源。千万别假设你要处理的数据一定会是什么样子,除了它们被可以安排成能征服你的系统之外。无论任何情况,都不应该调用shell来处理不可信的外来数据,让外界有机会夺取你的系统的访问权。
另一个要考虑的事项,是礼节教养问题。想像一下,如果自动回信程序的回信对象是一个含有几千人的邮箱列表,将客户请求的信息泄漏给几千人,或是让几千人收到不相干的邮件,应该都不是你原意见到的事。因此,在实际回信之前,最好先检查寄件人地址是否为owner-list或list-request之类的形式。此外,还有一些地址恐怕也是你不想回复的,像postmaster、daemon、majordomo等。你的程序应该将自己的信封地址设成空字符串,以免造成邮件循环。
许多邮件列表会利用precedence:标题栏来注明它自己。它们通常使用bulk之类的值来表示邮件的性质。你的回信程序应该要检查precedence:标题栏的值,如果发现bulk、list或junk之类的字样,就不必回信了。
最后,确定你的程序能记录每封来信的处理状况。一旦postfix将邮件托付给你的程序,你的程序就有检查错误的责任,并为管理员提供可以在事后追查问题的线索。
在虚拟网域假设邮件列表管理系统
第二各例子,我们要示范如何在虚拟网域上设置一个邮件列表。
postfix与MLM之间的连接是通过别名文件:利用别名文件的:include;机制来展开列表,并将管理用途的别名对应到实际地址与MLM管理程序。然而,只有local MDA才会处理系统的别名文件,virtual MDA没有这方面的功能。
虚拟邮件列表的原理,是在本地网域下创建列表的相同版本,这各本地版本仅供系统内部使用,外界用户所用的仍是虚拟地址,他们并部知道本地版本的存在。在决定本地版本的名称时,我们可设法将虚拟名称包含在内,以便容纳同系统上的其他虚拟网域列表

近年来,用同一台主机来搭建多个网域,已经蔚然成风。举个实例来说,oreillynet.com和onlamp.com其实位于同一台主机,但是从外界的观点来看,它们似乎分别位于两台完全不同的主机上。一个系统通常有一个最具代表性的网域名称,称为正式网域,除此之外的其他网域,则被视为虚拟网域。每个虚拟网域都可以提供自己的网络与邮件服务,且外界看不出正式网域与虚拟网域的差别。postfix如何投递虚拟网域的邮件,决定了你需要哪些技术。有两个重要因素影响你的postfix如何支持多个虚拟网域:       网域之间要有单独的命名空间吗?比方说,写给info@oreilly.com和info@ora.com这两个地址的邮件,是放在同一个邮箱还是各自单独的邮箱?对于使用相同邮箱的情况,我们称之为共享网域;而另一种情况则称为独立网域。       每位用户都需要系统账户吗?我们将区别“系统账户”与“虚拟账户”的不同。前者是真正的unix账户,可用来登录服务器系统;后者纯粹用于辨识邮箱,不能登录系统,在/etc/passwd里也没有对应记录。我们将探讨postfix对于虚拟网域邮件的四种处理方式:       共享网域搭配系统账户       独立网域搭配系统账户       独立网域搭配虚拟账户       虚拟网域搭配非postfix控制管理的特殊格式邮箱应该挑选哪一种技术,主要决定因素是你所使用的POP/IMAP server。如果你的POP/IMAP server不能辨别虚拟网域,那么,很可能所有邮件地址需要系统账户。某些POP/IMAP servers天生就是为了支持多重网域而设计,而且邮件是存放在本地文件系统的某个特定目录结构下,还有些POP/IMAP server使用自己专属的邮箱格式。对于posfix不支持的邮箱格式,postfix可使用LMTP将邮件交给POP/IMAP server。不管采用哪一种技术,你的正式网域的DNS是怎么设定的,所有虚拟网域的DNS都必须“依样画葫芦”。
共享网域搭配系统账户
最简单的虚拟网域模式,是每位用户都可以收到每个网域的邮件。就用户的感受而言,就好像同一个邮箱有多个地址一样。这种模式的设定方法最简单,只要将所有虚拟网域名称都列在mydestination参数,并像平常一样为每一位用户都创建自己的系统账户,他们就可以收到写给任何网域的邮件。这种模式使用LOCAL MDA来执行投递操作,因此,正式网域该有的功能,虚拟网域同样一应俱全,所有网域共享同一个别名文件,每位用户都可以创建自己的.forward文件。举例来说,假设我们希望oreillynet.com网域的邮件服务器兼任ora.com与oreilly.com这两个网域的邮件交换站。第一步是设定那两个虚拟网域的DNS,将它们的mx都指向此服务器;第二步是修改此服务器的mydestination参数,完成修改之后,记得要让postfix重新读取其配置文件,让你所做的改变生效;用户现在可以收到寄给mydestination所列的任一网域的邮件。外界写给info@ora.com或 info@oreilly.com的邮件,都会被投递到同一个系统账户的邮箱。
独立网域搭配系统账户
如果每个虚拟网域都要有自己的命名空间,设定方法就稍微复杂些。在独立网域模式下,写给info@ora.com的邮件不应该被放在 info@oreilly.com的邮箱中。在这种情况下,虚拟网域不应该被列在mydestination参数中,而应该被列在 virtual_alias_domains参数中;你必须为每一个邮件地址分别创建对应的系统账户。每一个系统账户的名称都必须独一无二,但是不要求一定要与邮件地址的人名部分相同,因为我们可以另外准备一个查询表来定义两者之间的对应关系。若要区别账户所属网域,同时又要避免账户名称重复,最简单的方法是将网域名称当成账户名称的一部分。一种可行的命名法则,是使用类似info.ora.com和info.oreilly.com这样的名称来创建系统账户。不过,某些系统平台的账户名称被限制在8个字符以下,如果你的平台不支持长名称,就不能使用这种命名法则。在postfix知道它应该收下哪些网域的邮件,而你也为每一个地址都准备好对应的系统账户之后,下一步就是将virtual_ailas_maps指向虚拟别名表:       virtual_alias_maps = hash:/etc/postfix/virtual_alias此查询表定义了每一个虚拟网域邮件地址所对应的实际邮件地址。每当你修改虚拟别名表后,别忘了使用postmap将该文件转换成postfix可直接查询的格式:          postmap virtual_alias如果helene和frank能够登录服务器系统,直接从服务器寄信出去,你可能还需要另外准备一个规范映射表,好让他们寄出去的邮件的寄件人地址被改写成正确的地址。例如:       canoniacl_maps = hash:/etc/postfix/canonical再次提醒,规范映射表也必须经过postmap的转换
独立网域搭配虚拟账户
前两种模式最大的缺点,就是每一个邮件地址都必须在服务器上有对应的系统账户。虽然事前的设定过程不难,但是事后维护工作却很麻烦。尤其当虚拟网域的数量增加时,系统账户的维护工作更是苦不堪言。此外,从系统安全的角度来看,如果绝大部分用户都只是利用服务器来收信而已,实在没有必要赋予他们能够登录系统的能力。比较务实的做法,应该是要求postfix将邮件投递到本地系统上的一个虚拟邮箱目录,在此目录下,每一个虚拟邮件都有自己的邮箱文件,而用户可通过支持虚拟邮箱的POP/IMAP server来取信。虚拟邮箱与一般邮箱的差别之处,在于邮件文件与系统账户之间不要求存在一比一的对应关系。使用虚拟邮箱模式时,你必须在virtual_mailbox_domains参数列出每一个虚拟网域的名称:       virtual_mailbox_domains = ora.com, oreilly.com如果你有许多虚拟网域,不妨将它们列在一个文件,然后将virtual_mailbox_domains指向该文件:       virtual_mailbox_domains = /etc/postfix/virtual_domains/etc/postfix/virtual_domains文件的每一行,各包含一个虚拟网域的名称。每当postfix收到写给virtual_mailbox_domains所列的虚拟网域的邮件时,就交由virtual MDA执行投递操作。virtual的实质是local MDA的“小型版本”,它以一种安全而且高效率的程序来进行投递,其代价是牺牲了本地别名文件、forward文件、MLM饿支持。不过,这不是什么大缺点,因为我们仍可使用virtual_alias_maps参数来达到同样的效果。设定虚拟邮箱时,你应该妥善安排邮件目录的结构,使其符合POP/IMAP server的预期要求。支持虚拟邮箱的POP/IMAP server,多半假设所有虚拟邮箱都位于某一个基础目录下,在此目录下,每一个虚拟网域都有一个与其网域名称同名的子目录。因此,如果有两个虚拟网域,则它们的虚拟邮箱应该分别被放在两个子目录下;定义虚拟邮箱基础目录的参数是virtual_mailbox_base,你必须给出完整的目录路径;       virtual_mailbox_base = /var/vmailvirtual_mailbox_maps参数定义虚拟邮箱查询表的位置;此查询表描述每一位虚拟邮箱用户的邮件地址以及对应的邮箱文件的相对路径文件名。邮箱文件的格式可以是mbox或maildir。如果你选择maildir格式,邮箱文件名末端必须加一个“/”符合。       info@ora.com            ora.com/info       info@oreilly.com         oreilly.com/info完成上述设定后,外界写到info@ora.com和info@oreilly.com的邮件,就不会存放在同一个邮箱了。
邮箱文件的拥有权
Unix系统上的每一个文件都有主人,虚拟邮箱文件也不例外--虽然虚拟邮箱的“用户”没有系统账户。因此,用户如何访问邮箱文件,决定呢邮箱文件拥有权的归属。通常,POP/IMAP server的运行权限继承于某个专属的系统虚账户,并假设其权限足以访问所有邮箱文件。因此,邮箱文件的拥有者应该是POP/IMAP server所有的那个虚账户。但是,如果必要的话,postfix也容许你自己决定文件的拥有者。你可以让每个邮箱文件都有自己的拥有者或是让同网域的所有邮箱文件都同属于一个拥有者,但不同网域的邮箱分属不同的拥有者。virtual_uid_maps于virtual_gid_maps参数决定了postfix的virtual MDA投递邮件到虚拟邮箱时,应该继承的系统账户。假设所有虚拟邮箱都属于同一个账户,则你可以使用static映射方式,直接指定virtual所要继承的UID与GID;       virtual_uid_maps = static:1003       virtual_gid_maps = static:1005这会使得virtual MDA以UID 1003、GID 1005的身份来访问任何邮箱文件。如果你希望virtual以不同的UID身份来访问不同的邮箱文件,你必须另外准备一个查询表,定义各个虚拟邮箱地址与UID之间的对应关系,然后将virtual_uid_maps指向 此查询表;       virtual_uid_maps = hash:/etc/postfix/virtual_uids如果大部分的虚拟邮箱文件属于固定的拥有者,但也有某些是属于不同的UID,你可以混合使用static与查询表:       virtual_uid_maps = hash:/etc/postfix/virtual_uids static:1003virtual_gid_maps参数的用法与virtual_uid_maps完全相同。定义邮箱文件与拥有者对应关系的/etc/postfix/virtual_uids文件,其索引键是邮箱文件所属的邮件地址,而对应值是邮箱文件拥有者的UID(或GID)。举例来说,如果我们希望ora.com网域的所有邮箱都属于同一个UID,而oreilly.com的邮箱属于另一个UID。
虚拟别名
即使是虚拟网域,postfix也能将其邮件投递到本地邮箱,或是转寄到其他站点。既然所有类型的收件地址都会被检查是否为虚拟别名,所以,只要把转寄地址放在virtual_alias_maps所指的文件即可。请确定virtual_alias_maps参数指向一个虚拟别名表:       virtual_alias_maps = hash:/etc/postfix/virtual_alias/etc/postfix/virtual_alias文件包含了要被转寄到他处的虚拟地址:       kdent@oreilly.com      kyle.dent@onlamp.com不要将同一个网域同时列在virtual_mailbox_domains和virtual_alias_domains中。对于同时含有邮箱与别名的虚拟网域,请使用virtual_mailbox_domains。如果所有地址都是别名,请使用virtual_alias_domains。
无限别名地址
无论是虚拟别名还是虚拟邮箱,它们的查询表都可以含有一个“无限别名地址”--只有网域部分没有人名部分的邮件地址。无限别名地址所对应的邮箱(如果是虚拟邮箱的话)或转寄地址(如果是虚拟别名的话),用来承接外界寄到该网域的不明用户的邮件。无限别名地址应该谨慎使用,因为它们一定会收到大量垃圾邮件。发送垃圾邮件者常用“字典攻击法”来滥发垃圾邮件,所以你的邮件服务器会时常收到寄信给不明用户的要求。如果设定了无限别名地址,等于是让这些发送垃圾邮件者有机会塞爆你的邮箱。
无限别名虚拟邮箱第一步是找出一个邮箱来承接所有寄给不明用户的邮件。你可以使用现有的邮箱,或是另外创建一个新邮箱。决定好邮箱之后,在virtual_mailbox_maps所指的查询表增加一笔无限别名地址记录;       @ora.com         ora.com/service
无限别名虚拟别名
无限别名虚拟别名的设定步骤,很类似无限别名虚拟邮箱。第一步,先选定一个邮箱地址来接收所有寄到不明别名等邮件,然后在virtual_alias_maps所指的查询表定义无限别名所对应的地址:       @ora.com         customer.service@onlamp.com除非你的系统没有任何虚拟邮箱,否则不应该设置无限别名虚拟别名。因为postfix会先展开虚拟别名,然后才检查虚拟邮箱;如果你设置了无限别名虚拟别名,它将拦截掉所有的邮件,包括原本应该投递到虚拟邮箱的邮件。在设置了无限别名的情况下,如果还希望虚拟邮箱能够收到邮件,唯一办法是将虚拟别名展开成虚拟邮箱地址。举例来说,假设下面是虚拟邮箱查询表的内容:       info@ora.com         ora.com/info       info@oreilly.com      oreilly.com/info那么,含有无限别名的虚拟别名表,应该要含有上述虚拟邮箱的别名地址:       info@ora.com      info@ora.com         info@oreilly.com      info@oreilly.com         kdent@oreilly.com      kyle.dent@onlamp.com       @ora.com      customer.service@onlamp.com如此一来,寄到info@oreilly.com的邮件,就不至于被@ora.com无限别名拦截掉了。
虚拟网域搭配特殊格式的邮箱
我们要讨论的最后一种操作模式,是在一个使用特殊邮箱格式的系统上假设虚拟网域。在这类系统上,postfix本身不做投递工作,而是使用LMTP协议将邮件托付给知道如何访问特殊邮箱的程序。因为postfix必须先收下邮件后才转交给LMTP server,所以postfix必须知道它要收下哪些虚拟网域名称的邮件。请将这些网域的名称列于virtual_mailbox_domains参数:       virtual_mailbox_domains = ora.com, oreilly.com你还必须逐一列出每一个邮件地址,这样postfix才能够知道哪些收件地址是有效的,并拒收不明用户的邮件。请将virual_mailbox_maps参数指向有效地址查询表:          virtual_mailbox_maps = hash:/etc/postfix/virtual因为postfix只需要知道地址的有效性而不参与投递工作,所以/etc/postfix/virtual查询表只有索引键的部分有意义,对应值的部分没有作用。然而,查询表的格式不容许我们省略对应值,所以仍必须随便填入数据;为了让postfix能将虚拟网域的邮件交给POP/IMAP server,我们还必须在main.cf的virtual_transport参数中指定正确的传送方法,也就是LMTP server的socket是何种形式。假设LMTP server与postfix都位于同一台机器,而且LMTP server使用unix-domain socket,其文件位置是/var/imap/socket/lmtp,则virtual_transport应该这样设定:       virtual_transport = lmtp:unix:/var/imap/socket/lmtp现在,每当postfix收到寄给virtual_mailbox_domains所列的任一网域的邮件,都会通过LMTP协议交给同机器上的POP/IMAP server来执行投递操作。
投递到外部程序
先前说过,virtual MDA不能处理系统别名文件与个人的.forward文件。虽然使用virtual_alias_maps可弥补虚拟网域的地址别名问题,但是.forward文件的一项重要功能--传递邮件内容给外部程序,还没解决。这表示虚拟网域的地址没有自动回信功能,也不能假设邮递列表管理系统。本节将示范如何利用postfix的其他机制,让寄到虚拟地址的邮件也可以传给外部程序。第一个例子示范如何投递邮件到一个自动回复程序,第二个例子以majordomo MLM来做示范。自动回信程序的作用,主要是在没有任何人员接入操作的情况下,自动处理外来邮件、储存或处理来信信息,然后回信给原寄信人。回信程序可以是简单的脚步,也可以是以C或任何语言写成的复杂程序。假设我们要提供一个供客户请求信息的服务,只要客户寄信到特定地址,就回复一封含有请求信息的回信。我们不希望使用人工处理这种千篇一律的机械工作,所以,最好的办法是写一个自动回复程序。
将虚拟网域的邮件传给自动回信程序
虚拟网域的邮件不能通过.forward机制传给外部程序,因此,若想让自动回信程序能收到虚拟地址的邮件,我们必须在master.cf中增加一个能投递邮件到外部程序的特殊MDA,然后使用传输表将特定地址的邮件交给这个特殊的MDA处理。许多自动回信程序一次只能处理一封来信,而且一次只能回一封信。对于每一种MDA,都有一个限制收件人数量的mda_destination_recipient_limit参数,其中的mda是MDA在master.cf里的服务名称。
自动回信程序的设计
如果你想设计自己的自动回信程序,有些重要考虑事项必须注意。首先,同时也可能是最重要的事项,就是程序的数据来源是网络--一种不可信赖的数据源。千万别假设你要处理的数据一定会是什么样子,除了它们被可以安排成能征服你的系统之外。无论任何情况,都不应该调用shell来处理不可信的外来数据,让外界有机会夺取你的系统的访问权。另一个要考虑的事项,是礼节教养问题。想像一下,如果自动回信程序的回信对象是一个含有几千人的邮箱列表,将客户请求的信息泄漏给几千人,或是让几千人收到不相干的邮件,应该都不是你原意见到的事。因此,在实际回信之前,最好先检查寄件人地址是否为owner-list或list-request之类的形式。此外,还有一些地址恐怕也是你不想回复的,像postmaster、daemon、majordomo等。你的程序应该将自己的信封地址设成空字符串,以免造成邮件循环。许多邮件列表会利用precedence:标题栏来注明它自己。它们通常使用bulk之类的值来表示邮件的性质。你的回信程序应该要检查precedence:标题栏的值,如果发现bulk、list或junk之类的字样,就不必回信了。最后,确定你的程序能记录每封来信的处理状况。一旦postfix将邮件托付给你的程序,你的程序就有检查错误的责任,并为管理员提供可以在事后追查问题的线索。
在虚拟网域假设邮件列表管理系统
第二各例子,我们要示范如何在虚拟网域上设置一个邮件列表。postfix与MLM之间的连接是通过别名文件:利用别名文件的:include;机制来展开列表,并将管理用途的别名对应到实际地址与MLM管理程序。然而,只有local MDA才会处理系统的别名文件,virtual MDA没有这方面的功能。虚拟邮件列表的原理,是在本地网域下创建列表的相同版本,这各本地版本仅供系统内部使用,外界用户所用的仍是虚拟地址,他们并部知道本地版本的存在。在决定本地版本的名称时,我们可设法将虚拟名称包含在内,以便容纳同系统上的其他虚拟网域列表

Posted in Linux | Leave a comment

CPU明明8个核,网卡为啥拼命折腾1号核?[转]

中断机制
我是 CPU 一号车间的阿 Q,我又来了!
我们日常的工作就是不断执行代码指令,不过这看似简单的工作背后其实也并不轻松。
咱不能闷着头啥也不管一个劲的只管执行代码,还得和连接在主板上的其他单位打交道。
经常保持联系的有键盘、鼠标、磁盘,哦对,还有网卡,这家伙最近把我惹到了,待会再说这事儿。
原以为内存那家伙已经够慢的了,没想到跟上面这几位通个信比他更慢,咱 CPU 工厂的时间一刻值千金,不能干等着,耽误工夫。后来厂里一合计,想了个叫中断的办法。
在我们车间装了个大灯,这些单位想联系我们办事儿,就先给我们发一个中断信号,大灯就会自动亮起。
我们平时工作执行代码指令的时候,每执行一条指令就会瞅一眼看看大灯有没有亮起来。
一旦发现灯亮了,就把手头的工作先放一边,去处理一下。
我们记性很差的,等会处理了完了还得回来接着原来的活继续干,为了等会回来还能接的起来,走之前得把当前执行的这个线程的各个寄存器的值,执行到哪里了等等这些信息都保存在这个线程的栈里去。
不过有时候我们在执行非常重要的事情的时候,就不想被他们打断。于是我们又在车间里那个 eflags 寄存器中设置了一个标记,如果是 1 我们才允许被打断,如果是 0 那就算天王老子找我们也不管了。
哦不对,还有一种不可以屏蔽的中断 NMI,走得是绿色通道。不过我可不期望有这种事情发生,因为一般都没有好事,不是电源断电就是温度过高,或者总线出了错误等这之类严重的事情。
8259A PIC
还有一个问题,找我们办事儿的单位有很多,我们得要区分开来,到底是谁来消息了,而且要是他们一起来找,按什么样优先级顺序处理,也是一件头疼的事情。
为此,厂里单独组建了一个全资的子公司来负责这事儿,他就是可编程中断控制器 PIC,外号 8259A,其他单位想联系我们都得通过这个 PIC,我们只需要和 PIC 进行对接就可以了。
我们给办事单位都分配了一个编号,叫做中断向量。我们还准备了一个表格叫中断描述符表 IDT,表格里记录了很多信息,其中就有处理这个中断号对应的函数地址。
我们找 PIC 拿到编号后就执行处理函数就 OK 了。
这个表格有点大,足足有 256 项,咱 CPU 车间空间有限,放不下,就把它放在内存那家伙那里了,为了能快速找到这个表,专门添置了一个叫 idtr 的寄存器指向这个表格。
其实除了中断,我们在执行指令的时候如果遇到了异常情况,也会去这个表里执行异常处理函数,最常见的比如遇到了除数是 0,内存地址错误等等情况。
这种情况下,我们必须主动放下手里的活,去处理异常,所以我们也说异常是同步的,而中断不知道什么时候发生,所以是异步的。
APIC
8259A 干的挺不错的,不过后来咱们厂扩大规模,从单核 CPU 变成了多核,他就有点应付不过来了。
终于有一天,厂里召开会议,把 8259A 给撤了,成立了一个新的全资子公司叫高级可编程中断控制器 APIC,名字就多了个高级两个字,干的活还是一样的。
不过你还别说,这两个字还真不是吹嘘,比 8259A 不知道高到哪里去了。
这个 APIC 的新公司一上台,就成立了两个部门,一个叫 I/O APIC,负责接待那些要找我们办事儿的单位,一个叫 Local APIC,以外包的形式入驻到我 CPU 的各个车间工作,因为就挨着我们办公,所以取名叫 Local。
I/O APIC 收到中断信号以后,根据自己的策略就分发到对应的 Local APIC,咱们八个车间就可以专心处理了,为我们省了不少事儿。
不仅如此,通过这个外包团队,我们 8 个车间还能向彼此发起中断请求,我们把这个叫做处理器间中断 Inter-Processor Interrupt,简称 IPI。
中断亲和性
每当网络中有数据包到来,网卡那家伙就发送一个中断消息过来,告诉我们去处理。
不过最近不知道怎么回事,网络数据量激增。咱们厂里明明有 8 个车间,他非得一个劲的只给我们发消息,搞得我们手头的工作老是被打断,忙得不可开交。
终于,我忍不住了,去找网卡那家伙理论了一番。不过他告诉我,这也不能怪他,分发给谁处理,那是 APIC 在负责。
想想也是,回头我就去了 APIC 那里,要求他们分摊一点给别的车间处理。
APIC 表示这他们做不了主,得让厂里来决定。
没过几天,厂里开了个会,参会的有各车间代表、APIC 负责人,还请了操作系统那边的相关代表过来。
会上,大家为了此事争执不休。
二号车间虎子:“阿 Q,谁叫你们一号车间是 Bootstrap Processor,你们就多辛苦一点嘛”。
三号车间代表:“你这话说的不合适,大家是一个 Team,要互相帮助!要不这样,既然有这么多单位要联系我们,咱就分下工,比如一号车间负责网卡,二号负责磁盘,我们三号负责键盘,以此类推。”
五号车间代表:“你想的倒是挺美哦,键盘一天能发多少中断,网卡一天要发多少中断,你净挑轻松的干。这样吧,咱就用随机分发进行负载均衡你们觉得怎么样?”
八号车间代表:“随机个啥啊,多麻烦,依我看呐咱 8 个车间就轮流来呗。”
这时,领导问操作系统代表有没有什么建议。
这代表站起身来,推了推眼镜说到:“几位有没有听过线程的 CPU 亲和性?”
大家都摇了摇头,问到:“这是个什么意思?”
“就是有些线程想绑定在你们之中的某一个核上面执行,不希望一会儿在这个核执行,一会儿在那个核执行。”
我接过他的话:“好像是有这么回事儿,之前有遇到过,有个线程一直被分配到我们一号车间,不过我们对这个不用关心吧,执行谁不是干活啊,对我们都一个样。”
代表摇了摇头,“唉,这可不一样!你们每个核的一二级缓存都是自己在管理,要是换到别的核,这缓存多半就没用了,又得重新来建立,这换来换去的岂不是瞎耽误功夫嘛!对于一般的线程他们倒是不关心,但是有些线程执行大量的内存访问和运算处理,又对性能要求很高的话,那就很在意这个问题了。”
我们几个都恍然大悟,纷纷点头。
虎子起身问到:“那你们是如何实现这个亲和性的呢?这跟我们今天的会议又有什么关系呢?”
代表继续回答说到:“我先回答你的第一个问题。线程调度是我们操作系统完成的工作,我们提供了 API 接口,线程通过调用这些接口表明自己的亲和性意愿,我们在调度的时候就能按照他们的意愿把线程分配给你们来执行。”
代表喝了一口水接着说到:“我再回答你的第二个问题。既然线程可以有亲和性,那中断也可以按照这个思路来分发啊!APIC 默认有一套分发策略,但是也提供亲和性的设置,可以指定谁哪些核来处理,这样不用把规矩定死,灵活可变,岂不更好?”
刚说完,会议室门口突然出现一年轻少年,挥手将操作系统代表唤了出去。
接下来,我们详细讨论了这种方案的可行性,最后大家一致决定,就照这么办。
我们一起提出了一个叫中断亲和性的东西,操作系统那边提供一个可配置的入口 smp_affinity,可以通过设置各处理器核的掩码来决定中断交由谁来处理,APIC 回去负责落地支持。
有了这套方案,再遇到网络高峰期,咱们一号车间的压力就有办法缓解了。
我们刚刚达成一致,操作系统代表返回会议室,神色凝重的说到:“不好意思各位,操作系统那边有点事情需要赶回去处理一下,先走一步了。”
随着网卡的一声中断,一个新的数据包来到了这片土地。帝国网络部新来的年轻人显然没有意识到危险的到来······
太慢不能忍!CPU 又拿硬盘和网卡开刀了!
总线技术
我是 CPU 一号车间的阿 Q,最近为了一件事儿搞得我挺烦的。
当初我们 CPU 工厂刚刚来到主板上建厂时,那时候主板上的单位还不多,跟我们打交道最多的就是内存那家伙了。
后来,键盘、鼠标、硬盘、网卡、声卡、显卡等等设备纷纷入驻主板,这块土地变得越来越热闹起来。
不过,他们的到来并没有影响我们的地位,毕竟我们是中央处理器,所有人都得听我们指挥。
为了和主板上这些家伙们通信,我们花了重金铺了一条线路,主板上家家户户都连上了这条线路,我们把它叫做总线,虽然说是一条,但实际上它包含了传输数据的数据总线,传输地址的地址总线和进行控制管理的控制总线。
这样一来,各单位就能一起聊天了。不过这线路是共用的,大家不能都一起传数据,那就乱套了。
为了统一管理,我们设立了一个新的单位叫总线控制器,这个单位来统一管理总线,大家要通信就得找它申请,这就叫做总线仲裁。
不过啊,主板上的单位之间的速度还是千差万别的,像内存就比硬盘、网卡这些单位快多了(当然,跟我们 CPU 车间的工作速度那还是不能比)。
不仅如此,不同单位他们的接口还千差万别,用一套总线矛盾就日益明显了,后来就变成了多级总线,让慢的跟慢的玩,快的跟快的玩,最后大家再用一个东西把不同总线连接起来,这个东西就是桥!
主板上后来出现了两个著名的桥,一个离我们 CPU 很近的叫北桥,内存那家伙和我们通信就会经过它,另一个离我们远一点的叫南桥,那些慢一些的 I/O 设备就通过南桥接进来。
再后来,随着我们 CPU 工厂的壮大,直接把北桥收购了,现在变成了我们厂里的一个部门了。
PIO 模式
现在我们可以和这些 I/O 设备通信了,就拿硬盘来说吧,它有 I/O 端口,我们提供了 in 和 out 两条指令,就可以对它进行读写数据了。
这种通信的方式叫做可编程输入输出模型,Programming Input/Output Model,简称 PIO。
我们是整个主板上的核心,俗话说得好,能力越大,责任越大,但有时候真心觉得有点累。
随着越来越多的设备接入主板,越来越多的程序需要等待我们去执行,工作量大的压的我们喘不过气来。
尤其是随着技术进步,我们 CPU 工厂的速度越来越快,与硬盘的读写速度之间的差距越来越拉大,我们还用这种方式通信就太浪费我们的时间了。
DMA 技术
这几天,我们几个车间的 Leader 私下聚在一起讨论起这个事情来。
“阿 Q,你不觉得现在我们花了太多时间再读写硬盘上了吗,这家伙慢不是他的错,扯我们后腿这就是他的错了啊。传输一次数据,我们要执行好多次 I/O 端口读写,我们宝贵的时间都浪费在这上面了!”,二号车间的虎子一脸幽怨的说到。
“嗨,我最近也为这事发愁呢,程序越来越多,读写硬盘的时间越来越多了,尤其是那个叫 MySQL 的,老让我访问硬盘,可累死我了。”
没想到我俩都憋了一肚子苦水呢。
这时,平日里爱拍老板马屁的八号车间老大说了一句话:“你们说的问题确实存在,这工作太没技术含量了,就是个体力活嘛,要不咱给老板说说,让他外包出去吧。”
我俩一听,妙啊,要是能把这体力活外包出去,那可简直太好了,我们就可以专心做我们的专职工作了。
“你跟老板平时走得近,这事你去说吧”,我给虎子使了个眼色,一起撺掇老八去说这事。
“行,我去就我去”。
还别说,领导立马就同意了这个想法,毕竟能提高我们的工作效率,他自然是举双手欢迎。
没过多久,就成立了一个外包团队,独立出我们厂子,专门来负责这件事。
和我们 CPU 一样,他们也提供了几个寄存器,传输数据的时候,只需要设置一下这些寄存器的内容,告诉他们要传输哪里的数据,从哪到哪,长度是多少,接下来的事情我们就不用操心了,交由他们来完成。
我们就可以腾出功夫做其他事情,等数据传输完毕了,他们再用中断的方式告诉我们,我们直接去处理就好了,省去了让我们亲自去搬运的过程,真是爽的飞起!
后来,我们给这项技术也取了一个名字,叫 Direct Memory Access,直接存储器访问,简称 DMA,这个外包团队就是 DMAC,DMA 控制器。
DMA 全面开花
前几天的月总结会上,领导表扬了老八,说多亏他的建议让厂里的生产效率大大提升。早知道,当初就不撺掇老八去跟老板提建议了,我自己去。
正想着走神,突然想到了一个问题,这一次我打算抓住机会挣个表现。
“老板,这个 DMA 技术好是好,但现在只能用于硬盘哦。最近网卡那家伙数据包也挺多的,我花了好多时间去把数据包从网卡读取到内存中,又低效又没有技术含量,可不可以把这技术推广到网卡上啊?”,我起身说到。
老板点了点头,若有所思。
二号车间虎子见状也起身说到:“老板,除了硬盘和网卡,显示器也有这个需求。我经常要疲于奔波于把内存数据传输到显示器,也是劳神劳力,建议 DMA 技术也推广到显示器呢。”
老板听完,皱了皱眉头说到,“这个不同设备之间的差别还是挺大的,没法通用。难不成我们要为每个设备成立一个外包团队?这成本有点高啊···”
老板果然还是老板,还是把成本考虑在第一位。
这时,爱拍马屁的老八又说话了,“老板说的是。我倒是有个建议,这个 DMA 推广到网卡、显示器这些单位也可以,不过让他们自己掏钱来增加 DMAC,按照他们各自不同的需求来做。咱们不能当这冤大头。”
老板一听,喜形于色,大声叫好!
就这样,很快我们就把这项技术推广了出去,主板上以网卡、显示器、摄像头为首的那些个单位为了不落后于人,纷纷拥抱变化,集成了 DMAC。
我们得到了彻底的解放,再也不用做枯燥的搬运工了~
彩蛋:“阿 Q,听说了吗,最近 Linux 帝国新成立了一个公司,居然绕过我们 CPU 就能把数据从网卡写入硬盘中”。
“不可能啊,至少得经过我们拷贝一下吧”,“根本不用,他们号称是零拷贝技术”。
Posted in IT运维 | 评论关闭

SSH服务器端/etc/ssh/sshd_conf配置文件详解

[root@u0704-t5-test-shaoew1 ~]$cat /etc/ssh/sshd_config
#Port 22                                          监听端口,默认监听22端口   【默认可修改】
#AddressFamily any                        IPV4和IPV6协议家族用哪个,any表示二者均有
#ListenAddress 0.0.0.0                   指明监控的地址,0.0.0.0表示本机的所有地址  【默认可修改】
#ListenAddress ::                            指明监听的IPV6的所有地址格式
# The default requires explicit activation of protocol 1
#Protocol 2                                      使用SSH第二版本,centos7默认第一版本已拒绝
# HostKey for protocol version 1      一版的SSH支持以下一种秘钥形式
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2                  使用第二版本发送秘钥,支持以下四种秘钥认证的存放位置:(centos6只支持rsa和dsa两种)
HostKey /etc/ssh/ssh_host_rsa_key               rsa私钥认证 【默认】
#HostKey /etc/ssh/ssh_host_dsa_key            dsa私钥认证
HostKey /etc/ssh/ssh_host_ecdsa_key          ecdsa私钥认证
HostKey /etc/ssh/ssh_host_ed25519_key      ed25519私钥认证
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024        主机秘钥长度
# Ciphers and keying
#RekeyLimit default none
# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV                   当有人使用ssh登录系统的时候,SSH会记录信息,信息保存在/var/log/secure里面
#LogLevel INFO                                  日志的等级
# Authentication:
#LoginGraceTime 2m                           登录的宽限时间,默认2分钟没有输入密码,则自动断开连接
#PermitRootLogin no
PermitRootLogin yes                            是否允许管理员直接登录,’yes’表示允许
#StrictModes yes                                 是否让sshd去检查用户主目录或相关文件的权限数据
#MaxAuthTries 6                                  最大认证尝试次数,最多可以尝试6次输入密码。之后需要等待某段时间后才能再次输入密码
#MaxSessions 10                                 允许的最大会话数
#RSAAuthentication yes
#PubkeyAuthentication yes
# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys                 服务器生成一对公私钥之后,会将公钥放到.ssh/authorizd_keys里面,将私钥发给客户端
#AuthorizedPrincipalsFile none
#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don’t trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don’t read the user’s ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication yes                    是否允许支持基于口令的认证
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no     是否允许任何的密码认证
# Kerberos options                                   是否支持kerberos(基于第三方的认证,如LDAP)认证的方式,默认为no
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
#KerberosUseKuserok yes
# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials no
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
#GSSAPIEnablek5users no
# Set this to ‘yes’ to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of “PermitRootLogin without-password”.
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to ‘no’.
# WARNING: ‘UsePAM no’ is not supported in Red Hat Enterprise Linux and may cause several
# problems.
UsePAM yes
#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes                    是否允许x11转发,可以让窗口的数据通过SSH连接来传递(请查看ssh -X 参数):#ssh -X  user@IP
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
UsePrivilegeSeparation sandbox # Default for new installations.
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#ShowPatchLevel no
#UseDNS yes              是否反解DNS,如果想让客户端连接服务器端快一些,这个可以改为no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none
# no default banner path
#Banner none
# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
# override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server                    支持 SFTP ,如果注释掉,则不支持sftp连接
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server
AllowUsers user1 user2                登录白名单(默认没有这个配置,需要自己手动添加),允许远程登录的用户。如果名单中没有的用户,则提示拒绝登录
Posted in Linux | 评论关闭