I'm trying to set up Capistrano for a webapp I'm working on, and I'm having trouble getting agent forwarding to work.
Here's my ~/.ssh/config:
Host rs
Hostname <ip of my server>
ForwardAgent yes
User root
And I don't think default settings are overriding anything, since ForwardAgent is never mentioned there (except in a commented line).
Here's what happens when I SSH normally:
$ ssh -v deploy#<server>
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /Users/ulyssecarion/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 102: Applying options for *
-- snip --
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions#openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Welcome to Ubuntu 12.04.3 LTS (GNU/Linux 3.8.0-29-generic x86_64)
If I force SSH to allow agent-forwarding with the -A flag, then I can get it work:
$ ssh -Av deploy#<server>
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /Users/ulyssecarion/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 102: Applying options for *
-- snip --
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions#openssh.com
debug1: Entering interactive session.
debug1: Requesting authentication agent forwarding. # Note this additional line here
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Welcome to Ubuntu 12.04.3 LTS (GNU/Linux 3.8.0-29-generic x86_64)
(Notice that the logs on the second example have an additional line indicating agent forwarding is being requested.)
Is this normal, or am I doing something wrong? Thanks in advance!
This block
Host rs
HostName <ip of my server>
ForwardAgent
User root
only applies if your call to ssh looks like
ssh rs
in which case ssh knows that should be used in place of "rs". In your call
ssh -v deploy#<server>
whatever you are using as <server> does not match "rs" (since only the literal string "rs" is going to match), so the block does not apply.
The argument to the Host option must be a pattern which will match the host name you actually use on the command line.
There is some great information over on ServerFault about setting up ssh agent forwarding.
https://superuser.com/questions/168933/extra-configuration-required-for-ssh-agent-forwarding
One thing I want to point out, the ssh config file on the server might have ForwardAgent commented out, but at least on my config file, it's really listing the ssh defaults. It seems for some versions of openssh you have to set the AllowAgentForwarding option on the server. I've found this article really useful https://help.github.com/articles/using-ssh-agent-forwarding
The way to check if ssh agent forwarding is working is by looking at the $SSH_AUTH_SOCK environment variable.
echo "$SSH_AUTH_SOCK"
Related
So ssh works fine through console/terminal, but when I am using a MySQL database client (Sequel Pro), it seems to somehow be using a different ssh version, and the include directive therefore doesn't work. It states that it is using the proper SSH version, but does it switch at some point during the protocol?
OpenSSH_7.5p1, OpenSSL 1.0.2l 25 May 2017
debug1: Reading configuration data /Users/me/.ssh/config
debug1: Reading configuration data /Users/me/.ssh/devops
debug1: Reading configuration data /Users/me/.ssh/defaults
debug1: /Users/me/.ssh/defaults line 4: Applying options for *
debug1: /Users/me/.ssh/defaults line 76: Applying options for ch-pre-bastion
debug1: /Users/me/.ssh/defaults line 80: Applying options for ch-pre-*
debug1: Reading configuration data /usr/local/etc/ssh/ssh_config
debug1: Control socket " none" does not exist
debug1: Executing proxy command: exec ssh gateway#52.33.83.63 -W 52.33.83.63:22
debug1: permanently_drop_suid: 502
debug1: identity file /Users/me/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.5
/Users/me/.ssh/config: line 1: Bad configuration option: include
/Users/me/.ssh/config: line 2: Bad configuration option: include
/Users/me/.ssh/config: terminating, 2 bad configuration options
ssh_exchange_identification: Connection closed by remote host
You have probably more SSH versions installed on your machine and the one from proxy command is probably picking up the old one, without Include support.
debug1: Executing proxy command: exec ssh gateway#52.33.83.63 -W 52.33.83.63:22
Try to find a complete path to ssh binary and use it in the ~/.ssh/config of ProxyCommand or just use ProxyJump option, which should choose correct ssh instance`.
I have two machines, m_remote and m_server. I can successfully set up an ssh tunnel from m_remote to m_server using:
ssh -f -N -T -R22222:localhost:22 m_remote_user_on_server#123.123.123.123 -i /path/to/.ssh/m_remote_key
Where 123.123.123.123 is the m_server IP address. And I can successfully use that tunnel from m_server to m_remote using:
ssh m_server_user_on_remote#localhost -p 22222 -i /path/to/.ssh/m_server_key
However after a period of time the tunnel becomes unresponsive and it's no longer possible to use it. I have to access the remote machine directly and restart the tunnel. Is there any way of debugging this? From the remote all I get is:
$ ssh -vvvv m_server_user_on_remote#localhost -p 22222 -i /home/server_user/.ssh/m_server_key
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /home/server_user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "localhost" port 22222
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 22222.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /home/server_user/.ssh/m_server_key type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/server_user/.ssh/m_server_key-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
Then after a long pause of at least 2 minutes it logs out:
ssh_exchange_identification: Connection closed by remote host
Though this is due to a cron job I've set up to periodically kill and restart the tunnel.
** Edit **
On OSX 10.11 it's the same debug log with an additional line:
...
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9
debug1: permanently_drop_suid: 501 # <-- additional line before hanging
I'm not certain as I need to diagnose and correlate this but as the m_remote machine is on a flaky home wifi connection this may be dropping and causing the tunnel to hang.
Alternatively there may be some config option such as ControlPersist (which may only be relevant to master connections) which has a low default of perhaps 10 minutes which could be increased.
I was trying to configure my SSH configs for easier workflows, but I've run against a wall here.
I have a jump host which requires sudo ssh to get to all the other machines.
I've figured out that if I run ssh -tt jumphost sudo ssh desthost that I get asked for my sudo password and I get access to desthost
Now, when I add ProxyCommand ssh -tt jumphost sudo ssh %h to my ssh_config and run ssh desthost then I just get a blank connection.
Debug printout:
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /Users/deiga/.ssh/config
debug1: /Users/deiga/.ssh/config line 34: Applying options for desthost
debug1: /Users/deiga/.ssh/config line 167: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: auto-mux: Trying existing master
debug1: Control socket "/tmp/ssh-deiga#desthost:22" does not exist
debug2: ssh_connect: needpriv 0
debug1: Executing proxy command: exec ssh -tt jumphost sudo ssh desthost
debug1: identity file /Users/deiga/.ssh/id_rsa type -1
debug1: identity file /Users/deiga/.ssh/id_rsa-cert type -1
debug1: identity file /Users/deiga/.ssh/id_dsa type -1
debug1: identity file /Users/deiga/.ssh/id_dsa-cert type -1
debug1: permanently_drop_suid: 501
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: ssh_exchange_identification: [sudo] password for deiga:
debug1: ssh_exchange_identification: Sorry, try again.
debug1: ssh_exchange_identification: [sudo] password for deiga:
debug1: ssh_exchange_identification: sudo: 1 incorrect password attempt
This is not how the proxy command work. Basic example how you should do jumphosts is this way:
ProxyCommand ssh -W %h:%p jumphost
which doesn't support running sudo on remote machine. But you can do the same with netcat command:
ProxyCommand ssh jumphost nc %h %p
And to make it working with your sudo requirement, just add the sudo command:
ProxyCommand ssh jumphost sudo nc %h %p
If it will not help, please try to diagnose the problem with verbose logs from ssh (-vvv).
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.
Again I have a question about an ssh issue:
On a embedded system (no display, no keyboard) my only login interface was ssh. Telnet is disabled too. (I am currently trying to enable it with only little hope...)
My only interaction at the moment is receiving a ping answer and browsing my shared files via smb://!
ssh's answer is always:
$ ssh -vvvvl root 192.168.0.3
OpenSSH_5.5p1 Debian-4ubuntu4, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.0.3 [192.168.0.3] port 22.
debug1: Connection established.
debug1: identity file /home/simon/.ssh/id_rsa type -1
debug1: identity file /home/simon/.ssh/id_rsa-cert type -1
debug1: identity file /home/simon/.ssh/id_dsa type -1
debug1: identity file /home/simon/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3p2 Debian-8
debug1: match: OpenSSH_4.3p2 Debian-8 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-4ubuntu4
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer
But I direct access to the hdd through pulling it out of the device and manipulating files on it while it is connected to another machine.
One of my last steps before I logged off and get locked out was sudo rm /etc/ssh/*host*key* followed by dpkg-reconfigure openssh-server, what failed because dpkg-reconfigure was not found. So I guess the problem is, that the keys are deleted.
My question is now: how can I off-shore create keys and provide them to sshd without running any command on the target system OR how can I make sshd let me log in without having a key?
Thanks for your help if there is any..?!
You can generate a new set of host keys on a handy Linux system as follows:
ssh-keygen -t rsa -b 2048 -f ssh_host_rsa_key
ssh-keygen -t dsa -b 1024 -f ssh_host_dsa_key
When ssh-keygen asks you for a passphrase, hit Enter without typing anything. Host keys must have an empty passphrase.
This creates the following files in your current directory:
ssh_host_rsa_key
ssh_host_rsa_key.pub
ssh_host_dsa_key
ssh_host_dsa_key.pub
You can then mount your device's hard drive and copy these four files into etc/ssh.
Note that when you try to ssh to the system afterwards, your ssh client will complain that the keys are different than expected, and probably refuse to connect. If you're running the OpenSSH client, you can correct this by using ssh-keygen again:
ssh-keygen -R <your_server_hostname>
ssh -vvvvl root 192.168.0.3
should be:
ssh -vvvvl root#192.168.0.3
I don't know if that is just a typo you made while posting on stackoverflow or if you typed it in on the command line.