Why does SSH work from the command line but not from the SSH config file? - ssh

I've found that when running ssh from the command line on my system is different than running it from the ~/.ssh/config file. But I'm not sure how to fix it or if its a problem with the program itself.
I have a server (blueberry.local) and a client (xps.local). Both have a user named bob. Both can resolve each-other with the host command from either box.
The server is running sshd with the following configuration (/etc/ssh/sshd_config):
UsePAM yes
Banner none
AddressFamily any
Port 22
X11Forwarding no
PermitRootLogin no
GatewayPorts no
PasswordAuthentication no
KbdInteractiveAuthentication no
PrintMotd no
AuthorizedKeysFile %h/.ssh/authorized_keys %h/.ssh/authorized_keys2 /etc/ssh/authorized_keys.d/%u
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
KexAlgorithms sntrup761x25519-sha512#openssh.com,curve25519-sha256,curve25519-sha256#libssh.org,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305#openssh.com,aes256-gcm#openssh.com,aes128-gcm#openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm#openssh.com,hmac-sha2-256-etm#openssh.com,umac-128-etm#openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128#openssh.com
LogLevel INFO
UseDNS no
And from my client I'm running ssh with this configuration (~/.ssh/config):
Host blueberry.stark.local
Port 22
HostName blueberry.local
IdentityFile ~/.ssh/blueberry_rsa
IdentitiesOnly yes
When running ssh from the command line like this:
ssh bob#blueberry.local -i ~/.ssh/blueberry_rsa
The command works and I can successfully connect via ssh to the server.
However, when running ssh from the command line using the client configuration like this:
ssh bob#blueberry.local
I get an authentication error:
bob#blueberry.local: Permission denied (publickey).
What's going on here? I've tried to remove configuration properties and the like but it never works.
What's even stranger is that I have another client configuration just like that that works without any issues at all...

The issue is likely caused by two factors:
Based on your example command, your Host and HostName values are mixed up:
Host <this should be what you type on the CLI>
...
HostName <The real hostname of the server>
...
This means ssh isn't actually going to use any of the configuration you provided. Making the following change should work.
Host blueberry.local
Port 22
HostName blueberry.stark.local
IdentityFile ~/.ssh/blueberry_rsa
IdentitiesOnly yes
This is most likely if the following command works with the configuration you posted:
ssh bob#blueberry.starlink.local
If you expected ssh to just try all of your private keys until it found the right one, (~/.ssh/blueberry_rsa), its likely you haven't added it to your ssh-agent (you can confirm by running ssh-add -L and check the output.
by default ssh will check these paths, then any additional keys in the agent:
~/.ssh/id_rsa
~/.ssh/id_ecdsa
~/.ssh/id_ecdsa_sk
~/.ssh/id_ed25519
~/.ssh/id_ed25519_sk
~/.ssh/id_xmss
~/.ssh/id_dsa
Its likely you only have ~/.ssh/id_rsa in your agent which is what is throwing the
When in trouble, its always helpful to run ssh -vvv <rest of your command> to see whats happening under the hood 😉.

Related

Sign_and_send_pubkey: no mutual signature supported

I tried to connect to ssh server in M1 macOS terminal like this
ssh -i {myKeyFilePath/myKeyFile.pem} user#host
but it returns
sign_and_send_pubkey: no mutual signature supported
user#host: Permission denied (publickey).
I didn't modify any ssh settings, and the file permissions of {myKeyFile.pem} is 400.
Also I can connect ssh server well by IntelliJ remote hosts,
but when I tried this in terminal, it goes wrong.
When I updated my Mac system, all the ssh server can't ssh with the private key, you can add the 3 lines below in the beginning of your /etc/.ssh/config.
But the best solution is create a new private key and upload the public key to each server one by one, because when you got this error, means your private key is deprecated to use.
# vim ~/.ssh/config, add the lines at the beginning
Host *
PubkeyAcceptedKeyTypes=+ssh-rsa
HostKeyAlgorithms=+ssh-rsa
Most likely your SSH client is using ssh-rsa (RSA+SHA1) and your server has that signature algorithm disabled. SHA-1 is vulnerable and OpenSSH disabled that signature algorithm in version 8.8 (2021-09-26).
The replacement for ssh-rsa is rsa-sha2-256 and rsa-sha2-512.
Try this command:
ssh -o PubkeyAcceptedKeyTypes=rsa-sha2-256 -i {myKeyFilePath/myKeyFile.pem} user#host
If that command fails with an error regarding an unsupported key exchange, then your SSH client is probably ancient.
Use one of the following solutions:
update the SSH client (usually a good idea)
use a different SSH Key Type such as Ed25519 (recommended)
enable rsa-sha in the SSH server (not recommended)
Edit:
If that works, you can permanently add it to your ~/.ssh/config file, and eliminate it from the command line use. However, there is a valid security reason that rsa-sha1 was disabled. Only do this as a last resort because SHA1 has been broken. Do not enable rsa-sha1 if your servers are audited for security or exposed to the public Internet.
Host *
PubkeyAcceptedKeyTypes +ssh-rsa
Replace * with a specific host or IP address to limit the use of this configuration.
I spent a few hours until I came to this question and answers. Here is a quick try to ssh into the server and then deal with the stuff later:
ssh -o PubkeyAcceptedKeyTypes=ssh-rsa -i {yourfile} user#host
This combines the previous answers by shoaly and John Hanley which contain more details and suggestions worth to follow to.
After the Mac system is upgraded to Ventura 13.1, I encounter the problem that SSH is configured with passwordless login, but the password is still required, my solution is to upgrade and encrypt the server's key to ed25519:
// 1. server: check HostKey in /etc/ssh/sshd_config
...
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
// 2. client: ssh-keygen -t ed25519
ssh-keygen -t ed25519
// 3. client: vim ~/.ssh/ssh_config
Host *
IdentityFile ~/.ssh/id_ed25519
// 4. client: ssh-copy-id
ssh-copy-id -i ~/.ssh/id_ed25519.pub
// 5. test ssh using identity file
ssh -v username#hostname
more about see man sshd_config, search keywords HostKey and HostKeyAlgorithms
HostKey
Specifies a file containing a private host key used by SSH. The defaults are /etc/ssh/ssh_host_ecdsa_key,
/etc/ssh/ssh_host_ed25519_key and /etc/ssh/ssh_host_rsa_key.
Note that sshd(8) will refuse to use a file if it is group/world-accessible and that the HostKeyAlgorithms
option restricts which of the keys are actually used by sshd(8).
HostKeyAlgorithms
Specifies the host key signature algorithms that the server offers.

