I ran into a similar problem and followed the steps using the debug mode. This was solved by reloading the keys to the ssh agent: ssh-add Apparently the keys are cached in the local ssh agent and we got the following error on the debug log: 'Agent admitted failure to sign using the key' Then we ran into another problem, after the switch. So the solution in our case was to switch the default rsa key to the one that contained When a key is default, there is no checking for client name. Obviously this will not work from any other client. ssh -vv we discovered was that the default key (id_rsa) was not accepted and instead the ssh client offered a key matching the client hostname: debug1: Offering public key: /home/user/.ssh/id_rsaĭebug2: we sent a publickey packet, wait for replyĭebug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,passwordĭebug1: Offering public key: /home/user/.ssh/id_dsaĭebug1: Offering public key: we sent a publickey packet, wait for replyĭebug1: Server accepts key: pkalg ssh-rsa blen 277 By running the ssh command in verbose mode you get a lot of information. ssh directory was NFS mounted and both clients were using the same keys). Our problem was that login worked from one client but not from another (the. We ran into the same problem and we followed the steps in the answer. (Depending on your Linux distribution, first / last line might be systemctl stop rvice / systemctl start rvice instead.) Stopping the SSH daemon does not kill existing connections so it is possible to do this through a remote terminal, but somewhat risky - if the connection does get broken somehow at a time when the debug replacement is not running, you are locked out of the machine until you can restart it. If it isn't possible to use an alternative port, you can temporarily stop the SSH daemon and replace it with one in debug mode. Look for something like debug1: trying public key file /path/to/home/.ssh/authorized_keysĪuthentication refused: bad ownership or modes for directory /path/to/home/ If you have root access to the server, the easy way to solve such problems is to run sshd in debug mode, by issuing something like /usr/sbin/sshd -d -p 2222 on the server (full path to sshd executable required, which sshd can help) and then connecting from the client with ssh -p 2222 This will force the SSH daemon to stay in the foreground and display debug information about every connection. ¹ Except on some distributions (Debian and derivatives) which have patched the code to allow group writability if you are the only user in your group. Ubuntu bug 965663 and Debian bug report #658675 this is patched in CentOS 6). Also, if SELinux is set to enforcing, you may need to run restorecon -R -v ~/.ssh (see e.g.Your private key file (on the local machine) must be readable and writable only by you: rw-, i.e.Your ~/.ssh/authorized_keys file (on the remote machine) must be readable (at least 400), but you'll need it to be also writable (600) if you will add any more keys to it.If ~/.ssh or authorized_keys is a symbolic link, the canonical path (with symbolic links expanded) is checked. Your home directory ~, your ~/.ssh directory and the ~/.ssh/authorized_keys file on the remote machine must be writable only by you: rwx- and rwxr-xr-x are fine, but rwxrwx- is no good¹, even if you are the only user in your group (if you prefer numeric modes: 700 or 755, not 775).When I first set up my ssh key auth, I didn't have the ~/.ssh folder properly set up, and it yelled at me. Make sure the permissions on the ~/.ssh directory and its contents are proper.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |