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.
Related
After changing the sshd port in OpenSSH 8.2, I found that the ssh fingerprint changed. This surprised me since I had assumed it was just dependent on the public key.
What does the fingerprint depend on? Is the port part of it?
On closer examination it looks like the key changed from ssh-rsa to ecdsa-sha2-nistp256. It looks like the server has multiple key files. What determines which key is used and what might have caused a change?
I haven't found the official documentation, but ran into a similar confusion so just experimented a bit.
The hostnames in fingerprints (in .ssh/known_hosts) are hashed, but you can check them with ssh-keygen -H -F 'remote' (you'd see Host remote found...)
It seems that if you're using the default port (22), when you run ssh remote the first time, the fingerprint will only contain the hostname.
You can check this with ssh-keygen -H -F 'remote' (you'd see Host remote found...)
Now, if you change the sshd port on remote (say, to 1234), seems that ssh is still happy with it, because it tries matching against the hostname without the port.
You can see that with the -v flag:
$ ssh -v remote -p 1234
debug1: Authenticating to remote:1234 as 'user'
...
debug1: checking without port identifier
debug1: Host 'remote' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:11
However -- if the first time you ssh onto remote is with a custom port (ssh remote -p 1234), then it seems to remember the hostname with port:
ssh-keygen -H -F 'remote' -- doesn't result in anything
ssh-keygen -H -F '[remote]:1234' -- results in a match
The ssh output changes slightly too, it's checking both host and port now:
$ ssh -v remote -p 1234
...
debug1: Host '[remote]:1234' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:12
...
Now if you change the remote sshd port to something else, say back to 22, and run ssh remote, ssh won't be able to verify the host, because it only knows about [remote]:1234, not remote.
(I guess in theory it could still check all 65535 ports against .ssh/known_hosts and give a friendlier error message).
Regarding the key choice: same -v flag might be helpful here:
...
debug1: Will attempt key: /home/user/.ssh/id_rsa RSA <redacted> agent
debug1: Will attempt key: /home/user/.ssh/id_dsa
debug1: Will attempt key: /home/user/.ssh/id_ecdsa
debug1: Will attempt key: /home/user/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/user/.ssh/id_ed25519
debug1: Will attempt key: /home/user/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/user/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<redacted>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_rsa RSA <redacted> agent
debug1: Server accepts key: /home/user/.ssh/id_rsa RSA <redacted> agent
...
I've used ddev auth ssh to add my ssh identities to my DDEV-Local projects.
But when I use ssh to connect to an external host, ssh example.com I get "Too many authentication failures"
Received disconnect from 174.127.116.22 port 22:2: Too many authentication failures
Disconnected from 174.127.116.22 port 22
When I use ssh -v example.com I see it trying six different keys before giving up with the "Too many authentication failures":
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: rfay#rfay-mbp-2017.local RSA SHA256:LrokWMbl1bD0vV0z7Qpn4HLd168NYSIAbqsek6aXIaE agent
debug1: Authentications that can continue: publickey
debug1: Offering public key: rfay#rfay-mbp-2017.local RSA SHA256:ecpRhfcaRWS8EfmYyLuJ81ayhyPWAZd9MG3mKOUKMqA agent
debug1: Authentications that can continue: publickey
debug1: Offering public key: rfay#rfay-mbp-2017.local RSA SHA256:07LrVlDSWu4r+4Eb6WP8FpWYYcREw7IcGm4rtp5v+Ws agent
debug1: Authentications that can continue: publickey
debug1: Offering public key: rfay#rfay-mbp-2017.local RSA SHA256:6L9cIsLlu858CPgb5zZ3v3+5p808uNencyAxJ0S9wOM agent
debug1: Authentications that can continue: publickey
debug1: Offering public key: rfay#rfay-mbp-2017.local RSA SHA256:HwksLkZqEXAK6Zo21+y/C508Mjx2I7EvUQWFScKHsAQ agent
debug1: Authentications that can continue: publickey
debug1: Offering public key: rfay#rfay-mbp-2017.local RSA SHA256:dsGaELF0OPNyQfIYZoEyI+dP3AQqh5r+15iUwfalNtc agent
Received disconnect from 174.127.116.75 port 22:2: Too many authentication failures
Disconnected from 174.127.116.75 port 22
How can I solve this problem? Note that I have 10 different private keys in my ~/.ssh directory.
It seems ssh wasn't designed for use with loads and loads of private keys, but some people end up with lots of them anyway. (Note that you can use a single private key for many, many purposes; all you share with the world or an external service is the public key, which does not give away any information about the private key.)
Since ddev auth ssh is setting up an ssh agent for you, and there doesn't seem to be a way to make ssh choose a specific identity from among the identities provided by the agent, you'll need to use one of two workarounds.
Workaround #1: Use just a few keys
You could, of course, winnow down the number of keys in your ~/.ssh directory to 6 or fewer (6 is the default in sshd on the server side for MaxAuthTries). But let's assume you don't want to do that.
Create a directory, maybe ~/ddev-ssh-keys. In that directory, either copy or symlink the 6 keys you use most often. So cd ~/ddev-ssh-keys && for item in goodkey1 goodkey2 ... googdkey6; do ln -s ~/.ssh/$item; done (or any way you want to accomplish the linking or copying).
Now ddev auth ssh -d ~/ddev-ssh-keys and the ddev-ssh-agent will only have those 6 keys. If they're the right keys to solve most of your problems, you should be good with this approach.
Workaround #2: Copy keys into the container using .ddev/homeadditions
This workaround will let you actually copy the key(s) you want into the web container. This isn't probably as secure as the first approach (because you should never really copy your private keys anywhere), but it works.
If you really want the keys in the container (as opposed to using the agent), then mkdir -p .ddev/homeadditions/.ssh && cp ~/.ssh/<yourimportantkey(s)> .ddev/homeadditions/.ssh && chmod 700 .ddev/homeadditions/.ssh && chmod 600 .ddev/homeadditions/.ssh/*. You can then use the .ddev/homeadditions/.ssh/config file any way you want, including specifying keys.
This answer is adapted from https://github.com/drud/ddev/pull/2224
This is an extension of rfay's Workaround #2, to make it more secure. You can use the public part of a key pair to specify which private key you want to use from the ssh agent. So, instead of copying your private keys into the .ddev/homeadditions/.ssh folder, just copy the pub keys. For example, mkdir -p .ddev/homeadditions/.ssh && cp ~/.ssh/*.pub .ddev/homeadditions/.ssh && chmod 700 .ddev/homeadditions/.ssh && chmod 600 .ddev/homeadditions/.ssh/*.
Technically, you don't even need to 'chmod 600' the key files since they're the pub keys, but it does add some security.
You can then specify the key to use on the command line:
ssh -i ~/.ssh/id_rsa.pub example#example.com
ssh -o IdentityFile=~/.ssh/id_rsa.pub example#example.com
Or you can specify the IdentityFile in your .ssh/config file.
I am trying to set up a new ssh key for a gcloud instance. I followed the instructions here verbatim (https://cloud.google.com/compute/docs/instances/adding-removing-ssh-keys), generating a new key, putting the public rsa-ssh key with my username on the SSH Keys section of the Metadata tab in the Google Cloud Platform interface, and setting the appropriate permissions for my public and private keys with chmod.
I am getting an error which ends as follows, when attempting to ss using the -vvv verbose flag:
...
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/erickofman/.ssh/salsadb
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
I have (with a co-worker) ensured that my public key is contained within the authorized_keys file in the server's .ssh folder. Thinking that perhaps something was just stale, I also tried restarting the ssh server using service sshd restart to no avail.
I also tried setting up ssh using the gcloud tool, same result.
I have the correct role/permissions for the site from what I can tell.
This is what the log looks like on the server side:
admin#awesome-website:~$ tail /var/log/auth.log
Nov 15 20:40:16 awesome-website sshd[18846]: input_userauth_request: invalid user ekofman [preauth]
Nov 15 20:40:17 awesome-website sshd[18846]: Connection closed by 10.100.100.10 port 90001 [preauth]
Nov 15 20:41:17 awesome-website sshd[18848]: Connection closed by 200.200.20.20 port 90002 [preauth]
Been banging my head on this for a bit, any help much appreciated!
Whelp, turns out that new ssh keys do not get incorporated unless a full instance restart is effected. Not ssh server restart, but a full instance restart (stop gcloud instance, then start gcloud instance). It doesn't say this in the documentation, good to know for future reference.
Per this make sure you're .ssh/authorized_keys in your user's directory.
You also want to ensure your .ssh directory and authorized_keys have the proper permissions set. (700 and 600 respectively).
sudo chmod 700 ~/.ssh
sudo chmod 600 ~/.ssh/authorized_keys
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.
I can't ssh from client "A" to server "B" (but I can from many other ssh clients on the same subnet than "A" - all are *nux machines)
serverA>ssh -v -p PORT user#serverB
OpenSSH_5.3p1 Debian-3ubuntu5, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to serverB [serverB] port PORT.
debug1: Connection established.
debug1: identity file /home/user_A/.ssh/id_rsa type -1
debug1: identity file /home/user_A/.ssh/id_dsa type 2
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu5
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr 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: checking without port identifier
Host key verification failed.
I've already checked these following pts on client A - as server A looks to be the point - :
user_A/.ssh directory permissions : 700 (see man ssh)
user_A/.ssh/known_hosts permissions: 644 (see man ssh)
user_A/.ssh/known_hosts: does NOT content serverB host public key
otherusers/.ssh/known_hosts: does NOT content serverB host public key
I've tried :
deleting known_hosts on server A: same error remains
to empty known_hosts on server A: same error
checking if host key names are matching the ssh server config: ok (HostKey /etc/ssh/ssh_host_rsa_key)
regenerating server B host keys (ssh-keygen -t dsa/rsa -f /etc/ssh/ssh_host_dsa/rsa_key) : same error
ssh -p PORT me#localhost on serverB: it also works as from other ssh clients
So I'm really stacked now ! ssh specialists welcome home.
Thx in advance
Don't understand what exactly I did wrong for this particular server..
What remains "strange" is that destroying "known_hosts" on the client side did not drive to the expected positive effect.
Anyway pls find hereafter what I did manually, quite ugly but works:
Note: This assumes full access to both machines (client and server)
server side : regenerate the 2 pairs of keys (rsa and dsa)
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
client side:
generate a pair of dsa keys (private and public) for the user "foo"
ssh-keygen -t dsa -f /home/foo/.ssh/my_client_key
add this new key to the ssh-agent if running
ssh-add /home/foo/.ssh/my_client_key
add the content of the server ssh_host_rsa_key.pub to the client /home/foo/.ssh/known_hosts, after the IP/port:
[server_ip]:server_port copy/paste here the server public rsa key (ctrl+shift+C/V)
[server_ip]:server_port copy/paste here the server public dsa key (ctrl+shift+C/V)
now back to the server side :
copy/paste the client public key /home/foo/.ssh/my_client_key.pub into /home/bar/.ssh/.authorized_keys in order to allow connection to the user "foo" to connect to "bar" account:
make sure of the path consistency with /etc/ssh/sshd_config to be able tu use the file .authorized_keys :
AuthorizedKeysFile %h/.ssh/.authorized_keys
restart the ssh server
/etc/init.d/ssh restart
client: now the client "foo" can ssh to the user "bar" on the server :
foo#client>$ ssh -p PORT bar#server_ip
Note: in my case, both client and server are running locally within VM's. Do not use these settings for production obviously.
EDIT: Reading a bit more carefully the man ssh pages, it should be possible to get around this in a much proper manner, ref to the man: "The StrictHostKeyChecking option can be used to control logins to machines whose host key is not known or has changed."
I had the same problem, on an embedded system that I have no control over. I think the way I fixed it was to install all of the public keys on both sides, manually.
The problem started with ssh complaining that 'ssh-askpass' wasn't found. The work around for this was to unset the $DISPLAY environment variable (yes, totally obvious). I read somewhere that OpenSSH will try to use ssh-askpass if DISPLAY is set. So I did this
unset DISPLAY
Then I basically got the error message in the OP. So, continuing on, I did everything on this page to create and copy the public key from A to B.
http://knol.google.com/k/how-to-use-ssh-keygen#
I created both an RSA key and DSA key. I guess RSA is older and DSA is newer. (It looks like it was using the RSA key.) Anyways, this didn't solve the problem alone.
Then I tried copying server "B" public key back to client "A"'s known_hosts. And that worked!
From server B, grab
/etc/ssh/ssh_host_rsa_key.pub
Then add the contents of that to
~/.ssh/known_hosts
on client "A", with the IP address of server "B" prepended to the beginning (and one space)
192.168.0.200 ssh-rsa QbJfEdeu4rsgeAAAAAB3Nza.... etc ... ==
A useful debugging tip is to use the -vvv option to ssh to get super verbose output.
For future reference I fixed what I think was the same issue by doing (from the client)
$ ssh-keyscan [HOST-SERVER-IP]
# [HOST-SERVER-IP] SSH-2.0-OpenSSH_6.7
[HOST-SERVER-IP] ssh-rsa AAAAB3NzaC1yc2EAAAADA ... etc ... +Zl
# [HOST-SERVER-IP] SSH-2.0-OpenSSH_6.7
[HOST-SERVER-IP] ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTI ... etc ... +1w=
I then removed everything in ~/.ssh/known_hosts and copy pasted the two keys exactly the way they appeared into ~/.ssh/known_hosts.
I actually copy pasted the ssh-rsa one only at first, because I thought that's what I was using. For some reason that didn't work, when I copy pasted the second key in it worked like a charm. Of note as well that I enabled PasswordAuthentication in my sshd config on the server so as to not worry about keys.