I have tried to setup public key connection between AIX to AIX and that's working and I am facing problem while I setup same public key connection between AIX and DataPower appliance.
I could see in logs that's connection established but while using public I am not able to login and everytime expecting to enter password manually.
Can someone please help on this?
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: ./***_rsa.pub
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
There are many, many reasons why client-side debugging (ssh -vvv ...) shows:
debug2: we did not send a packet, disable method
Many of these are listed in the answers to SSH public key won't send to server on Unix & Linux, but, unfortunately, the client does not give any indication as to which one applies.
When I was struggling with this, my main problem was getting server-side logging/debugging to show. Of great help was the following (paraphrased) suggestion taken from Ciro Santilli 冠状病毒审查六四事件法轮功's answer to How to check sshd log? on ServerFault:
Start a new SSH Server instance on a new port in debug mode with:
/usr/sbin/sshd -d -p 2222
then connect to it from the client with:
ssh -p 2222 user#host
If you have sudo access to the destination server, check the SSH logs (/var/log/secure), it may give you some clue. For my case it was a bad permission on the home directory.
chmod g-w /home/user
chmod 700 /home/user/.ssh
chmod 600 /home/user/.ssh/authorized_keys
Reference: https://chemicloud.com/kb/article/ssh-authentication-refused-bad-ownership-or-modes-for-directory/
I solved the same problem
(when I checked in my system there is .ssh/authorized_keys : the filename was wrong)
this way:
cp -p .ssh/authorised_keys .ssh/authorized_keys
Check the ssh configuration on remote server to find if remote system is accepting type of key being passed.
Check the file /etc/ssh/sshd_config and look for property PubkeyAcceptedKeyTypes to confirm that it accepts key type being passed. For instance, here the key type seems to be ssh-rsa, so that should be added to the list of PubkeyAcceptedKeyTypes
(or for maximium compatibility PubkeyAcceptedKeyTypes *)
Once added, restart sshd daemon
EX:
sudo sed -i "/.*PubkeyAcceptedKeyTypes.*/d" /etc/ssh/sshd_config
sudo sed -i "/.*RSAAuthentication.*/d" /etc/ssh/sshd_config
sudo sed -i "/.*PubkeyAuthentication.*/d" /etc/ssh/sshd_config
sudo sed -i "/.*PasswordAuthentication.*/d" /etc/ssh/sshd_config
sudo sed -i "/.*PermitRootLogin.*/d" /etc/ssh/sshd_config
echo "PubkeyAcceptedKeyTypes *" | sudo tee -a /etc/ssh/sshd_config
echo "RSAAuthentication yes" | sudo tee -a /etc/ssh/sshd_config
echo "PubkeyAuthentication yes" | sudo tee -a /etc/ssh/sshd_config
echo "PasswordAuthentication no" | sudo tee -a /etc/ssh/sshd_config
echo "PermitRootLogin no" | sudo tee -a /etc/ssh/sshd_config
sudo systemctl restart sshd.service
sudo systemctl status sshd.service | grep -i success
Refer to this answer SSH public key won't send to server.
In your log
Offering RSA public key: ./***_rsa.pub
...
we did not send a packet, disable method
It means that the client didn't send the key file. So make sure the key file exists.
Check the key file is in your local path
Make sure the public key content is copied into ~/.ssh/authorized_keys in remote server.
I've just had the same problem. Two raspberry Pis on my local network - one connected, one didn't (with the 'debug2: we did not send a packet, disable method' error)
after 4 hours I found the problem
Being used to uk spelling I created the 'authorised_users' file not 'authorized_users'
Doh !!
So what happened for me is that I have 2 VMs to access from my local machine (2 keys id_rsa.pub and id_rsa2.pub). I realized that my ssh connection is using id_rsa.pub by default for any ssh user#xx.xx.xx.xx connection. I solved my issue by adding a config file and specify the identity to be used for every host like the following :
vi ~/.ssh/config
Add both hostnames and their identity file as follows:
Host server1.nixcraft.com
IdentityFile ~/Users/.ssh/id_rsa1
Host server2.nixcraft.com
IdentityFile ~/Users/.ssh/id_rsa2
This happened to me and, after several hours banging my head against the wall, I realized there was a typo in the public key file. Instead of beginning with
ssh-rsa
there was a + sign at the beginning:
+ssh-rsa
I know it's obvious in retrospect, but it doesn't hurt to double check your file.
It looks like there can be a lot of things causing this problem. In my case I forgot to specified the User name in my ~/.ssh/config file. Apparently, it depends on your current login name.
Host dev
HostName 1.2.3.4
IdentityFile ~/.ssh/id_rsa
User John
This can happen if in your /etc/ssh/sshd_config you have the following entry
PubkeyAcceptedKeyTypes=+ssh-dss
as opposed to
PubkeyAcceptedKeyTypes +ssh-dss #this is the correct entry
After updating this, be sure to issue a
sudo systemctl restart sshd #Ubuntu
Think about selinux, if is enabled,do:
# sudo ausearch -c "sshd" --raw | audit2allow -M my-sshd
# sudo semodule -i my-sshd.pp
I checked and tried every instruction given here and after several hours of troubleshooting, I noticed the SSH server (which is my router) does not have a support for ed25519. Dropbear was spamming the following log: Pubkey auth attempt with unknown algo...
Using an RSA type fixed my issue.
Just for those who have the log "we did not send a packet, disable method" when trying to use a public key.
Check your sshd_config file on the remote server and force "PubkeyAuthentication" to "yes", even if it should be "yes" by default.
For me it solved my connection problem.
In my case the private key must have been added to the agent with:
ssh-add ~/.ssh/private_id_rsa
Related
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.
I have two different machines I can connect to in SSH, using a corporate VPN and proxy.
For that, my ~/.ssh/config has two hosts defined like this:
Host foobar
User alice
HostName XXX.XXX.XXX.XXX
ProxyCommand nc -x proxy-socks.foobar.com:4242 %h %p
The ProxyCommand is identical for both hosts, only the HostName and User are different. Each host has my public key, I can connect to each one simply by typing ssh foobar, no password is asked.
Now, I tried to use ansible to act on these machines. I have an inventory.cfg like that listing the name of both machines as defined in my ~/.ssh/config:
[vpn]
foobar
barfoo
I tried this simple command:
ansible -i inventory.cfg vpn -m ping
This worked for one of the machines, but not the other. Here is the redacted output:
foobar | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/libexec/platform-python"
},
"changed": false,
"ping": "pong"
}
barfoo | UNREACHABLE! => {
"changed": false,
"msg": "Failed to connect to the host via ssh: Welcome on barfoo [...] Permission denied (keyboard-interactive).",
"unreachable": true
}
Since I got the "welcome" message from the host in the output, it means that I did reach the host (so the proxy configuration should be ok).
But I cannot understand the error "Permission denied (keyboard-interactive).". I can connect to this machine by SSH without password (in fact, the admins even disabled password authentication, I had to send them my public key by e-mail).
I tried to explicitely specify my SSH key by adding --private-key $HOME/.ssh/id_rsa, but the error message was exactly the same.
By curiosity, I tried with Python's package fabric, but this worked fine for both machines:
import fabric
fabric.Connection('barfoo').run('hostname')
So it seems there is something weird going on between ansible and this machine configuration. Any clue?
EDIT
Using the advice from #GeralexGR, I added -vvvv in my ansible command to have more output.
In the output, I could see that ansible is making this call to SSH :
ssh -vvv -C -o ControlMaster=auto -o ControlPersist=60s -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o ConnectTimeout=10 -o 'ControlPath="/home/alice/.ansible/cp/dbd7338475"' barfoo '/bin/sh -c '"'"'echo ~ && sleep 0'"'"''
By trial and error, I could reduce this command to this one :
ssh -vvv -o PreferredAuthentications=publickey barfoo 'hostname'
This command fails on one machine but not the other. However, if I remove the PreferredAuthentications option, it works fine with both machines.
When it fails, it outputs something like that:
debug1: Next authentication method: publickey
debug1: Offering public key: [...]
[...]
debug1: Server accepts key: [...]
[...]
Authenticated with partial success.
debug1: Authentications that can continue: keyboard-interactive
debug3: start over, passed a different list keyboard-interactive
debug3: preferred publickey
debug1: No more authentication methods to try.
If I remove this option and do a simple ssh -vvvv, I get this in the output:
debug1: Next authentication method: publickey
debug1: Offering public key: [...]
[...]
debug1: Server accepts key: [...]
[...]
Authenticated with partial success.
debug1: Authentications that can continue: keyboard-interactive
[...]
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
[...]
debug1: Authentication succeeded (keyboard-interactive).
So, my guess is that keyboard-interactive is required for this machine. And indeed, if I put both publickey and keyboard-interactive in the option, this works:
ssh -vvv -o preferredauthentications=publickey,keyboard-interactive barfoo 'hostname'
So, back to ansible, I tried this:
ansible -vvvv --ssh-extra-args='-o preferredauthentications=publickey,keyboard-interactive' -i inventory.cfg -m ping vpn
But it still failed, I guess that this authentication mecanism is not possible with ansible? I am not sure why/how keyboard-interactive is needed here, since I am never prompted for a password. I will ask the admins of the machine.
The solution was kindly given by #Zeitounator in comments.
I added these two lines in my inventory.cfg file (with a dummy password):
[vpn:vars]
ansible_ssh_pass=foo
Now the initial ansible command works well.
Alternatively, using the --ask-pass option on the command line works as well:
ansible --ask-pass -i inventory.cfg -m ping vpn
For the context I asked a bit more information to the admins of the machine. This machine does not ask me for a password or anything, however, it asks to some external users (not me) to accept some terms and conditions. This is why the keyboard-interactive mechanism is needed.
Duo requires keyboard-interactive authentication, but ansible turned it off by -o KbdInteractiveAuthentication=no as seen from the ansible -vvv output as shown in the original post. I added ssh_args -o KbdInteractiveAuthentication=yes in ansible.cfg:
ssh_args = -o PreferredAuthentications=publickey,keyboard-interactive -o ControlMaster=auto -o ControlPersist=300s -o KbdInteractiveAuthentication=yes
and now it works fine.
My problem is the following. I wish to configure the .ssh/config as such, that when I write
ssh exampleX
It is the same as if I wrote
ssh -i /path/to/key.pem user#address
Note that the above command works.
Following the answers here I tried to create the file as
Host exampleX
HostName address
User user
IdentityFile /path/to/key.pem
Taken from
ssh -i /path/to/key.pem user#address
Yet when I run
ssh exampleX
I get the error
ssh: Could not resolve hostname exampleX: Name or service not known
But if I manually run the command
ssh -i /path/to/key.pem user#address
everything works. Where am I making the mistake in creating the file?
Edit
If I run
sudo ssh exampleX -v
I get the output
OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
ssh: Could not resolve hostname exampleX: Name or service not known
but if I run it without sudo i get a longer stream, that ends with
debug1: Authentications that can continue: publickey
debug1: Trying private key: /path/to/key.pem
Load key "/path/to/key.pem": Permission denied
debug1: No more authentication methods to try.
Permission denied (publickey).
Edit 2
Due to some confusion , I restate my question
What does the config file has to look like, so that running
ssh exampleX
will work the same as running
ssh -i /path/to/key.pem user#address
When you run your command through sudo, you are using the .ssh/config file that corresponds to the user that sudo runs as. If you really need to run this ssh command as root, you need the configuration added to ~root/.ssh/config instead of ~/.ssh/config.
If possible, run your ssh as a normal user, not as root.
(Since the question was edited, I edited accordingly my answer)
Check the permissions of the file ~/.ssh/config: it must have strict permissions: read/write for the user, and not accessible by others, as explained in the man page.
Check also you have read access (as a user) to the file /path/to/key.pem. The debug option you used with ssh suggests you don't have.
I've been trying "ssh localhost" on cygwin (I use WIndows 7), but it keeps asking for the password.
When I did "ssh -vvv localhost", I found out that the public key authentications were not happening (or failing). Hence, it was asking for the password.
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/xxxxxxxx/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
I'm not sure if it is unable to read the authorized_keys file, or if there is a timeout issue with this, or did the authentication fail? Is there any way to get more details?
I have done the following steps:
ssh-host-config. Answered yes to all.
Generated the RSA key and added it to the authorized_keys file.
net start sshd
ssh localhost
These are the permissions:
-rw------- 1 xxxxxxxx mkgroup 402 May 18 16:34 authorized_keys
-rw------- 1 xxxxxxxx mkgroup 1675 May 18 16:33 id_rsa
-rw-r--r-- 1 xxxxxxxx mkgroup 402 May 18 16:33 id_rsa.pub
-rw-r--r-- 1 xxxxxxxx mkgroup 171 May 18 14:33 known_hosts
There are a couple of issues as well:
- The group is displayed as mkgroup.
- The user "xxxxxxxx" does not exist in the localhost, I guess.
It was not displayed in "net user sshd". "xxxxxxxx" is a Domain account.
Could this be causing the public key authentication issue?
Just to see if there is any difference in the output, I deleted the authorized_keys file and tried. There was no difference in the output. It still sends a packet and proceeds to the next mode of authentication. There is no error message. Is there any other way to get more details (I'm a Cygwin and SSH n00b)? I would like to find it fails while reading the authorized_keys file.
Quick double-check, did you add your public key or private key to authorized_keys? It needs to be your public key.
I notice that the server is not responding with a "Server accepts key..." upon receipt of your pubkey_test and I have seen that when the public key is missing from the authorized_keys file on the server you're connecting to. You should see:
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
Easiest way to set it up is to use ssh-copy-id to do the work, e.g.,:
# ssh-copy-id localhost
That will create your authorized_keys file with the correct permissions. When you run this, you will be prompted for your password, because the server doesn't have the key. Once this command runs successfully, you'll be able to simply ssh to the server using your identity file. Note that ssh_config defaults the identity file to ~/.ssh/identity, ~/.ssh/id_rsa, ~/.ssh/id_dsa, so if you want to use a different file, you should set up an alias in ~/.ssh/config.
Hope this helps.
My problem was that I thought cygwin is OK if its files gets copy and pasted, so if I wanted to clone the installation I just copied and pasted C:\cygiwn64 folder somewhere else and ran the .bat file.
But I was wrong. Every time you copy a file with windows explorer the permission and ownerships gets corrupted in cygwin. So dont use windows explorer for making changes to any of the cygwin files, only use the command line apps like cp, mkdir, mv, vim, nano and others.
Also If you want to create a new installation just use the setup_x86_64.exe file and simply choose a new root directory for it and let the setup install packages and do the rest for you.
This way you make sure that nothing gets corrupted and you wont get surprised by some amazing error messages in the future.
At the very least you need to
chmod 700 id_rsa
This is
my setup
if it helps
-rwx------ 1 Steven None 1675 May 17 12:49 id_rsa
-rwx------ 1 Steven None 399 May 17 12:49 id_rsa.pub
-rwx------ 1 Steven None 803 May 18 01:13 known_hosts
It appears that there are some problems with your cygwin setup, which is why the user/group is not showing up correctly. You need to run mkgroup to generate your /etc/group, and possibly mkpasswd as well. I had a similar problem - I had to run mkpasswd to regenerate my /etc/passwd. After running mkpasswd, I could finally ssh into my localhost. It's a shame the debug info does not log enough info to easily diagnose the problem.
This page describes more about Windows security in cygwin: http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview
I had a similar problem setting up public key authentication (with similar verbose output from the client), though I was trying to do it from an Ubuntu client to a Cygwin SSHD server, and it was a very old Cygwin environment (version 1.5.12 on Windows 2000!). I had copied the public key using ssh-copy-id.
In my case, making the authorized_keys files world readable (mode 644) on the Cygwin side appeared to allow public key authentication to succeed.
From what I've seen, mode 600 is standard, so perhaps this "fix" in my case is actually a sign of a problem elsewhere in the Cygwin SSHD setup. But now that pub key authentication is finally working, I probably won't be digging any deeper.
Re-Install it on
C:\
Many problems will be solved.
I added the public SSH key to the authorized_keys file. ssh localhost should log me in without asking for the password.
I did that and tried typing ssh localhost, but it still asks me to type in the password. Is there another setting that I have to go through to make it work?
I have followed the instructions for changing permissions:
Below is the result if I do ssh -v localhost.
debug1: Reading configuration data /home/john/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/john/.ssh/identity type 1
debug1: identity file /home/john/.ssh/id_rsa type -1
debug1: identity file /home/john/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu3
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /home/john/.ssh/known_hosts:12
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/john/.ssh/identity
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Then it asks for a passphase after the above log. Why isn't it logging me in without a password?
You need to verify the permissions of the authorized_keys file and the folder / parent folders in which it is located.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
For more information see this page.
You may also need to change/verify the permissions of your home directory to remove write access for the group and others.
chmod go-w ~
SELinux can also cause authorized_keys not to work. Especially for root in CentOS 6 and 7. There isn't any need to disable it though.
Once you've verified your permissions are correct, you can fix this like so:
chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
restorecon -R -v /root/.ssh
Setting ssh authorized_keys seem to be simple, but it hides some traps I'm trying to figure.
-- SERVER --
In /etc/ssh/sshd_config, set passwordAuthentication yes to let the server temporarily accept password authentication
-- CLIENT --
consider Cygwin as Linux emulation and install & run OpenSSH
1. Generate private and public keys (client side)
# ssh-keygen
Here pressing just Enter, you get default two files, "id_rsa" and "id_rsa.pub", in ~/.ssh/, but if you give a name_for_the_key, the generated files are saved in your current working directory.
2. Transfer the your_key.pub file to the target machine, ssh-copy-id user_name#host_name
If you didn't create a default key, this is the first step to go wrong
... you should use:
ssh-copy-id -i path/to/key_name.pub user_name#host_name
3. Logging ssh user_name#host_name will work only for the default id_rsa file, so here is the second trap. You need to do ssh -i path/to/key_name user#host
(Use ssh -v ... option to see what is happening.)
If the server still asks for a password then you gave something. To Enter passphrase: when you've created keys (so it's normal).
If ssh is not listening on the default port 22, you must use ssh -p port_nr.
-- SERVER -----
4. Modify file /etc/ssh/sshd_config to have
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
(uncomment if case)
This tells ssh to accept file authorized_keys and look in the user home directory for the key_name sting written in the .ssh/authorized_keys file.
5 Set permissions on the target machine
chmod 755 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
Also turn off pass authentication,
passwordAuthentication no
to close the gate to all ssh root/admin/....#your_domain attempts.
6. Ensure ownership and group ownership of all non-root home directories are appropriate.
chown -R ~ usernamehere
chgrp -R ~/.ssh/ user
===============================================
7. Consider the excellent http://www.fail2ban.org
8. Extra
SSH tunnel to access a MySQL (bind = 127.0.0.1) server
Also be sure your home directory is not writeable by others:
chmod g-w,o-w /home/USERNAME
This answer is stolen from here.
The desperate may also make sure they don't have extra newlines in the authorized_keys file due to copying file id_rsa.pub's text out of a confused terminal.
Listing a public key in .ssh/authorized_keys is necessary, but not sufficient for sshd (server) to accept it. If your private key is passphrase-protected, you'll need to give ssh (client) the passphrase every time. Or you can use ssh-agent, or a GNOME equivalent.
Your updated trace is consistent with a passphrase-protected private key. See ssh-agent, or use ssh-keygen -p.
In the following, user is your username.
mkdir -p /home/user/.ssh
ssh-keygen -t rsa
touch /home/user/.ssh/authorized_keys
touch /home/user/.ssh/known_hosts
chown -R user:user /home/user/.ssh
chmod 700 /home/user/.ssh
chmod 600 /home/user/.ssh/id*
chmod 644 /home/user/.ssh/id*.pub
chmod 644 /home/user/.ssh/authorized_keys
chmod 644 /home/user/.ssh/known_hosts
Beware that SELinux can trigger this error as well, even if all permissions seem to be OK. Disabling it did the trick for me (insert usual disclaimers about disabling it).
Look in file /var/log/auth.log on the server for sshd authentication errors.
If all else fails, then run the sshd server in debug mode:
sudo /usr/sbin/sshd -ddd -p 2200
Then connect from the client:
ssh user#host -p 2200
In my case, I found the error section at the end:
debug1: userauth_pubkey: test whether pkalg/pkblob are acceptable for RSA SHA256:6bL+waAtghY5BOaY9i+pIX9wHJHvY4r/mOh2YaL9RvQ [preauth]
==> debug2: userauth_pubkey: disabled because of invalid user [preauth]
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth]
debug3: userauth_finish: failure partial=0 next methods="publickey,password" [preauth]
debug3: send packet: type 51 [preauth]
debug3: receive packet: type 50 [preauth]
With this information I realized that my sshd_config file was restricting logins to members of the ssh group. The following command fixed this permission error:
sudo usermod -a -G ssh NEW_USER
Try "ssh-add" which worked for me.
The thing that did the trick for me finally was to make sure that the owner/group were not root, but user:
chown -R ~/.ssh/ user
chgrp -R ~/.ssh/ user
Issue these on the command line:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
After you do this, make sure your directory is like this:
drwx------ 2 lab lab 4.0K Mar 13 08:33 .
drwx------ 8 lab lab 4.0K Mar 13 08:07 ..
-rw------- 1 lab lab 436 Mar 13 08:33 authorized_keys
-rw------- 1 lab lab 1.7K Mar 13 07:35 id_rsa
-rw-r--r-- 1 lab lab 413 Mar 13 07:35 id_rsa.pub
In my case I needed to put my authorized_keys file in .openssh.
This location is specified in /etc/ssh/sshd_config under the option AuthorizedKeysFile %h/.ssh/authorized_keys.
Another tip to remember: Since v7.0 OpenSSH disables DSS/DSA SSH keys by default due to their inherit weakness. So if you have OpenSSH v7.0+, make sure your key is not ssh-dss.
If you are stuck with DSA keys, you can re-enable support locally by
updating your sshd_config and ~/.ssh/config files with lines like so: PubkeyAcceptedKeyTypes=+ssh-dss
Another issue you have to take care of: If your generated file names are not the default id_rsa and id_rsa.pub.
You have to create the .ssh/config file and define manually which id file you are going to use with the connection.
An example is here:
Host remote_host_name
HostName 172.xx.xx.xx
User my_user
IdentityFile /home/my_user/.ssh/my_user_custom
Make sure that the target user has a password set. Run passwd username to set one. This was required for me even if password SSH login was disabled.
Just look in file /var/log/auth.log on the server. Setting additional verbosity with -vv on the client side won't help, because the server is unlikely to offer too much information to a possible attacker.
My problem was a modified AuthorizedKeysFile, when the automation to populate /etc/ssh/authorized_keys had not yet been run.
$sudo grep AuthorizedKeysFile /etc/ssh/sshd_config
#AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile /etc/ssh/authorized_keys/%u
Make sure you've copied the whole public key to authorized_keys; the ssh rsa prefix is necessary for the key to work.
I issued sudo chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys and chmod go-w $HOME $HOME/.ssh from a previous answer and it fixed my problem on a CentOS 7 box that I had messed up the permissions on while trying to get Samba shares working.
It seems like a permission problem. Usually it happens if the permission of some file/directory is not correctly set up. In most case they are ~/.ssh and ~/.ssh/*. In my case they are /home/xxx.
You can change the log level of sshd by modifying file /etc/ssh/sshd_config(search for LogLevel, and set it to DEBUG) and then check the output in file /var/log/auth.log to see what happened exactly.
This solves my problem:
ssh-agent bash
ssh-add
In my case it's because the user's group is not set in AllowGroups of configuration file /etc/ssh/sshd_config. After adding it, everything works fine.
You need to verify the properties of the files.
To assign the required property, use:
$ chmod 600 ~/.ssh/sshKey
$ chmod 644 ~/.ssh/sshKey.pub
I use it this way.
cat ~/.ssh/id_rsa.pub| ssh user#remote-system 'umask 077; cat >>~/.ssh/authorized_keys'
On that note, make sure your sshd configuration has this line:
PermitRootLogin without-password
Set as the above, and then restart sshd (/etc/init.d/sshd restart).
Log out and try log in in again!
The default, I believe, is:
PermitRootLogin no
I have the home directory in a non-standard location and in sshd logs I have the following line, even if all permissions were just fine (see the other answers):
Could not open authorized keys '/data/home/user1/.ssh/authorized_keys': Permission denied
I have found a solution here: Trouble with ssh public key authentication to RHEL 6.5
In my particular case:
Added a new line in /etc/selinux/targeted/contexts/files/file_contexts.homedirs:
This is the original line for regular home directories:
/home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0
This is my new line:
/data/home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0
Followed by a restorecon -r /data/ and a sshd restart.
I had this problem and none of the other answers solved it, although of course the other answers were correct.
In my case, it turned out that the /root directory itself (not e.g. /root/.ssh) had the wrong permissions. I needed:
chown root.root /root
chmod 700 /root
Of course, those permissions should be something like that (maybe chmod 770) regardless. However, it specifically prevented sshd from working, even though /root/.ssh and /root/.ssh/authorized_keys both had correct permissions and owners.
I had this problem when I added the group of the login user to another user.
Let's say there is an SSH-login user called userA and a non-SSH-login user userB. userA has the group userA as well. I modified userB to have the group userA as well. The lead to the the described behaviour, so that userA was not able to login without a prompt.
After I removed the group userA from userB, the login without a prompt worked again.
I have had the same issues since before, but today I had to set up one new server. What I could learn in this time...
The basic process to allow authentication without a password is as follows:
On the server, validate if your home folder has the .ssh folder. If it doesn't exist, you can create it manually with a mkdir command and then to assign the correct permissions with chmod, or otherwise you could use the same utility, ssh-keygen, to create private/public keys, but on the server for your user. This process will create the required .ssh folder.
On the local machine you also need to create the private/public keys with the ssh-keygen utility.
You need to move your public key to file .ssh/authorized_keys to the server. To achieve this, you can use the ssh-copy-id utility, or you can do it manually using the cat and scp commands.
In the best of cases, this will allow connect to your server without a password.
OK, now the issues that I found today: first there are several key generation algorithms: rsa, dsa, ecdsa and ed25519 and there are many releases of OpenSSH (you can have one version on your local machine and an old version on your server):
Hint: Using ssh -v helps to see additional information when you are connecting to the server.
OpenSSH_8.2p1 Ubuntu-4, OpenSSL 1.1.1f 31 Mar 2020
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
The error in my case today was that I was trying to use a key with a "newer" generation algorithm that was not supported by the installed version of OpenSSH on the server. When I had checked the supported algorithms, another error that I found was that the server was rejecting my algorithm:
debug1: Skipping ssh-dss key /home/user/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes
After that, I had to change the algorithm of my key and then I could connect with the server successfully.
OpenSSH releases notes: Link