I have a server setup to only allow private/public keys, except for an SFTP group:
Match Group sftp
PasswordAuthentication yes
ForceCommand internal-sftp
ChrootDirectory %h
That works fine, however, I have a user that wants to use SFTP with public key. I have that user set up and SSH works perfectly fine, however, when I add the user to the "sftp" group, authentication stops. I do not want this user to be able to SSH in and I want to Chroot them to their home directory.
I checked that root owns the home directory and that it's not writeable by other groups. The following debugging info isn't leading me anywhere useful either:
sftp -vv -i ~/.ssh/id_rsa testuser#serveraddress
Gives the following:
...
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/myuser/.ssh/id_rsa
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
debug1: Next authentication method: password
tester#serveraddress's password:
Any ideas why it seems to be just completely ignoring the key? Again, if I remove the user from the "sftp" group, logging in with key works fine.
Related
Although a simple question, I have searched for days without success.
M = My machine
J = Jump Host
S = Server
Jump Host has my public key on authorized_keys.
Server has J's public key on authorized_keys.
Allowed connections (due to key authentication):
M -> J
J -> S
How is it possible for me to ssh into S from my machine?
My current configuration is:
host jump
user root
HostName x.x.x.x
host server
user root
HostName x.x.x.x
port 22
ForwardAgent no
ProxyCommand ssh jump -W %h:%p
It does not work as it tries to login with M's key.
Here's the ssh log
debug1: Host 'x.x.x.x' is known and matches the ECDSA host key.
debug1: Found key in /Users/xxxxx/.ssh/known_hosts:1542
...
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/xxxxx/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/xxxxx/.ssh/id_dsa
debug1: Trying private key: /Users/xxxxx/.ssh/id_ecdsa
debug1: Trying private key: /Users/xxxxx/.ssh/id_ed25519
debug1: No more authentication methods to try.
Permission denied (publickey).
Killed by signal 1.
Yes. Of course it tries to login with M's key. You are not really connecting from J to S.
The first ssh connection is from M to J. This one simply sets up some forwarding. The second ssh connection is directly from M to S using the forwarding set up by the first ssh. - No chance to use the key on J.
You might use ssh -A jump ssh-add to add J's key to your agent.
Then your setup should work fine.
Another idea might be something like ssh -t jump ssh server. This way you log into J and from there you log into S, pretty much as you expected it.
Well, I have 2 computers call 120 and 110. I am trying to configure a ssh connection without password from 110 to 120. This is what i have done in the 120:
1- ssh-keygen -t rsa
2- scp ~/.ssh/id_rsa.pub root#110:.ssh/authorized_keys
and then in the 110:
1- chmod 700 ~/.ssh/authorized_keys
This steps don't work because it keeps asking for the password. So, I tried to do the opposite, from 120 to 110 and doing exactly the same thing it works.
I also change the PermitRootLogin yes in the /etc/ssh/sshd_config file of both computers.
I am out of ideas. Any suggestion?
EDIT:
This is what I got using ssh -vv:
debug2: we did not send a packet, disable method
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /root/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
root#192.168.1.120's password:
Try running this (after generating the key):
ssh-add
I have followed Jeffrey Way's instructions and I am continuously getting the same SSH error within Terminal.
I am wanting to connect through Sequel Pro and upon digging further into it, this is the most accurate log description:
debug1: Host 'IP ADDRESS' is known and matches the RSA host key.
debug1: Found key in /Users/ben/.ssh/known_hosts:17
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/ben/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: /Users/ben/.ssh/id_rsa.pub
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).
I generate my SSH key this way:
ssh-keygen -t rsa -C "your_email#example.com"
Then copy it into Laravel Forge by:
cat ~/.ssh/id_rsa.pub | pbcopy
It saves without error. But then I try forge#ip_address and it returns the Permission denied error, always.
Any help would be hugely appreciated.
I had the same problem follwing the instructions.
Try:
pbcopy < ~/.ssh/id_rsa.pub
I solved this problem by recreating the server on Forge. pbcopy also failed to work.
If you added your key from the Forge "Account" > "SSH keys" page after creating your server, you'll need to also add your key here:
Servers > [your server name] > SSH keys > Add
Env:
VM A : the machine I want to access with out password
VM B : I want to access VM A without password from the machine
Problem Description:
As I want to access VM A from VM B without password, I want first inject VM B's public key into VM A, but I still need password if I use ssh-copy, so I try to inject the file by mount.
The steps:
Start VM A from LiveCD
Mount VM A's root disk(contains the OS)
Create an authorized_keys file under ${mount_point}/root/.ssh/
Cat the VM B's public key into the authorized_keys file
Stop the VM A and remove the LiveCD then start the VM A again
Access the VM A from VM B by command
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o PasswordAuthentication=no root#9.112.224.130
Results:
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 368 bytes for a total of 1645
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
But after I did following commands, it works (file mode are all 600 and not difference with diff command)
mv authorized_keys authorized_keys_bak
cp authorized_keys_bak authorized_keys
so I try to inject it again, but for this time, I create an empty authorized_keys file before start from LiveCD, and skip the step 3, other step are all the same, for this time the VM B can access VM A without password
Questions:
The property for authorized_keys and authorized_keys_bak are all the same, why one works, one not works?
I authorized_keys can works only when I create the file not mount from LiveCD?
ssh-copy-id will ask you password one time to inject the keys into remote system.
Logs which you have shown is from ssh client. We would need ssh server logs as well to check why ssh server is not able to verify user credentials.
From client logs, we can say, it has tried for publickey based (without password) authentication but it failed (means rejected by server). So remaining method is "keyboard-interactive" (which is supported by server) but client doesn't support it so no authentication method to try so it failed.
Can you also check following things for working & non-working scenerio
check user's publickey on client and server which is used for authentication
on client -> /users//.ssh/id_rsa.pub
on server -> /etc/ssh/authorized_keys (check entry for your username)
I have been trying to connect from one EC2 instance to another using ssh public keys and have been having a very tough time.
Here is the scenario:
I need to have box 2 scp a file from box 1 in a script. This script will need to be able to scp without a password so I need to setup public keys.
On box 2 I ran ssh-keygen –t rsa and generated id_rsa and id_rsa.pub
I copied id_rsa.pub to box 1
I moved id_rsa.pub to .ssh and ran cat id_rsa.pug >> authorized_keys
I changed permissions of all .ssh directory to 700 on both boxes and the files themselves to 600.
I have changed the sshd_config settings on box 1 to:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
And then restarted ssh
/sbin/service sshd restart
When I try to scp or ssh into box1 from box1 I get the error:
Address 67.22.33.1 maps to ec2-67-22-33-1.compute-1.amazonaws.com, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
tomcat#tomcat1.****.com's password:
Any ideas?
I made that change and tried scp to tomcat1 and it failed. Here is the output:
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to tomcat1.****.com [67.22.33.15] port 22.
debug1: Connection established.
debug1: identity file /home/tomcat/.ssh/identity type -1
debug1: identity file /home/tomcat/.ssh/id_rsa type 1
debug1: identity file /home/tomcat/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
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
The authenticity of host 'tomcat1.****.com (67.22.33.15)' can't be established.
RSA key fingerprint is 5a:3e:fe:be:b8:0e:05:63:bf:ab:c8:4f:e5:91:db:a0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'tomcat1.****.com,67.22.33.15' (RSA) to the list of known hosts.
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: Trying private key: /home/tomcat/.ssh/identity
debug1: Offering public key: /home/tomcat/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/tomcat/.ssh/id_dsa
debug1: Next authentication method: password
Your authorized keys line should be
AuthorizedKeysFile %h/.ssh/authorized_keys
The server is looking in the wrong directory for your server.
UPDATE - FIXED IT
restorecon -R -v -d /root/.ssh
This is a known issue with RH where directories get mislabelled and PAM prevends sshd from reading authorized_hosts when run as init script. You'll see the errors if you stumble across /var/log/audit/audit.log. Rare it seems but painful when it happens!
More details at https://bugzilla.redhat.com/show_bug.cgi?id=499343
ORIGINAL POST
I've just hit what looks like exactly this problem. I had a poorly tuned VirtualBox (I hadn't told vbox to use 64bit) -- which when I cloned and restarted (in vbox RedHat 64-bit mode), started asking me for a password.
The original image was fine -- with identical settings -- so I think the suggestion of being networking-related might be relevant, or else to do with server keys.
The weird thing however is that if on the box, I kill the sshd process which autostarted, then manually run /usr/sbin/sshd as root, I can log in passwordless fine. A silly workaround, but usable.
So it is an /etc/init.d/sshd issue. But I haven't been able to track down what it is ... have tried chucking out most of the stuff in that script but it still prompts for password when invoked as /etc/init.d/sshd start but not when at /usr/sbin/sshd.
Maybe these comments can help, and someone can then help further!?
Try removing box1 IP from ~/.ssh/known_hosts, so it renews. Perhaps ssh disables key authentication due to possible 'man in the middle' attack.
If it won't help, add line
GSSAPIAuthentication no
in your /etc/ssh/ssh_config file.
I think this link will solve your problem and I use it to solve my ssh not login problem. The keypoint is to run
ssh root#node02 'restorecon -R -v /root/.ssh'
this command will fix SE
http://blog.firedaemon.com/2011/07/27/passwordless-root-ssh-public-key-authentication-on-centos-6/
After following previous steps I had to set the permission to ".." in the .ssh folder:
Once I had for ~/.ssh:
drwx------ 2 build build 4096 Nov 4 14:35 .
drwx------ 6 build build 4096 Nov 4 14:34 ..
-rw------- 1 build build 400 Nov 4 14:35 authorized_keys
It worked!
Thanks. Damian
I had the exact same problem and have been scratching my head for an entire afternoon.
It turned out to be a small sshd_config file issue.
first, change access mod on .ssh folder of the remote host to user access only.
chmod 700 ~/.ssh
next, go to /etc/ssh/sshd_config, change StrictModes yes to StrictModes no. If it's commented out, then specifically add StrictModes no into the file.
That solved the issue.
And one more thing I just found, I had to edit the .ssh/authorized_keys file to and make hostname fully qualified. Otherwise, I couldn't use the fully qualified name in the scp/ssh command. Now both fully qualified (like "host.company.com") & the relative name ("host") work, given that both hosts are in the "company.com" domain. ssh-keygen created the public key file with just the hostname.