ssh_config AddKeysToAgent yes not working on Fedora

I've tried a multitude of things to get this working but despite having the AddKeysToAgent variable set to yes in my ssh_config the keys are not getting added.
This is my ssh-config:
Host *
AddKeysToAgent yes
Host remote
HostName /*hostname for remote here*/
User dcaglar2
IdentityFile ~/.ssh/personal_laptop
IdentitiesOnly yes
Host git
HostName github.com
User git
IdentityFile ~/.ssh/git
IdentitiesOnly yes
and running
ssh-add -l
returns
The agent has no identites.
I've checked the man pages ssh, ssh_config, but wasn't able to find anything.
I know that I can add a line to my .bashrc as a substitute but I just want to know what's wrong at this point.
From the description of AddKeysToAgent in the ssh_config manual:
If this option is set to yes and a key is loaded from a file, the key and its passphrase are added to the agent with the default lifetime, as if by ssh-add(1).
If I'm not mistaken, a key will be added to the agent the first time it's used. So try connecting to a remote and then run ssh-add -l again, you should then see the corresponding key in the output.

Scp denied when copying files into vagrant VM

I am trying to copy a demo.zip from local host to a newly initiated vagrant VM.
I tried command like this from my MAC terminal:
scp -P 2200 demo.zip vagrant#127.0.0.1:/home/vagrant
However, I get:
vagrant#127.0.0.1: Permission denied (publickey).
lost connection
And below is the log from vagrant ssh-config:
Host default
HostName 127.0.0.1
User vagrant
Port 2200
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
PasswordAuthentication no
IdentityFile /Volumes/dailystorage/program_analysis_VM/.vagrant/machines/default/virtualbox/private_key
IdentitiesOnly yes
LogLevel FATAL
The version of vagrant box is ubuntu-xenial (Ubuntu 16.04.3).
Could anyone tell what's going on here and possible ways out?
Thanks!
UPDATE: Solved by installing vagrant scp.
The name localhost normally resolves to the IPv4 loopback address 127.0.0.1
So you can try copy file from your local machine to local machine.
Try this:
scp -i /Volumes/dailystorage/program_analysis_VM/.vagrant/machines/default/virtualbox/private_key demo.zip vagrant#private_ip_address_your_remote_machine:/home/vagrant
I regenerated the key and it worked:
Generate Key Pair on master-1 node $ssh-keygen
Leave all settings to default.
View the generated public key ID at:
$cat .ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD......8+08b vagrant#master-1
Move public key of master to all other VMs
$cat >> ~/.ssh/authorized_keys <<EOF
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD......8+08b vagrant#master-1
EOF

SSH IdentitiesOnly=yes forwarding all my keys

