I am attempting to run a PS script on a remote host that uses pssession to connect to another host.
For various reasons I don't have complete access to the remote host where the script will be ran.
I have copied my known_hosts file from my machine to the remote machine.
Will this bypass the check for key fingerprint when it is connecting to a machine for the first time ? I have connected to the destination machine locally so its information is in my known_hosts file.
Thanks
Related
I'm trying to copy task1.zip from my desktop /Users/myname/desktop if I pwd, to a remote server. I'm connected to the remote server via ssh. I would like to copy the file to /its/home/jt463/task1(pwd path from the directory) on the remote server.
I have used the command below in the terminal when I'm connected to the server via ssh and tried it on the terminal on my machine:
scp Users/myname/desktop/task1.zip username#inf900179.inf.susx.ac.uk:its/home/username/task1
Error that I get when I try to use the terminal that's connected to the remote server:
Users/jonatantibarovsky/desktop/task1.zip: No such file or directory
Error that I get when I try to use my local terminal:
ssh: connect to host inf900179.inf.susx.ac.uk port 22: Operation timed out lost connection
First scp to the intermediate server, using your credentials. Then, you should be able to scp from that server to the target.
I am trying to SSH into the server as part of the deployment job in CircleCI
ssh -oStrictHostKeyChecking=no $DEV_DROPLET_USER#$DEV_DROPLET_IP
I have my SSH private key for the user on this server loaded into CircleCI but everytime I run the job, I get this output
Warning: Permanently added '$host' (ECDSA) to the list of known hosts.
<$user>#<$host>'s password:
How can I stop it prompting me for the password?
I have added the SSH key for this user to the SSH Agent on the server (these instructions)
For a passwordless ssh connection, you must:
put the private ssh key into a file in the directory $HOME/.ssh/ on the client computer connecting to the server (example : $HOME/.ssh/MyServer)
copy the public ssh key into the file $HOME/.ssh/authorized_keys on the server
have writing permission on the file $HOME/.ssh/known_hosts on the client computer
The sshd service is normally already configured to accept key based authentication.
From the client computer, you can now do a passwordless connection ssh -i $HOME/.ssh/MyServer $DEV_DROPLET_USER#$DEV_DROPLET_IP
Of course, on the client computer your $DEV_DROPLET_USER must have appropriate permissions for accessing the ssh related files.
You don’t need to do anything with the ssh agent, on the client or on the server.
Late reply, but I hope it helps somebody else in the future.
Assuming you followed these instructions in the CircleCI docs, then the private key will automatically be copied to the machine being used by CircleCI when the add_ssh_keys step is run.
Make sure one the server you are trying to SSH into, the public key generated (in ~/.ssh/id_rsa.pub or something similar) is copied to the ~/.ssh/authorized_hosts file on the same server. This crucial step is what allows anybody with the private key (CircleCI) to be allowed into the server.
I'm sorry to have to ask this question, but I feel like I've tried every answer so far on SO with no luck.
I have my local machine and my remote server. Jenkins is up and running on my server.
If I open up terminal and do something like scp /path/to/file user#server:/path/to/wherever then my ssh works fine without requiring a password
If I run this command inside of my Jenkins job I get 'Host Key Verification Failed'
So I know my SSH is working correctly the way I want, but why can't I get Jenkins to use this SSH key?
Interesting thing is, it did work fine when I first set up Jenkins and the key, then I think I restarted my local machine, or restarted Jenkins, then it stopped working. It's hard to say exactly what caused it.
I've also tried several options regarding ssh-agent and ssh-add but those don't seem to work.
I verified the local machine .pub is on the server in the /user/.ssh folder and is also in the authorized keys file. The folder is owned by user.
Any thoughts would be much appreciated and I can provide more info about my problem. Thanks!
Update:
Per Kensters suggestion I did su - jenkins, then ssh server, and it asked me to add to known hosts. So I thought this was a step in the right direction. But the same problem persisted afterward.
Something I did not notice before I can ssh server without password when using my myUsername account. But if I switch to the jenkins user, then it asks me for my password when I do ssh server.
I also tried ssh-keygen -R server as suggested to no avail.
Try
su jenkins
ssh-keyscan YOUR-HOSTNAME >> ~/.ssh/known_hosts
SSH Slaves Plugin doesn't support ECDSA. The command above should add RSA key for ssh-slave.
Host Key Verification Failed
ssh is complaining about the remote host key, not the local key that you're trying to use for authentication.
Every SSH server has a host key which is used to identify the server to the client. This helps prevent clients from connecting to servers which are impersonating the intended server. The first time you use ssh to connect to a particular host, ssh will normally prompt you to accept the remote host's host key, then store the key locally so that ssh will recognize the key in the future. The widely used OpenSSH ssh program stores known host keys in a file .ssh/known_hosts within each user's home directory.
In this case, one of two things is happening:
The user ID that Jenkins is using to run these jobs has never connected to this particular remote host before, and doesn't have the remote host's host key in its known_hosts file.
The remote host key has changed for some reason, and it no longer matches the key which is stored in the Jenkins user's known_hosts file.
You need to update the known_hosts file for the user which jenkins is using to run these ssh operations. You need to remove any old host key for this host from the file, then add the host's new host key to the file. The simplest way is to use su or sudo to become the Jenkins user, then run ssh interactively to connect to the remote server:
$ ssh server
If ssh prompts you to accept a host key, say yes, and you're done. You don't even have to finish logging in. If it prints a big scary warning that the host key has changed, run this to remove the existing host from known_hosts:
$ ssh-keygen -R server
Then rerun the ssh command.
One thing to be aware of: you can't use a passphrase when you generate a key that you're going to use with Jenkins, because it gives you no opportunity to enter such a thing (seeing as it runs automated jobs with no human intervention).
I am trying log in to one of my projects at sagemath cloud using SSH (I am using OS X 10.10.1) after adding the local copy of the public key (~/.ssh/id_rsa.pub) to the authorized_keys file in the .ssh subdirectory of the project on the remote host, which is 162.222.176.40:
$ ssh <project id>#162.222.176.40
The authenticity of host '162.222.176.40 (162.222.176.40)' can't be established.
RSA key fingerprint is 3a:40:8e:77:88:7e:f8:68:0c:28:4a:32:f8:4a:4a:25.
Are you sure you want to continue connecting (yes/no)? yes
Is this as expected? I did check ~/.ssh/known_hosts and this host does not appear. I am guessing it will be added once I log in for the first time.
It's normal to see a message like that once upon first connecting to a server. If it asks if it's ok to continue connecting, just say "yes". That public key will then be added to your local ~/.ssh/known_hosts file (associated with that IP address or domain).
There's only a problem if you see this message every time you connect to a server. In that case, the problem might be that the given key is already in your local computer's ~/.ssh/known_hosts file, but is associated there with a different IP address or domain. Try removing that line of the file, or just clearing that file completely.
Now I want to run a script from a client machine which will ssh to a virtual machine guest on a host machine and start to run a shell command. I do not want to be prompted to input the password.
So firstly I try to do it to connect to the host. I copy the file id_rsa.pub in the .ssh folder from the client to the host's file called authorized_keys in the .ssh folder. Then when I
"ssh root#hostname"
It works fine and I do not need to input the password(note my client's account is not root).
Then I try the same thing to the virtual machine guest in the host. I copied the same file to the guest. I started the guest using qemu with option "-net user,vlan=0,hostfwd=tcp::5555-:22 " which will forward the requests to host 5555 port to guest's 22 port. Then in the client, I executed
" ssh -p 5555 root#hostname "
It fails. It shows that RSA key for the host has changed or something... Note that my guest's account is also root and I can use Putty to ssh to the guest by connecting to the 5555 port of the host. And I believe the file permission is also properly handled.
Does anyone have a clue :>
Yes, this is correct behavior.
When you get connected to the host system first time, the ssh at your client machine ask you if the machine with fingerprint bla-bla-bla really the one you are wanted to connect. You replied 'yes' and ssh at your client machine memorized the host name, IP and the fingerprint in the file ~/.ssh/known_hosts. Then during all subsequent connections it verifies that the fingerprint is not changed as a change is an indication that the authentication process requires your attention. There could be a few valid reasons of a mismatch:
you re-installed sshd at the remote host;
your host uses DHCP to get its IP and the IP got changed.
The case when you know precisely that the fingerprint should not change indicates to you an attempt to make you get into another system.
This mechanism aimed to make you sure that you are logged in to the system you are expected to log in.
In your case you first log into the system at IP a.b.c.d at port 22. Then you try to log in with the same IP a.b.c.d at port 5555. There is your VM behind this port that is having different fingerprint. So ssh complains.
The solution for your problem will be to log in to the host system and then from this remote shell session into VM. Also I would recommend you to generate another pair of public/private keys for this 'remote' connection. Thus when your private key kept at the host get compromised then your private key that is kept at your workstation remains valid.