Related
I'm getting the standard
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
error message. However, the system (Appworx) that executes the command (sftp I think, not that it matters) is automated and I can't easily accept the new key, even after checking with the third party vendor that it is a valid change. I can add a new shell script that I can execute from the same system (and user), but there doesn't seem to be a command or command-line argument that will tell ssh to accept the key. I can't find anything in the man page or on Google. Surely this is possible?
The answers here are terrible advice. You should never turn off StrictHostKeyChecking in any real-world system (e.g. it's probably okay if you're just playing on your own local home network – but for anything else don't do it).
Instead use:
ssh-keygen -R hostname
That will force the known_hosts file to be updated to remove the old key for just the one server that has updated its key.
Then when you use:
ssh user#hostname
It will ask you to confirm the fingerprint – as it would for any other "new" (i.e. previously unseen) server.
While common wisdom is not to disable host key checking, there is a built-in option in SSH itself to do this. It is relatively unknown, since it's new (added in Openssh 6.5).
This is done with -o StrictHostKeyChecking=accept-new.
WARNING: use this only if you absolutely trust the IP\hostname you are going to SSH to:
ssh -o StrictHostKeyChecking=accept-new mynewserver.example.com
Note, StrictHostKeyChecking=no will add the public key to ~/.ssh/known_hosts even if the key was changed.
accept-new is only for new hosts. From the man page:
If this flag is set to “accept-new” then ssh will automatically add
new host keys to the user known hosts files, but will not permit
connections to hosts with changed host keys. If this flag
is set to “no” or “off”, ssh will automatically add new host keys
to the user known hosts files and allow connections to hosts with
changed hostkeys to proceed, subject to some restrictions.
If this flag is set to ask (the default), new host keys will be
added to the user known host files only after the user has confirmed
that is what they really want to do, and ssh will refuse to
connect to hosts whose host key has changed.
The host keys of known hosts will be verified automatically in all cases.
Why -o StrictHostKeyChecking=no is evil?
When you do not check the host key you might land with an SSH session on a different computer (yes, this is possible with IP Hijacking). A hostile server, which you don't own can be then used to steal a password and all sort of data.
Accepting a new unknown key is also pretty dangerous.
One should only do it if there is an absolute trust in the network or that the server was not compromised.
Personally, I use this flag only when I boot machines in a cloud environment with cloud-init immediately after the machine started.
Here's how to tell your client to trust the key. A better approach is to give it the key in advance, which I've described in the second paragraph. This is for an OpenSSH client on Unix, so I hope it's relevant to your situation.
You can set the StrictHostKeyChecking parameter. It has options yes, no, and ask. The default is ask. To set it system wide, edit /etc/ssh/ssh_config; to set it just for you, edit ~/.ssh/config; and to set it for a single command, give the option on the command line, e.g.
ssh -o "StrictHostKeyChecking no" hostname
An alternative approach if you have access to the host keys for the remote system is to add them to your known_hosts file in advance, so that SSH knows about them and won't ask the question. If this is possible, it's better from a security point of view. After all, the warning might be right and you really might be subject to a man-in-the-middle attack.
For instance, here's a script that will retrieve the key and add it to your known_hosts file:
ssh -o 'StrictHostKeyChecking no' hostname cat /etc/ssh/ssh_host_dsa_key.pub >>~/.ssh/known_hosts
Since you are trying to automate this by running a bash script on the host that is doing the ssh-ing, and assuming that:
You don't want to ignore host keys because that's an additional security risk.
Host keys on the host you're ssh-ing to rarely change, and if they do there's a good, well-known reason such as "the target host got rebuilt"
You want to run this script once to add the new key to known_hosts, then leave known_hosts alone.
Try this in your bash script:
# Remove old key
ssh-keygen -R $target_host
# Add the new key
ssh-keyscan $target_host >> ~/.ssh/known_hosts
You just have to update the current fingerprint that's being sent from server. Just Type in the following and you'll be good to go :)
ssh-keygen -f "/home/your_user_name/.ssh/known_hosts" -R "server_ip"
Just adding the most 'modern' approach.
Like all other answers - this means you are BLINDLY accepting a key from a host. Use CAUTION!
HOST=hostname ssh-keygen -R $HOST && ssh-keyscan -Ht ed25519 $HOST >> "$HOME/.ssh/known_hosts"
First remove any entry using -R, and then generate a hashed (-H) known_hosts entry which we append to the end of the file.
As with this answer prefer ed25519.
Get a list of SSH host IPs (or DNS name) output to a file > ssh_hosts
Run a one-liner to populate the ~/.ssh/known_hosts on the control node (often do this to prepare target nodes for Ansible run)
NOTE: Assume we prefer ed25519 type of host key
# add the target hosts key fingerprints
while read -r line; do ssh-keyscan -t ed25519 $line >> ~/.ssh/known_hosts; done<ssh_hosts
# add the SSH Key('s) public bit to target hosts `authorized_keys` file
while read -r line; do ssh-copy-id -i /path/to/key -f user#$line; done<ssh_hosts
ssh -o UserKnownHostsFile=/dev/null user#host
Add following file
~/.ssh/config
and this in the file as content
StrictHostKeyChecking no
This setting will make sure that ssh will never ask for fingerprint check again.
This should be added very carefully as this would be really dangerous and allow to access all fingerprints.
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 months ago.
Improve this question
I've reinstalled my server and I am getting these messages:
[user#hostname ~]$ ssh root#pong
###########################################################
# WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! #
###########################################################
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
6e:45:f9:a8:af:38:3d:a1:a5:c7:76:1d:02:f8:77:00.
Please contact your system administrator.
Add correct host key in /home/hostname /.ssh/known_hosts to get rid of this message.
Offending RSA key in /var/lib/sss/pubconf/known_hosts:4
RSA host key for pong has changed and you have requested strict checking.
Host key verification failed.
I have tried various solutions that I found on the Internet. My known_hosts file (normally in ~/.ssh/known_hosts) is in /var/lib/sss/pubconf/known_hosts. I've tried to edit it, but it remains in one state. I have installed ipa-client and have Fedora 19. How do I resolve this warning?
All the answers answered so far work only if you do not have Freeipa installed.
The right answer for freeipa in comments below from adrin is here.
Here is the simplest solution:
ssh-keygen -R <host>
For example,
ssh-keygen -R 192.168.3.10
From the ssh-keygen man page:
-R hostname Removes all keys belonging to hostname from a known_hosts file. This option is useful to delete hashed hosts (see the -H option above).
Use
ssh-keygen -R [hostname]
Example with an ip address/hostname would be:
ssh-keygen -R 168.9.9.2
This will update the offending of your host from the known_hosts. You can also provide the path of the known_hosts with -f flag.
I had this same error occur after I recreated a Digital Ocean Ubuntu image. I used the following command with my server IP in place of [IP_ADDRESS]
ssh-keygen -R [IP_ADDRESS]
The sledgehammer is to remove every known host in one fell swoop:
rm ~/.ssh/known_hosts
On Monterey
sudo rm /var/root/.ssh/known_hosts
I come up against this as we use small subnets of short-lived servers from a jump box, and frequently have internal IP address reuse of servers that share the same ssh key.
When you reinstall the server its identity changes, and you'll start to get this message. Ssh has no way of knowing whether you've changed the server it connects to, or a server-in-the-middle has been added to your network to sniff on all your communications - so it brings this to your attention.
Simply remove the key from known_hosts by deleting the relevant entry:
sed '4d' -i /var/lib/sss/pubconf/known_hosts
The 4d is on the account of Offending RSA ...known_hosts:4
The problem is that you've previously accepted an SSH connection to a remote computer and that remote computer's digital fingerprint or SHA256 hash key has changed since you last connected. Thus when you try to SSH again or use github to pull code, which also uses SSH, you get an error. Why? Because you're using the same remote computer address as before but the remote computer is responding with a different fingerprint. Therefore, it's possible that someone is spoofing the computer you previously connected to. This is a security issue.
If you're 100% sure that the remote computer isn't compromised, hacked, being spoofed, etc then all you need to do is delete the entry in your known_hosts file for the remote computer. That will solve the issue as there will no longer be a mismatch with SHA256 fingerprint IDs when connecting.
On Mac here's what I did:
1) Find the line of output that reads RSA host key for servername:port has changed and you have requested strict checking. You'll need both the servername and potentially port from that log output.
2) Back up the SSH known hosts file cp /Users/yourmacusername/.ssh/known_hosts /Users/yourmacusername/.ssh/known_hosts.bak
3) Find the line where the computer's old fingerprint is stored and delete it. You can search for the specific offending remote computer fingerprint using the servername and port from step #1. nano /Users/yourmacusername/.ssh/known_hosts
4) CTRL-X to quit and choose Y to save changes
Now type ssh -p port servername and you will receive the original prompt you did when you first tried to SSH to that computer. You will then be given the option to save that remote computer's updated SHA256 fingerprint to your known_hosts file. If you're using SSH over port 22 then the -p argument is not necessary.
Any issues you can restore the original known_hosts file: cp /Users/yourmacusername/.ssh/known_hosts.bak /Users/yourmacusername/.ssh/known_hosts
As many have already said, use ssh-keygen, i.e.
ssh-keygen -R pong
Also, you may like to consider temporarily turning off host key checking:
ssh -oStrictHostKeyChecking=no root#pong
Works for me!
Error: Offending RSA key in /var/lib/sss/pubconf/known_hosts:4
This indicates you have an offending RSA key at line no. 4
Solution 1:
1. vi /var/lib/sss/pubconf/known_hosts
2. remove line no: 4.
3. Save and Exit, and Retry.
Solution 2:
ssh-keygen -R "you server hostname or ip"
OR
Solution 3:
sed -i '4d' /root/.ssh/known_hosts
This will remove 4th line of /root/.ssh/known_hosts in place(-i).
I used the solution of mockinterface, though the sed -i didn't quite work
I solved it by deleting the line by hand with vim:
sudo vim /var/lib/sss/pubconf/known_hosts
You can use any other text editor you want, but probably you'll need to show your administrative privileges
FINAL Solution!
It is showing due to the stored invalid ECDSA key. So we have to remove the ECDSA key from our master/controller machine by using the below command:
ssh-keygen -R 192.168.0.132
Here 192.168.0.132 is the remote system IP.
Edit /home/hostname /.ssh/known_hosts,and delete the 4 lines, and save it.
Then run ssh root#pong again, you will see message like this:Are you sure you want to continue connecting (yes/no)? yes, just print yes.
Note: If you got some problem, read the hints first, it will help.
The other answers here are good and working, anyway, I solved the problem by deleting ~/.ssh/known_hosts. This certainly solves the problem, but it's probably not the best approach.
updated your ssh key, getting the above message is normal.
Just edit ~/.ssh/known_hosts and delete line 4, as the message pointed you
Offending RSA key in /Users/isaacalves/.ssh/known_hosts:4
or use ssh-keygen to delete the invalid key
ssh-keygen -R "you server hostname or ip"
This is because your remote computer settings have changed. Remove your current keys for that.
vim /root/.ssh/known_hosts
Delete the line of the IP you are connecting.
In my case it happened because I previously had ssh connection with a machine with same ip(say 192.152.51.10) and the system was considering the RSA key(stored in /home/user_name/.ssh/known_hosts) of the previous host which resulted in mismatch.
To resolve this issue, you have to remove previously stored RSA key for the ip 192.152.51.10.
ssh-keygen -f "/home/user_name/.ssh/known_hosts" -R 192.152.51.10
Simple one-liner solution, tested on mac:
sed '/212.156.48.110/d' ~/.ssh/known_hosts > ~/.ssh/known_hosts
Deletes only the target ssh host IP from know hosts.
where 212.156.48.110 is replaced by the target host IP address.
Cause: Happened because the target IP was already known for a different machine due to port forwarding. Deleting the target IP before connecting will fix the issue.
I use PowerShell in Windows 10 for ssh.
My problem was in the Windows directory: C:\Users\youruser\.ssh
Delete the file known_hosts in that directory to forget the old value.
You may also use use File Explorer to locate and delete the file.
If you are trying to connect to running docker container on port 2222 with the command and you get the error
mian#tdowrick2~$ ssh pos#localhost -p 2222
Then to solve this problem, on your local computer (i.e. host machine not container) go to cd ~/.ssh/ and open known_hosts file with text editor. Remove the line starting with [localhost]:2222 and save the file. Now try to ssh again
mian#tdowrick2~$ ssh pos#localhost -p 2222
Error will disappear but you have to do it each time the container restart.
My solution is:
vi ~/.ssh/known_hosts
delete the line that contains your want connected ip.
This is better than delete all of the known_hosts
Remove that the entry from known_hosts using:
ssh-keygen -R *ip_address_or_hostname*
This will remove the problematic IP or hostname from known_hosts file and try to connect again.
From the man pages:
-R hostname
Removes all keys belonging to hostname from a known_hosts file. This option is useful to delete hashed hosts (see the -H option
above).
Sometimes, if for any reason, you need to reinstall a server, when connecting by ssh we will find that you server say that the identification has changed.
If we know that it is not an attack, but that we have reinstated the system, we can remove the old identification from the known_hosts using ssh-keygen:
ssh-keygen -R <host/ip:hostname>
root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old
When connecting again we will ask you to validate the new fingerprint:
ssh -l user <host/ip:hostname>
The authenticity of host '<host/ip:hostname>' can't
be established.
RSA key fingerprint is 3f:3d:a0:bb:59:24:35:6d:e5:a0:1a:3f:9c:86:81:90.
Are you sure you want to continue connecting (yes/no)? yes
Use this command:
truncate -s 0 /home/SYSTEM_NAME/.ssh/known_hosts
I had this problem, and the reason is very simple, I have a duplicated IP address to ssh login, so after modify this problem, everthing is solved.
Only client side problem(duplicate key for ip):
Solve variants:
For clear one ip(default port 22):
ssh-keygen -f -R 7.7.7.7
For one ip(non default port):
ssh-keygen -f -R 7.7.7.7:333
Fast clear all ips:
cd ~; rm .ssh/known_hosts
7.7.7.7 - ssh your server ip connect
333 - non standart port
Just do:
cd /home/user/.ssh/ -> here user will be your username, i.e. /home/jon/ for example.
Then
gedit known_hosts & and delete the contents inside it.
Now ssh again, it should work.
I had the same error in my machine, and I clear the known_hosts file, and after that, it works fine.
Simply clear the known_hosts which is present in /home/{username}/.ssh/known_hosts
vi /home/{username}/.ssh/known_hosts
remove every line inside known hosts and exit after that you will be able to login.
OR
run this command
ssh-keygen -R "hostname/ip_address"
SOLUTION:
1- delete from "$HOME/.ssh/known_hosts" the line referring to the host towards which is impossible to connect.
2- execute this command: ssh-keygen -R "IP_ADDRESSorHOSTNAME" (substitute "IP_ADDRESSorHOSTNAME" with your destination ip or destination hostname)
3- Retry ssh connection (if it fails please check permission on .ssh directory, it has to be 700)
My solution on UBUNTU (linux):
1.You have to delete the content from "known_hosts" file which is in "/home/YOUR_USERNAME/.ssh/known_hosts"
2.Generate a new ssh key like "ssh-keygen -t rsa -C "your.email#example.com" -b 4096"
3.Copy-paste your new ssh key in your git repository (gitlab in my case) SSH keys.
It works for me !
AWS EC2.
Find the ip in the message it gives you.
run
vim /home/ec2-user/.ssh/known_hosts
Use the arrow keys to find the ip from the message and click.
dd
This will delete that line then run escape
:wp
This will save then you are good to go.
I created key pair using puttygen.exe (client is windows 8). On server (Ubuntu 12.04.3 LTS), I have put my public key in ~/.ssh/authorized_keys. The public key is this:
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAopfM6RHOgnuc4Aftn3t4k5UIAT3StCAbn/vg/IMbphbXadshC+79sIlRq3P4zGzMjFTP4hKnzu6ehLV5lmj/qorq3SKT+bPO5Qrac3VbIlrGvuBFDDjP82I2Hwg3HzlsFTstqk++KToapaTYZ7jENEYyPl2wnzITJnt//+4U1o6juoXTKgdNE02hHnRZyHOV/bnkZyJJCEwJv5U0eXSThQnhmXtUxGT8U0HQNFiXfqIIVllhWiCnyrhhIaKz/CIJNAd2VmzyJzQtJtTQX8aWSNVrZju6Sv2/RncTNvsACdNgjjh/FH8PQXaep00jlJ3MOdsC8vz6VSPFbh6iKy1oLQ== rsa-key-20131231
So it's correct (one line, no comments, starts with ssh-rsa, etc.)
.ssh dir permission level is 700, authorized_keys file permission is 600. Both directory and file owned by the actual user that I try to log in.
When I try connecting I'm getting 'server refused our key' and server asks for password. That's all. Nothing is logged to /var/log/auth.log when attempting to log in with the key.
I've looked everywhere and all articles and tips mention setting chmod 600 and 700 for the file/directory and formatting the key correctly. I've done all this still getting 'refused our key' error and I'm out of ideas.
OK, there was a small typo in my key. Apparently when pasting to file the first letter was cut off and it started with sh-rsa instead of ssh-rsa.
nrathathaus - your answer was very helpful, thanks a lot, this answer is credited to you :) I did like you said and set this in sshd_conf:
LogLevel DEBUG3
By looking at the logs I realized that sshd reads the key correctly but rejects it because of the incorrect identifier.
Adding a few thoughts as other answers helped, but were not exact fit.
First of all, as mentioned in accepted answer, edit
/etc/ssh/sshd_config
and set log level:
LogLevel DEBUG3
Then restart sshd on the server to have it use the changed log level, e.g.:
sudo service ssh restart
Then try to authenticate, and when it fails, look for log file:
/var/log/secure
It will have errors you are looking for.
In my case I had to change the permissions of /home/user from 0755 to 0700 as well.
In my case, is a permission problem.
I changed the log level to DEBUG3, and in /var/log/secure I see this line:
Authentication refused: bad ownership or modes for directory
Googled and I found this post:
https://www.daveperrett.com/articles/2010/09/14/ssh-authentication-refused/
chmod g-w /home/$USER
chmod 700 /home/$USER/.ssh
chmod 600 /home/$USER/.ssh/authorized_keys
Basically, it tells me to:
get rid of group w permission of your user home dir
change permission to 700 of the .ssh dir
change permission to 600 of the authorized_keys file.
And that works.
Another thing is that even I enabled root login, I cannot get root to work. Better use another user.
Running Windows 8.1 I ran into the server refused our key problem.
Following the guide: https://winscp.net/eng/docs/guide_windows_openssh_server
It was easy to make a connection using the Windows login username and password. However, authenticating with the username in combination with a private key, the response was server refused our key.
Getting it to work with a public key came down to the permissions on the file:
C:\ProgramData\ssh\administrators_authorized_keys
This is a helpful page: https://github.com/PowerShell/Win32-OpenSSH/wiki/Troubleshooting-Steps
Stop the two OpenSSH services, then open a command prompt with admin permissions. Then run:
C:\OpenSSH-Win32>c:\OpenSSH-Win32\sshd.exe -ddd
Note: specify the full path to the exe otherwise sshd complains.
This creates a one-time use connection listener. The -ddd is verbose level 3.
After making a connection, scanning the logs revealed:
debug1: trying public key file __PROGRAMDATA__/ssh/administrators_authorized_keys
debug3: Failed to open file:C:/ProgramData/ssh/administrators_authorized_keys error:2
debug1: Could not open authorized keys '__PROGRAMDATA__/ssh/administrators_authorized_keys':
No such file or directory
Had to create the file: C:\ProgramData\ssh\administrators_authorized_keys
And copy the public key text into it, e.g: ssh-rsa AAAA................MmpfXUCj rsa-key-20190505
And then save the file. I saved the file as UTF-8 with the BOM. Didn't test ANSI.
Then running the one-time command line again, in the logs showed:
debug1: trying public key file __PROGRAMDATA__/ssh/administrators_authorized_keys
debug3: Bad permissions. Try removing permissions for user: S-1-5-11 on file C:/ProgramData/ssh/administrators_authorized_keys.
Authentication refused.
S-1-5-11 is the name given to the System.
To fix the Bad permissions, right click on the administrators_authorized_keys file, goto the Security Tab , click the Advanced button and remove inherited permissions.
Then delete all Group or user names: except for the Windows login username, e.g: YourMachineName\username
The permissions for that username should be Read Allow, Write Deny everything else is unchecked. The owner of the file should also be YourMachineName\username
This fixed the problem.
Other Useful links:
Download OpenSSH-Win32.zip from: https://github.com/PowerShell/Win32-OpenSSH/releases
C# example of how to use the WinSCPnet.dll to make a connection to the OpenSSH server: https://winscp.net/eng/docs/library#csharp
Here is the code snippet to make a connection using the WinSCPnet.dll:
static void WinSCPTest() {
SessionOptions ops = new SessionOptions {
Protocol = Protocol.Sftp,
PortNumber = 22,
HostName = "192.168.1.188",
UserName = "user123",
//Password = "Password1",
SshHostKeyFingerprint = #"ssh-rsa 2048 qu0f........................ddowUUXA="
};
ops.SshPrivateKeyPath = #"C:\temp\rsa-key-20190505.ppk";
using (Session session = new Session()) {
session.Open(ops);
MessageBox.Show("success");
}
}
Replace SshHostKeyFingerprint and SshPrivateKeyPath with your own values.
Edit: added screenshot of administrators_authorized_keys file permissions:
When OpenSSH SSH Server is running as a Service, then only System should have permission. However, if running sshd.exe from the command prompt, then the current user should be the only one listed (read allow, write deny).
The simple solution i found was to move the authorized_keys file away from the hidden .ssh directory and put it in the system ssh directory:
/etc/ssh/keys/authorized_keys
As soon as I did this it worked with no problems.
having same issue in windows server 2008 r2 and explored a lot to solve, finally did that by following:
open C:\Program Files (x86)\OpenSSH\etc\sshd_config with textpad or any other text editor
remove comment from following lines, after removing they should look like following:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
save it and try to login with private key now.
have fun.
I'm adding this answer to help anyone, like me, who spent hours scouring the internet without success.
YOUR HOME FOLDER MIGHT BE ENCRYPTED.
Or for that matter any folder in which your "authorized_keys" file is nested. Man, that would have saved me a lot of time. To check, go perform
ls -A
on the directory whose encryption status you would like to determine. If the folder contains a folder named ".encryptfs" the answer is, yes, that folder is encrypted. This will impede your ability to access the "authorized_keys" file containing the public ssh key needed for verification.
To fix this, place the "authorized_key" file in a directory tree that contains no encryption.
After adding key, login as ec2-user if you are using an Amazon Linux machine
If its ubuntu machine then use ubuntu
Thanks to nrathaus and /var/log/auth.log investigation on debug level comes the following.
Another reason is that your home directory may have permissions different than 755.
In my case it was caused by (/etc/ssh/sshd_config):
PermitRootLogin no
Changed to yes, restarted the service and got in normally.
I have solved this problem,puttygen is a third-party software, ssh key which generated by it didn't be used directly, so you must make some changes.
For example, it look like this
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7
*******C4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ==
---- END SSH2 PUBLIC KEY ----
I omit some of the alphabets in the middle, replaced by *, if not, StackOverflow told me that the code format is wrong, do not let me post。
this is my ssh key generated by puttygen, you must change to this
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7wfvKGWWR7wxA8GEXJsM01FQw5hYWbNF0CDI7nCMXDUEDOzO1xKtNoaidlLA0qGl67bHaF5t+0mE+dZBGqK7jG9L8/KU/b66/tuZnqFqBjLkT+lS8MDo1okJOScuLSilk9oT5ZiqxsD24sdEcUE62S8Qwu7roVEAWU3hHNpnMK+1szlPBCVpbjcQTdiv1MjsOHJXY2PWx6DAIBii+/N+IdGzoFdhq+Yo/RGWdr1Zw/LSwqKDq1SmrpToW9uWVdAxeC4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ== yourname#hostname
In my case, I have deleted some comments, such as
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
---- END SSH2 PUBLIC KEY ----
and add ssh-rsa at the beginning,
add yourname#hostname at the last.
note: not delete== in the last and you must change "yourname" and "hostname" for you, In my case, is uaskh#mycomputer,yourname is that you want to log in your vps .when all these things have done,you could to upload public-key to uaskh's home~/.ssh/authorized_keys by cat public-key >> ~/.ssh/authorized_keys then sudo chmod 700 ~/.ssh sudo chmod 600 ~/.ssh/authorized_keys then you must to modify /etc/ssh/sshd_config, RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys my operating system is CentOS 7,This is my first time to anwser question,I will try my efforts to do ,Thank you!
I encountered this problem today and my issue was that when copying the public key from file, new line characters are included as well. You can use ":set list" in vim to see all the hidden new lines and make sure to delete all the new lines except for the last one. Also, my key was missing "ssh-rsa " in the beginning. Make sure you have that as well.
The equivilent of an SSH command:
ssh -i <path_to_pem_file> ec2-user#calendar.com
In Windows, first use PuTTYGen to convert the pem file to a ppk file.
Open PuTTYGen
File/Load the private pem key (or an OpenSSH key)
In the Open FileDialog, use the drop down to select "All files" (it only shows ppk file formats not pem, also OpenSSH key files that can be converted like pem files don't have a file extension)
File/Save private key (*.ppk)
The same settings in Putty as the SSH command:
Open Putty
Session/Hostname: calendar.com
Connection/Data/Auto-login username: ec2-user
Connection/SSH/Auth/PrivateKeyFile Path: the file path to the PPK file
OpenSSH disable the ssh-rsa signature scheme by default in the next
release.
In the SSH protocol, the "ssh-rsa" signature scheme uses the SHA-1
hash algorithm in conjunction with the RSA public key algorithm. It is
now possible1 to perform chosen-prefix attacks against the SHA-1
algorithm for less than USD$50K.
Source
So, update the key.
For those receiving this error from Windows Server, I received this same error and it was a user account issue. With many organizations, group policy for Administrators may not allow setting up SSH Server and connections. With that type of setup, this must be done from Local Admin account. Might be worth looking into if you have confirmed there are not any typos in the public key.
In my case, I had to disable SELinux on Centos6.6 to get it working :)
Edit /etc/selinux/config and set the following and then reboot the host.
selinux=disabled
BTW...forgot to mention that I had to set the LogLevel=DEBUG3 to identify the issue.
I had the same error on solaris but found in /var/adm/splunk-auth.log the following:
sshd: [auth.debug] debug1: PAM conv function returns PAM_SUCCESS
sshd: [auth.notice] Excessive (3) login failures for weblogic: locking account.
sshd: [auth.debug] ldap pam_sm_authenticate(sshd-kbdint weblogic), flags = 1
sshd: [auth.info] Keyboard-interactive (PAM) userauth failed[9] while authenticating: Authentication failed
In /etc/shadow the account was locked:
weblogic:*LK*UP:16447::::::3
Removed the "*LK*" part:
weblogic:UP:16447::::::3
and I could use ssh with authorized_keys as usual.
I have this issue where sshd only reads from authorized_keys2.
Copying or renaming the file fixed the problem for me.
cd ~/.ssh
sudo cat authorized_keys >> authorized_keys2
P.S. I'm using Putty from Windows and used PuTTyKeygen for key pair generation.
I was facing similar issue when trying to logon through Mobaxterm. The private key was generated through puttygen. Regenerating the key helped in my case.
As my experience, I suggest you should generate keys from putty, should not generate from linux side. Because the key will be old PEM format. Anyway, just my suggestion. I did as steps below and worked fine with me and with my team.
Generate a key pair with PuTTYGen.exe on your local (type: RSA, length: 2048 bits).
Save private/public key as "id_rsa.ppk/id_rsa.pub" files on your local.
Create "authorized_keys" file on your local, then enter the public key in "id_rsa.pub" to "authorized_keys".
Remember content has to begin with "ssh-rsa" and one line only.
Use WinScp (or putty command) to copy "authorized_keys & id_rsa.pub" from your local to your linux-user-home "/home/$USER/.ssh/".
Run these commands:
chmod 700 .ssh
chmod 600 .ssh/authorized_keys
chown $USER:$USER .ssh -R
Test your connect setting by load the private key "id_rsa.ppk" in the PuTTY.exe profile, then click open (put your passphrase if have).
check your key, this should be a rsa (id_rsa.pub) key today and no longer a dss (id_dsa.pub) key, use puttygen 0.70 and choose RSA on type of key to generate, replace the public key on host ~/.ssh/authorized_keys
Oh my God I spent days trying to fix this. So here is what worked for me. I went back to the root fold like this:
cd /root/
mkdir .ssh
cd .ssh
chmod 700 .ssh
nano -w authorized_keys
service ssh restart
So I used root to logging via Putty and it worked. so try to do the same with the user you want to use in putty.
In the case of mine it was a wrong user:group attribution. I solved setting the right user and group:
sudo chown [user]:[group] -R /home/[user]
This helps to me:
# /etc/ssh/sshd_config
PubkeyAuthentication yes
PubkeyAcceptedKeyTypes=+ssh-rsa
# temporarily added:
LogLevel DEBUG3
# gentoo
# tail -n 50 /var/log/messages
and restart sshd
/etc/init.d/sshd restart
If you run Putty in a version before 0.75, then updating Putty should solve the problem.
Newer version of openSSH (as in Ubuntu 22.04) have deprecated the use of the SHA1 hashing algorithm during the login, but Putty used SHA1 until version 0.74.
If sshd log file on the server shows
$ sudo grep 'sshd' /var/log/auth.log
sshd[113232]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
then this in fact causing the error, and should be gone after Putty has been updated.
I'm using a PUTTYgen file with psftp, and I encountered this problem on my Windows Server when we were required to create new keys for a client. The private_key_name.ppk file and the open_ssh.txt file must be in the same directory for the connection to work.
In my case home on nfs was 777, needed to be 750. That fixed the issue.
When using Cpanel you can check if the key is authorized in
SSH Access >> Public keys >> Manage >> Authorize or Deauthorize.
if you get this error in /var/log/secure
error: key_read: key_from_blob AA
AAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswD
it means your key is having space, if you generated key through puttgen when you view .ppk file, it will look like this:
AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswD
al74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5
GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBC
gLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqz
xjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5L
VwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ==
and when you try to paste it you will get an error in reading key, so try to edit key and make it one line and try it
this should look like something
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswDal74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBCgLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqzxjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5LVwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ== username#domainname
When i ssh to a machine, sometime i get this error warning and it prompts to say "yes" or "no". This cause some trouble when running from scripts that automatically ssh to other machines.
Warning Message:
The authenticity of host '<host>' can't be established.
ECDSA key fingerprint is SHA256:TER0dEslggzS/BROmiE/s70WqcYy6bk52fs+MLTIptM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'pc' (ECDSA) to the list of known hosts.
Is there a way to automatically say "yes" or ignore this?
Depending on your ssh client, you can set the StrictHostKeyChecking option to no on the command line, and/or send the key to a null known_hosts file. You can also set these options in your config file, either for all hosts or for a given set of IP addresses or host names.
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no
EDIT
As #IanDunn notes, there are security risks to doing this. If the resource you're connecting to has been spoofed by an attacker, they could potentially replay the destination server's challenge back to you, fooling you into thinking that you're connecting to the remote resource while in fact they are connecting to that resource with your credentials. You should carefully consider whether that's an appropriate risk to take on before altering your connection mechanism to skip HostKeyChecking.
Reference.
Old question that deserves a better answer.
You can prevent interactive prompt without disabling StrictHostKeyChecking (which is insecure).
Incorporate the following logic into your script:
if [ -z "$(ssh-keygen -F $IP)" ]; then
ssh-keyscan -H $IP >> ~/.ssh/known_hosts
fi
It checks if public key of the server is in known_hosts. If not, it requests public key from the server and adds it to known_hosts.
In this way you are exposed to Man-In-The-Middle attack only once, which may be mitigated by:
ensuring that the script connects first time over a secure channel
inspecting logs or known_hosts to check fingerprints manually (to be done only once)
To disable (or control disabling), add the following lines to the beginning of /etc/ssh/ssh_config...
Host 192.168.0.*
StrictHostKeyChecking=no
UserKnownHostsFile=/dev/null
Options:
The Host subnet can be * to allow unrestricted access to all IPs.
Edit /etc/ssh/ssh_config for global configuration or ~/.ssh/config for user-specific configuration.
See http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html
Similar question on superuser.com - see https://superuser.com/a/628801/55163
Make sure ~/.ssh/known_hosts is writable. That fixed it for me.
The best way to go about this is to use 'BatchMode' in addition to 'StrictHostKeyChecking'. This way, your script will accept a new hostname and write it to the known_hosts file, but won't require yes/no intervention.
ssh -o BatchMode=yes -o StrictHostKeyChecking=no user#server.example.com "uptime"
This warning is issued due the security features, do not disable this feature.
It's just displayed once.
If it still appears after second connection, the problem is probably in writing to the known_hosts file.
In this case you'll also get the following message:
Failed to add the host to the list of known hosts
You may fix it by changing owner of changing the permissions of the file to be writable by your user.
sudo chown -v $USER ~/.ssh/known_hosts
Edit your config file normally located at '~/.ssh/config', and at the beggining of the file, add the below lines
Host *
User your_login_user
StrictHostKeyChecking no
IdentityFile ~/my_path/id_rsa.pub
User set to your_login_user says that this settings belongs to your_login_user
StrictHostKeyChecking set to no will avoid the prompt
IdentityFile is path to RSA key
This works for me and my scripts, good luck to you.
Ideally, you should create a self-managed certificate authority. Start with generating a key pair:
ssh-keygen -f cert_signer
Then sign each server's public host key:
ssh-keygen -s cert_signer -I cert_signer -h -n www.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub
This generates a signed public host key:
/etc/ssh/ssh_host_rsa_key-cert.pub
In /etc/ssh/sshd_config, point the HostCertificate to this file:
HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub
Restart the sshd service:
service sshd restart
Then on the SSH client, add the following to ~/.ssh/known_hosts:
#cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/
The above contains:
#cert-authority
The domain *.example.com
The full contents of the public key cert_signer.pub
The cert_signer public key will trust any server whose public host key is signed by the cert_signer private key.
Although this requires a one-time configuration on the client side, you can trust multiple servers, including those that haven't been provisioned yet (as long as you sign each server, that is).
For more details, see this wiki page.
Do this -> chmod +w ~/.ssh/known_hosts. This adds write permission to the file at ~/.ssh/known_hosts. After that the remote host will be added to the known_hosts file when you connect to it the next time.
With reference to Cori's answer, I modified it and used below command, which is working. Without exit, remaining command was actually logging to remote machine, which I didn't want in script
ssh -o StrictHostKeyChecking=no user#ip_of_remote_machine "exit"
Add these to your /etc/ssh/ssh_config
Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no
Generally this problem occurs when you are modifying the keys very oftenly. Based on the server it might take some time to update the new key that you have generated and pasted in the server. So after generating the key and pasting in the server, wait for 3 to 4 hours and then try. The problem should be solved. It happened with me.
The following steps are used to authenticate yourself to the host
Generate a ssh key. You will be asked to create a password for the key
ssh-keygen -f ~/.ssh/id_ecdsa -t ecdsa -b 521
(above uses the recommended encryption technique)
Copy the key over to the remote host
ssh-copy-id -i ~/.ssh/id_ecdsa user#host
N.B the user # host will be different to you. You will need to type in the password for this server, not the keys password.
You can now login to the server securely and not get an error message.
ssh user#host
All source information is located here:
ssh-keygen
For anyone who finds this and is simply looking to prevent the prompt on first connection, but still wants ssh to strictly check the key on subsequent connections (trust on first use), you can set StrictHostKeyChecking to accept-new in ~/.ssh/config, which will do what you're looking for. You can read more about it in man ssh_config. I strongly discourage disabling key checking altogether.
Run this in host server it's premonition issue
chmod -R 700 ~/.ssh
I had the same error and wanted to draw attention to the fact that - as it just happened to me - you might just have wrong privileges.You've set up your .ssh directory as either regular or root user and thus you need to be the correct user. When this error appeared, I was root but I configured .ssh as regular user. Exiting root fixed it.
This is trying to establish password-less authentication. So, if you try to run that command manually once, it will ask to provide the password there. After entering password, it saves that password permanently, and it will never ask again to type 'yes' or 'no'.
For me the reason is that I have wrong permission on ~/.ssh/known_hosts.
I have no write permission on known_hosts file. So it ask me again and again.
In my case, the host was unkown and instead of typing yes to the question are you sure you want to continue connecting(yes/no/[fingerprint])? I was just hitting enter .
I solve the issue which gives below written error:
Error:
The authenticity of host 'XXX.XXX.XXX' can't be established.
RSA key fingerprint is 09:6c:ef:cd:55:c4:4f:ss:5a:88:46:0a:a9:27:83:89.
Solution:
1. install any openSSH tool.
2. run command ssh
3. it will ask for do u add this host like.
accept YES.
4. This host will add in the known host list.
5. Now you are able to connect with this host.
This solution is working now......
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
I want to use multiple private keys to connect to different servers or different portions of the same server (my uses are system administration of server, administration of Git, and normal Git usage within the same server). I tried simply stacking the keys in the id_rsa files to no avail.
Apparently a straightforward way to do this is to use the command
ssh -i <key location> login#server.example.com
That is quite cumbersome.
Any suggestions as to how to go about doing this a bit easier?
From my .ssh/config:
Host myshortname realname.example.com
HostName realname.example.com
IdentityFile ~/.ssh/realname_rsa # private key for realname
User remoteusername
Host myother realname2.example.org
HostName realname2.example.org
IdentityFile ~/.ssh/realname2_rsa # different private key for realname2
User remoteusername
Then you can use the following to connect:
ssh myshortname
ssh myother
And so on.
You can instruct ssh to try multiple keys in succession when connecting. Here's how:
$ cat ~/.ssh/config
IdentityFile ~/.ssh/id_rsa
IdentityFile ~/.ssh/id_rsa_old
IdentityFile ~/.ssh/id_ed25519
# ... and so on
$ ssh server.example.com -v
....
debug1: Next authentication method: publickey
debug1: Trying private key: /home/example/.ssh/id_rsa
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/example/.ssh/id_rsa_old
debug1: read PEM private key done: type RSA
....
[server ~]$
This way you don't have to specify what key works with which server. It'll just use the first working key.
Also you would only enter a passphrase if a given server is willing to accept the key. As seen above ssh didn't try to ask for a password for .ssh/id_rsa even if it had one.
Surely it doesn't outbeat a per-server configuration as in other answers, but at least you won't have to add a configuration for all and every server you connect to!
The answer from Randal Schwartz almost helped me all the way.
I have a different username on the server, so I had to add the User keyword to my file:
Host friendly-name
HostName long.and.cumbersome.server.name
IdentityFile ~/.ssh/private_ssh_file
User username-on-remote-machine
Now you can connect using the friendly-name:
ssh friendly-name
More keywords can be found on the OpenSSH man page. NOTE: Some of the keywords listed might already be present in your /etc/ssh/ssh_config file.
The previous answers have properly explained the way to create a configuration file to manage multiple ssh keys. I think, the important thing that also needs to be explained is the replacement of a host name with an alias name while cloning the repository.
Suppose, your company's GitHub account's username is abc1234.
And suppose your personal GitHub account's username is jack1234
And, suppose you have created two RSA keys, namely id_rsa_company and id_rsa_personal. So, your configuration file will look like below:
# Company account
Host company
HostName github.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa_company
# Personal account
Host personal
HostName github.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa_personal
Now, when you are cloning the repository (named demo) from the company's GitHub account, the repository URL will be something like:
Repo URL: git#github.com:abc1234/demo.git
Now, while doing git clone, you should modify the above repository URL as:
git#company:abc1234/demo.git
Notice how github.com is now replaced with the alias "company" as we have defined in the configuration file.
Similary, you have to modify the clone URL of the repository in the personal account depending upon the alias provided in the configuration file.
ssh-add ~/.ssh/xxx_id_rsa
Make sure you test it before adding with:
ssh -i ~/.ssh/xxx_id_rsa username#example.com
If you have any problems with errors sometimes changing the security of the file helps:
chmod 0600 ~/.ssh/xxx_id_rsa
Generate an SSH key:
$ ssh-keygen -t rsa -C <email1#example.com>
Generate another SSH key:
$ ssh-keygen -t rsa -f ~/.ssh/accountB -C <email2#example.com>
Now, two public keys (id_rsa.pub, accountB.pub) should be exists in the ~/.ssh/ directory.
$ ls -l ~/.ssh # see the files of '~/.ssh/' directory
Create configuration file ~/.ssh/config with the following contents:
$ nano ~/.ssh/config
Host bitbucket.org
User git
Hostname bitbucket.org
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa
Host bitbucket-accountB
User git
Hostname bitbucket.org
PreferredAuthentications publickey
IdentitiesOnly yes
IdentityFile ~/.ssh/accountB
Clone from default account.
$ git clone git#bitbucket.org:username/project.git
Clone from the accountB account.
$ git clone git#bitbucket-accountB:username/project.git
Note: Because of the User git directive, you can omit the git# portion of the repo URL, shortening your clone command like so:
$ git clone bitbucket-accountB:username/project.git
This is the only purpose of that directive. If you don't need it (e.g. you always copy-paste the git clone command from the website), you can leave it out of the config.
See More Here
I would agree with Tuomas about using ssh-agent. I also wanted to add a second private key for work and this tutorial worked like a charm for me.
Steps are as below:
$ ssh-agent bash
$ ssh-add /path.to/private/key e.g ssh-add ~/.ssh/id_rsa
Verify by $ ssh-add -l
Test it with $ssh -v <host url> e.g ssh -v git#assembla.com
Now, with the recent version of Git, we can specify sshCommand in the repository-specific Git configuration file:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
sshCommand = ssh -i ~/.ssh/id_rsa_user
[remote "origin"]
url = git#bitbucket.org:user/repo.git
fetch = +refs/heads/*:refs/remotes/origin/*
For me on MacOs, the only working solution was to simply add this in file ~/.ssh/config:
Host *
IdentityFile ~/.ssh/your_ssh_key
IdentityFile ~/.ssh/your_ssh_key2
IdentityFile ~/.ssh/your_ssh_key3
AddKeysToAgent yes
your_ssh_key is without any extension. Don't use .pub.
I had run into this issue a while back, when I had two Bitbucket accounts and wanted to had to store separate SSH keys for both. This is what worked for me.
I created two separate ssh configurations as follows.
Host personal.bitbucket.org
HostName bitbucket.org
User git
IdentityFile /Users/username/.ssh/personal
Host work.bitbucket.org
HostName bitbucket.org
User git
IdentityFile /Users/username/.ssh/work
Now when I had to clone a repository from my work account - the command was as follows.
git clone git#bitbucket.org:teamname/project.git
I had to modify this command to:
git clone git#**work**.bitbucket.org:teamname/project.git
Similarly the clone command from my personal account had to be modified to
git clone git#personal.bitbucket.org:name/personalproject.git
Refer this link for more information.
Use ssh-agent for your keys.
Here is the solution that I used inspired from the answer of sajib-khan. The default configuration is not set; it's my personal account on GitLab and the other specified is my company account. Here is what I did:
Generate the SSH key
ssh-keygen -t rsa -f ~/.ssh/company -C "name.surname#company.com"
Edit the SSH configuration
nano ~/.ssh/config
Host company.gitlab.com
HostName gitlab.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/company
Delete the cached SSH key(s)
ssh-add -D
Test it!
ssh -T git#company.gitlab.com
Welcome to GitLab, #hugo.sohm!
ssh -T git#gitlab.com
Welcome to GitLab, #HugoSohm!
Use it!
Company account
git clone git#company.gitlab.com:group/project.git
Personal/default account
git clone git#gitlab.com:username/project.git
Here is the source that I used.
For those who are working with aws I would highly recommend working with EC2 Instance Connect.
Amazon EC2 Instance Connect provides a simple and secure way to connect to your instances using Secure Shell (SSH).
With EC2 Instance Connect, you use AWS Identity and Access Management (IAM) policies and principles to control SSH access to your instances, removing the need to share and manage SSH keys.
After installing the relevant packages (pip install ec2instanceconnectcli or cloning the repo directly) you can connect very easy to multiple EC2 instances by just changing the instance id:
What is happening behind the scenes?
When you connect to an instance using EC2 Instance Connect, the Instance Connect API pushes a one-time-use SSH public key to the instance metadata where it remains for 60 seconds. An IAM policy attached to your IAM user authorizes your IAM user to push the public key to the instance metadata.
The SSH daemon uses AuthorizedKeysCommand and AuthorizedKeysCommandUser, which are configured when Instance Connect is installed, to look up the public key from the instance metadata for authentication, and connects you to the instance.
(*) Amazon Linux 2 2.0.20190618 or later and Ubuntu 20.04 or later comes preconfigured with EC2 Instance Connect.
For other supported Linux distributions, you must set up Instance Connect for every instance that will support using Instance Connect. This is a one-time requirement for each instance.
Links:
Set up EC2 Instance Connect
Connect using EC2 Instance Connect
Securing your bastion hosts with Amazon EC2 Instance Connect
You can create a configuration file named config in your ~/.ssh folder. It can contain:
Host aws
HostName *yourip*
User *youruser*
IdentityFile *idFile*
This will allow you to connect to machines like this
ssh aws
As mentioned on a Atlassian blog page,
generate a config file within the .ssh folder, including the following text:
#user1 account
Host bitbucket.org-user1
HostName bitbucket.org
User git
IdentityFile ~/.ssh/user1
IdentitiesOnly yes
#user2 account
Host bitbucket.org-user2
HostName bitbucket.org
User git
IdentityFile ~/.ssh/user2
IdentitiesOnly yes
Then you can simply checkout with the suffix domain and within the projects you can configure the author names, etc. locally.
Multiple key pairs on GitHub
1.0 SSH configuration file
1.1 Create ~/.ssh/config
1.2 chmod 600 ~/.ssh/config (must)
1.3 Input the following into the file:
Host pizza
HostName github.com
PreferredAuthentications publickey # optional
IdentityFile ~/.ssh/privatekey1
Case A: Fresh new Git clone
Use this command to Git clone:
$ git clone git#pizza:yourgitusername/pizzahut_repo.git
Note: If you want to change the host name “pizza” of .ssh/config in the future, go into the Git cloned folder, edit .git/config file URL line (see case B)
Case B: Already have Git clone folder
2.1 Go to the cloned folder, and then go into the .git folder
2.2 Edit configuration file
2.3 Update the URL from *old to new:
(Old) URL = git#github.com:yourgitusername/pizzahut_repo.git
(New) URL = git#pizza:yourgitusername/pizzahut_repo.git
IMPORTANT: You must start ssh-agent
You must start ssh-agent (if it is not running already) before using ssh-add as follows:
eval `ssh-agent -s` # start the agent
ssh-add id_rsa_2 # Where id_rsa_2 is your new private key file
Note that the eval command starts the agent on Git Bash on Windows. Other environments may use a variant to start the SSH agent.
On Ubuntu 18.04 (Bionic Beaver) there is nothing to do.
After having created an second SSH key successfully the system will try to find a matching SSH key for each connection.
Just to be clear you can create a new key with these commands:
# Generate key make sure you give it a new name (id_rsa_server2)
ssh-keygen
# Make sure ssh agent is running
eval `ssh-agent`
# Add the new key
ssh-add ~/.ssh/id_rsa_server2
# Get the public key to add it to a remote system for authentication
cat ~/.ssh/id_rsa_server2.pub
I love the approach to set the following in file ~/.ssh/config:
# Configuration for GitHub to support multiple GitHub keys
Host github.com
HostName github.com
User git
# UseKeychain adds each keys passphrase to the keychain so you
# don't have to enter the passphrase each time.
UseKeychain yes
# AddKeysToAgent would add the key to the agent whenever it is
# used, which might lead to debugging confusion since then
# sometimes the one repository works and sometimes the
# other depending on which key is used first.
# AddKeysToAgent yes
# I only use my private id file so all private
# repositories don't need the environment variable
# `GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa"` to be set.
IdentityFile ~/.ssh/id_rsa
Then in your repository you can create a .env file which contains the ssh command to be used:
GIT_SSH_COMMAND="ssh -i ~/.ssh/your_ssh_key"
If you then use e.g. dotenv the environment environment variable is exported automatically and whoop whoop, you can specify the key you want per project/directory. The passphrase is asked for only once since it is added to the keychain.
This solution works perfectly with Git and is designed to work on a Mac (due to UseKeychain).
On CentOS 6.5 running OpenSSH_5.3p1 and OpenSSL 1.0.1e-fips, I solved the problem by renaming my key files so that none of them had the default name.
My .ssh directory contains id_rsa_foo and id_rsa_bar, but no id_rsa, etc.
You can try this sshmulti npm package for maintaining multiple SSH keys.