I cannot for the life of me figure out why my SSH config is forwarding the wrong key. I have two keys, we'll call them home_rsa and work_rsa. I have done the following:
eval `ssh-agent`
ssh-add -K ~/.ssh/home_rsa
ssh-add -K ~/.ssh/work_rsa
Here is my ~/.ssh/config file:
Host home
ForwardAgent yes
HostName home.com
IdentityFile ~/.ssh/home_rsa
IdentitiesOnly yes
User home
Host work
ForwardAgent yes
HostName work.com
IdentitiesOnly yes
IdentityFile ~/.ssh/work_rsa
User work
Host bitbucket
IdentityFile ~/.ssh/home_rsa
Host bitbucket-work
IdentityFile ~/.ssh/work_rsa
Host bitbucket*
HostName bitbucket.com
User git
When I run the following…
ssh work
ssh git#bitbucket.org
…Bitbucket reports that I'm using my home user, though I'm clearly logged into my work server and should be forwarding my work key. If I add my SSH identities in the reverse order and run the same code above, Bitbucket reports I'm using my work user. Running ssh-add -l from my work server, I see that both SSH keys are being forwarded, but isn't that the job of IdentitiesOnly yes?
Really confused as to what's going on here.
Really confused as to what's going on here.
ForwardAgent option forwards the connection to your agent, with all the keys inside and does not forward your local ~/.ssh/config to remote host. What you do on the work host is controlled by your configuration on that host.
What are you trying to do with that?
You need to update your ssh keys with their equivalent bitbucket account first at their website (work user with work_rsa, user with user_rsa). Then maybe this could help.
Host bitbucket-work
HostName bitbucket.org
IdentitiesOnly yes
IdentityFile ~/.ssh/work_rsa
User work
Usage:
ssh bitbucket-work
sshbitbucket
As written in the accepted answer, selecting keys used for authentication is not related to what keys are forwarded. Separate ssh-agents are needed. Luckily that is easily configured.
From ssh-agent (1) we can learn that it takes a -a option to specify bind_address, and ssh_config (5) tells that ForwardAgent can be set to what turns out to be the same value.
Prepare your agents:
eval `ssh-agent -a ~/.ssh/home.agent`
ssh-add ~/.ssh/home_rsa
eval `ssh-agent -a ~/.ssh/work.agent`
ssh-add ~/.ssh/work_rsa
unset SSH_AUTH_SOCK SSH_AGENT_PID
Configure your ssh:
Host work
HostName work.example.com
ForwardAgent ~/.ssh/work.agent
IdentityAgent ~/.ssh/work.agent
Host home
HostName home.example.com
ForwardAgent ~/.ssh/home.agent
IdentityAgent ~/.ssh/home.agent
That should completely separate home and work keys. Setting IdentityAgent to a different value than ForwardAgent is left as an exercise for someone exposed to a threat level calling for such complexity.

SSH error in connection to a new Domain

I was already able to connect to the server via ssh properly. But recently after changing the server fixed-IP address and domain name, I cannot connect to the server by DNS name. Despite, I can ssh to the server with its IP address. The error of ssh with domain name is the following:
###########################################################
# WARNING: POSSIBLE DNS SPOOFING DETECTED! #
###########################################################
The DSA host key for example.com has changed,
and the key for the corresponding IP address X.X.X.X
has a different value. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /home/.ssh/known_hosts:10
remove with: ssh-keygen -f "/home/.ssh/known_hosts" -R X.X.X.X
###########################################################
# 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 DSA key sent by the remote host is
*:*:*:*:*:....
Please contact your system administrator.
Add correct host key in /home/.ssh/known_hosts to get rid of this message.
Offending DSA key in /home/.ssh/known_hosts:11
remove with: ssh-keygen -f "/home/.ssh/known_hosts" -R example.com
DSA host key for example.com has changed and you have requested strict checking.
Host key verification failed.
The answer is in the question:
ssh-keygen -f "/home/.ssh/known_hosts" -R example.com
You will get more info on the first google hit for the big message. WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
You should remove line 10 from your known_hosts because the system signalized you about the problem
Offending key for IP in /home/.ssh/known_hosts:10
I moved my ~/.ssh/known_hosts file and retried it worked. I guess the effect will just confirmation prompt for future connections, for the hosts that are there in known_hosts
I encountered the same problem.
I think the problem is that the item recorded in the "known-hosts" does not match something of the remote host(sorry, I don't know what the something is).
In my case, I just deleted the item in "known-hosts" according to the IP address of the remote host and ran ssh command again. Then it worked.
If you have got a backup of your /etc/ssh directory and want to restore it, just use
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user#hostname
for connecting once without checking.
Source: ssh man page
I faced same problem when I tried to do a pull.
Fix:
I deleted .ssh/known_hosts file on my system and retried pull, it worked.
Why this happened:
We had a gitlab migration. known_host file store gitlab ip, so it was not able to establish connectivity with existing host.
Just follow what is suggested.
sudo ssh-keygen -f "/root/.ssh/known_hosts" -R ip
sudo ssh-keygen -f "/root/.ssh/known_hosts" -R host
These commands will remove old fingerprints, and then you will be asked:
The authenticity of host 'host (ip)' can't be established.
ECDSA key fingerprint is SHA256:YrD+1E4JmdeObwEyQW3zGqNhXE//64MMZrHHaInE7w0.
Are you sure you want to continue connecting (yes/no)?
Write "yes" and you will see such message:
Warning: Permanently added 'host,ip' (ECDSA)
to the list of known hosts.
This will create new fingerprint in the /root/.ssh/known_hosts file.
For me, it couldn't find the file so I had to flip the file path and domain name like so:
ssh-keygen -R example.com -f ~/.ssh/known_hosts
Just delete the known_hosts file
$ rm .ssh/known_hosts
$ ssh ras.mydomain.com
Try connecting with ssh again
ssh username#server-ip-here