版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/cdnight/article/details/81078191
前言
在一个自动化编译部署系统里面，使用scp命令远程复制文件是很正常的,然而使用jenkins出现了该问题。
环境还原
在一个pipeline任务里面，编译流水任务代码如下：
#!/usr/bin/env groovy
pipeline{
agent any
environment {
REVISION = "0.0.${env.BUILD_ID}"
}
options{
disableConcurrentBuilds()
skipDefaultCheckout()
timeout(time: 1, unit: 'HOURS')
timestamps()
}
parameters{
choice(name: 'build_env', choices: 'dev\ntest\nproduct\n', description: '请选择构建的环境')
}
stages{
stage ('Initialize') {
steps {
script {
currentBuild.displayName = "${REVISION}"
}
sh '''
echo "任务初始化..."
echo "构建版本revision:${REVISION}"
'''
sh '''
echo "项目检出...."
'''
checkout([$class: 'SubversionSCM',
additionalCredentials: [],
excludedCommitMessages: '',
excludedRegions: '',
excludedRevprop: '',
excludedUsers: '',
filterChangelog: false,
ignoreDirPropChanges: false,
includedRegions: '',
locations: [[credentialsId: 'e522721e-4a9a-467c-b154-acb803d8afb0',
depthOption: 'infinity',
ignoreExternalsOption: true,
remote: 'svn://127.0.0.1:3690/MicroBaseModule']],
workspaceUpdater: [$class: 'UpdateUpdater']])
}
}
stage ('Build') {
steps {
echo "您选择了：${params.build_env}"
echo '构建阶段....'
echo '构建部署 MicroBaseApi子项目...'
sh "mvn clean deploy -e -f MicroBaseModule/MicroBaseApi/pom.xml -P ${params.build_env}"
echo '构建打包MicroBaseApp子项目...'
sh "mvn clean package -e -f MicroBaseModule/MicroBaseApp/pom.xml -P ${params.build_env}"
}
}
stage ('Deploy') {
steps {
echo '发布阶段....'
script
{
if (params.build_env == 'test') {
echo '=====》》》测试环境进行远程发布。'
sh '''
scp /var/lib/jenkins/workspace/MicroBase/MicroBaseModule/MicroBaseApp/target/MicroBaseApp-Build.zip [email protected](你的远程机器地址):/data/packages/test/MicroBaseApp/MicroBaseApp-Build-${REVISION}.zip
'''
}
if(params.build_env=='product'){
echo '=====》》》生产环境进行远程发布。'
sh '''
scp /var/lib/jenkins/workspace/MicroBase/MicroBaseModule/MicroBaseApp/target/MicroBaseApp-Build.zip [email protected](你的远程机器地址):/data/packages/product/MicroBaseApp/MicroBaseApp-Build-${REVISION}.zip
'''
}
else {
echo '=====》》》 默认（开发）环境进行远程发布。'
sh '''
scp /var/lib/jenkins/workspace/MicroBase/MicroBaseModule/MicroBaseApp/target/MicroBaseApp-Build.zip [email protected](你的远程机器地址):/data/packages/dev/MicroBaseApp/MicroBaseApp-Build-${REVISION}.zip
'''
}
}
}
}
}
post {
always {
echo '构建结束...'
}
success {
echo '恭喜您，构建成功！！！'
}
failure {
echo '抱歉，构建失败！！！'
}
unstable {
echo '该任务已经被标记为不稳定任务....'
}
changed {
echo ''
}
}
}执行结果：
异常。
检查及诊断
资料搜集及参考：
Can’t su to user jenkins after installing Jenkins
ASK:
I've installed jenkins and I'm trying to get into a shell as Jenkins to add an ssh key. I can't seem to su into the jenkins user:
[root@pacmandev /]# sudo su jenkins
[root@pacmandev /]# whoami
root
[root@pacmandev /]# echo $USER
root
[root@pacmandev /]#
The jenkins user exists in my /etc/passwd file. Runnin su jenkins asks for a password, but rejects my normal password. sudo su jenkins doesn't seem to do anything; same for sudo su - jenkins. I'm on CentOS.ANSWER
down vote
accepted
jenkins is a service account, it doesn't have a shell by design. It is generally accepted that service accounts shouldn't be able to log in interactively.
I didn't answer this one initially as it's a duplicate of a question that has been moved to server fault. I should have answered rather than linked to the answer in a comment.
if for some reason you want to login as jenkins, you can do so with: sudo su -s /bin/bash jenkinsJenkins Host key verification failed
问题：
I have a problem with jenkins, setting "git", shows the following error:
Failed to connect to repository : Command "git ls-remote -h https://[email protected]/person/projectmarket.git HEAD" returned status code 128:
stdout:
stderr: fatal: Authentication failed
I have tested with ssh:
[email protected]:person/projectmarket.git
This is error:
Failed to connect to repository : Command "git ls-remote -h [email protected]:person/projectmarket.git HEAD" returned status code 128:
stdout:
stderr: Host key verification failed.
fatal: The remote end hung up unexpectedly
I've also done these steps with "SSH key".
Login under Jenkins
sudo su jenkins
Copy your github key to Jenkins .ssh folder
cp ~/.ssh/id_rsa_github* /var/lib/jenkins/.ssh/
Rename the keys
mv id_rsa_github id_rsa
mv id_rsa_github.pub id_rsa.pub
but still not working git repository in jenkins.
thanks by help!.回答1：
Change to the jenkins user and run the command manually:
git ls-remote -h [email protected]:person/projectmarket.git HEAD
You will get the standard SSH warning when first connecting to a new host via SSH:
The authenticity of host 'bitbucket.org (207.223.240.181)' can't be established.
RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)?
Type yes and press Enter. The host key for bitbucket.org will now be added to the ~/.ssh/known_hosts file and you won't get this error in Jenkins anymore.
shareimprove this answer
answered Mar 4 '13 at 6:54
ctc
1,77511116
5
show this: Permission denied (publickey). fatal: The remote end hung up unexpectedly – A. M. Mérida Mar 4 '13 at 8:40
6
Right, but that's an entirely different error. Now you have to go add your public key to the repository over at bitbucket.org. – ctc Mar 4 '13 at 16:57
4
See step 6 here: confluence.atlassian.com/display/BITBUCKET/Set+up+SSH+for+Git – ctc Mar 4 '13 at 16:58
1
+1 for "worksforme", had the exact same problem. Created id_rsa for the proper user, chmod-ed to jenkins, added the public key, still did not work. Trying git as sudo -u jenkins yielded the knonwn_hosts file, fixing the problem. – sibidiba Jun 13 '13 at 14:11
2
You need to run it as the user that is running Jenkins. On most systems, one typically runs it as a separate user (e.g. a 'jenkins' user). Hence, you would need to switch to that user to ensure that the address for bitbucket.org is added to ~/.ssh/known_hosts. – ctc Feb 4 '14 at 2:41回答2：
Jenkins is a service account, it doesn't have a shell by design. It is generally accepted that service accounts. shouldn't be able to log in interactively.
To resolve "Jenkins Host key verification failed", do the following steps. I have used mercurial with jenkins.
1)Execute following commands on terminal
$ sudo su -s /bin/bash jenkins
provide password
2)Generate public private key using the following command:
ssh-keygen
you can see output as ::
Generating public/private rsa key pair.
Enter file in which to save the key (/var/lib/jenkins/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
3)Press Enter --> Do not give any passphrase--> press enter
Key has been generated
4) go to --> cat /var/lib/jenkins/.ssh/id_rsa.pub
5) Copy key from id_rsa.pub
6)Exit from bash
7) ssh@yourrepository
8) vi .ssh/authorized_keys
9) Paste the key
10) exit
11)Manually login to mercurial server
Note: Pls do manually login otherwise jenkins will again give error "host verification failed"
12)once manually done, Now go to Jenkins and give build
Enjoy!!!
Good Luckjenkins集成git，构建项目报错，做了ssh的 认证，还是提示 Host key verification failed
部分回答摘抄：
经过努力，终于解决了这个问题。解决方法是，在Jenkins目录下的.ssh目录里面生成ssh的认证，执行ssh-keygen ,然后将生成的 id_rsa.pub 添加到GitHub的ssh认证。然后构建项目时，配置ssh认证，添加证书，即用户名。
解决思路1
从这么多的资料中可以获取到的一点信息及推测是：
在jenkins进行自动化任务时，调用sh脚本，要用到ssh之类的权限时候，需要先sudo su到某个角色譬如jenkins（系统用户账户），然后以jenkins的名义调用脚本命令---这时候需要给jenkins给予脚本运行权限，譬如，这样调用---sudo su -s /bin/bash jenkins，
在调用scp命令时候，为了不需要填入密码而直接执行，你需要：
2)Generate public private key using the following command:
ssh-keygen
you can see output as ::
Generating public/private rsa key pair.
Enter file in which to save the key (/var/lib/jenkins/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
3)Press Enter --> Do not give any passphrase--> press enter
Key has been generated
4) go to --> cat /var/lib/jenkins/.ssh/id_rsa.pub
5) Copy key from id_rsa.pub
6)Exit from bash
7) ssh@yourrepository
8) vi .ssh/authorized_keys
好了，该步骤中文解释清参考：
https://blog.csdn.net/qq_27528801/article/details/51539869
https://blog.csdn.net/nfer_zhuang/article/details/42646849
好了，现在来尝试思路1，看看能不能解决该问题。
思路1实践
检查有没有jenkins账号：
sudo su jenkins
没有，则新建jenkins账号：
adduser jenkins
测试能不能变更账号：
sudo su jenkins结果：
….放错服务器了，不过整体思路依然一样，下面我换回去。。
难怪没有jenkins账号了，安装jenkins时候应该有的，下面换回jenkins所在服务器，如下：
有jenkins账号，所以：
1、生成ssh密钥：
ssh-keygen
ps：这是试验性质，所以所有步骤一切从简，于是都偷懒直接按enter好了，用默认的，连密码也不设置了：
ps：出现already exists的原因是之前博主已经给root账号生成了一次ssh 的密钥用来测试scp无密码传输了，这是正常的，别管了。
ps2：如果不想覆盖的话，在第一步选择保存位置时候就填别的位置，譬如：/var/lib/jenkins/.ssh/id_rsa
2、复制key到需要传输文件的目标机器（这里默认为applicationServer）：
打开id_rsa.pub，复制内容：
vim /root/.ssh/id_rsa.pub看到了：
请点击复制，然后ssh到目标机器：
vim /root/.ssh/authorized_keys
好了，在原本的pipeline代码里面加上
sudo su -s /bin/bash jenkins这样的：
然后执行：
构建失败，继续跟进及解决：
无意中看到这篇文章，看来jenkins系统本身有bug的。
su jenkins本身是切换失败的，
可以看到切换不成功依然是root账号的。
好了，我们来解决这个问题。
网上一搜，找到了解决办法：
/etc/passwd文件中的/bin/bash被yum安装的时候变成了/bin/false.
1
然后我执行cat /etc/passwd命令，果然被改成了/bin/false
cat /etc/passwd
1
接着执行sudo vim /etc/passwd命令,把false改为bash
sudo vim /etc/passwd
1
修改完毕后，执行su jenkins命令。 sudo vim /etc/passwd
改为：
然后执行：
su jenkins
…又有问题了：
结果新的问题又来啦
当我切换到jenkins用户后，命令提示符的用户名不是jenkins而变成了
-bash-4.1#
网上一查，原因是在安装jenkins时，jenkins只是创建了jenkins用户，并没有为其创建home目录。所以系统就不会在创建用户的时候，自动拷贝/etc/skel目录下的用户环境变量文件到用户家目录，也就导致这些文件不存在，出现-bash-4.1#的问题了
以下命令是在切换到jenkins用户下执行的！（只是用户现在显示的是-bash-4.1）
这个时候呢，参考网上的做法我执行下面步骤：
①vim ~/.bash_profile
执行上面的命令，即使没有.bash_profile文件，linux会自动创建。
②然后再添加这句
export PS1='[\u@\h \W]\$'
1
PS1：命令行提示符环境变量
1
2
具体可以参考：http://zhidao.baidu.com/link?url=rMCdJazfyycZlY5xN-peNO-pUwTcPMROlXvrZZjE2EV9fDA7513e1JsiGXiWPlBWgArqrHNGu4yBvwNSY0Y79_
③我们最后再刷新.bash_profile文件，使其起作用
source ~/.bash_profile首先：
然后：
source ~/.bash_profile
好了，可以正常运行了。
执行jenkins任务：
还是错了。。。
原因为：
网上的解释之一：
解释一二没看出大区别，不过解释2详细，按照解释2来执行：
sudo: no tty present and no askpass program specified
由于帐号并没有开启免密码导致的
假设当前帐号为abc
切换到root下
1 打开sudoers
vi /etc/sudoers
2 添加免密码
abc ALL = NOPASSWD: ALL
文章标签： linux present and no askpa靠谱的解释：
在Jenkins的使用过程中，如果在脚本中使用到sudo命令，有可能出现如下所示的错误：
sudo: no tty present and no askpass program specified
这是因为Jenkins服务器在执行sudo命令时的上下文有误，导致这个命令执行的异常。
解决方案：
在Jenkins宿主服务器上运行如下命令
$ sudo visudo
在文件的末尾加上一行
jenkins ALL=(ALL) NOPASSWD: ALL
保存文件（注意保存的时候修改文件名，文件名后缀不要加上默认的.tmp，即可覆盖原文件）
Ctrl+O
退出编辑
Ctrl+X
重启Jenkins服务
$ /etc/init.d/jenkins restart
最后，重新执行构建任务，不会出现先前的错误。
PS：如果误操作修改了/etc/sudoers的权限来修改上述文件，则会导致如下所示的错误：
sudo :/etc/sudoers is world writable
sudo : no valid sudoers source found, quitting
sudo : unable to initialize poling plugin
这是Linux的一种保护机制。因此，如果出现上述误操作，则需要执行如下命令来解决：
$ pkexec chmod 0440 /etc/sudoers好，试试：
sudo visudo
后面加上：
jenkins ALL=(ALL) NOPASSWD: ALL
/etc/init.d/jenkins restart重启，然后测试一下是不是还要密码：
测试成功，免密登录。
再执行jenkins任务：
虽然还是出错，不过，切换到jenkins账户已经没问题了，就是scp有问题而已。
接下来，应该要进行的是免密远程ssh登录了，按照前面英文的提示。
当然，各位可以看看这篇资料：CentOS如何开启ssh远程连接
下面是主要内容的引用：
假设VPS采用centos，再假设用较新版本6.5。
VPS上可能没有安装桌面，但一般来说都会安装ssh，并且防火墙默认开放22端口。
那就从ssh开始。
# 安装ssh，默认已安装好
# yum install ssh
# 启动ssh服务器端
# service sshd start
# chkconfig sshd on
ssh登陆
如果本地端是Linux
# ssh [email protected]
其中root表示的是登录用户名，192.168.1.1为主机的IP地址，当然也可以使用主机名、域名来指代IP地址。
# ssh 192.168.1.1
则会以当前客户端的用户名进行登录。
ssh无密码登录
但是每次输入密码登录十分麻烦，有没有一种方式可以让服务器能够确定我的身份，无需输入密码可以直接通过认证？
ssh除了使用密码验证外，还提供了一种公私密钥的验证方式。客户端生成一个私钥，并生成一个与之对应的公钥，然后将公钥上传到服务器上。下面是Linux示例。
在客户端生成私钥、公钥（注意，在客户端完成）：
# ssh-keygen -t rsa
-t指定要创建的密钥类型，默认就是rsa了，所以只执行ssh-keygen是一样的。
期间会提示你输入你私钥的加密密码。如果需要完全脱离密码，此处可留空，直接回车，否则以后每次连接需要本地解锁。
完成后，会当前用户的主目录下的~/.ssh/路径下生成两个文件id_rsa与id_rsa.pub分别是私钥与公钥。
接下来，要把生成的公钥上传到服务器上，同样还是在客户端执行以下的代码。
# ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]
其中root可以修改为你想要自动登录的服务器端用户名，192.168.1.1修改为你的VPS主机名或IP地址。
最后，ssh登录远程服务器。
# ssh [email protected]
此时就不需要密码就可以登录了。重新生成ssh-keygen，看看行不行：
ssh-keygen
估计，之前生成的keygen都是root的。。现在才是jenkins账户的。。。。。。
然后，
cat /var/lib/jenkins/.ssh/id_rsa.pub请复制一下这段密码：
然后，测试ssh远程登录到目标机器：
ssh -p 你的ssh端口（默认是22） 你要登录的账号（通常为root）@你的远程ip地址结果如下：
都要输入密码啊，我们要做到不输入密码就可以远程登录，key密钥是时候用了。
好了，具体到我们这里，这样来用：
#带端口的：
ssh-copy-id -i /var/lib/jenkins/.ssh/id_rsa.pub -p 你的端口号（通常为22） root@目标ip地址
#不带端口的：
ssh-copy-id -i /var/lib/jenkins/.ssh/id_rsa.pub root@目标ip地址
结果和测试：
好了，至此，在a机器上面使用jenkins账户免密ssh登录到b机器已经部署成功，scp大体如此。
再继续执行jenkins的pipeline任务:
好了，我们到目标机器看看有没有接收到这份文件：
好了，自动化部署中的jenkins调用自己账户，免密码上传文件已经解决
结语
估计目前专业的运维还是少了，很多情况都是码农在兼任的，网上关于这样的文章很多，不过要一步一步解决还真的是很多问题的，没有专业的linux知识及运维知识估计也是很呛了。
还有些压根是坑人的。
就拿jenkins来说，jenkins安装以后会新建一个jenkins账户，然而没办法正常切换jenkins这个账号，没办法在jenkins的pipeline脚本直接运行这种问题在jenkins搭建的文章中无一体验，可见都是摸着石头过河的。
所以，运维这一块也不轻松。