I recently upgraded to DDWRT on my router, After doing so, I can't login to my Synology DS213's web interface (says cannot login as this account, root admin and my other admin account dont work) Also, the ssh keys I had setup that worked fine, no longer work. I get
ssh -vvv root#192.168.1.115
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
debug1: Reading configuration data /c/Users/chs/.ssh/config
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.115 [192.168.1.115] port 22.
debug1: Connection established.
debug1: identity file /c/Users/chs/.ssh/identity type -1
debug1: identity file /c/Users/chs/.ssh/id_rsa type -1
debug1: identity file /c/Users/chs/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host
And I cannot getinto the web interface to enable Telnet to even get in to check my config files. Any ideas?
Solved, my Synology NAS local IP changed from .115 to .135, also I needed to enable DDNS on DDWRT. After doing so I was again able to SSH into my NAS with pubkey authentication as was already setup.
Related
I have successfully been connecting to Bitbucket cloud via my SSH key set up on my laptop for the past three years with no issue, but suddenly today I started seeing this error when trying to pull from remote branch:
kex_exchange_identification: write: Broken pipe
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
I followed the instructions here: https://support.atlassian.com/bitbucket-cloud/docs/set-up-an-ssh-key/ for Mac OS (I am using Big Sur). So I deleted the old ssh key, both from my machine and from my Bitbucket account, and replaced it with a newly generated one.
My .ssh config file contains this as recommended:
Host *
UseKeychain yes
So I have added the new key id_rsa to ssh agent:
ssh-add -K ~/.ssh/id_rsa
and added id_rsa.pub to my Bitbucket account as described in the instructions.
Still when I run ssh -T git#bitbucket.org I see: "kex_exchange_identification: write: Broken pipe"
Here is the output with the -v flag enabled:
daniel#North ~ % ssh -T -v git#bitbucket.org
OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/daniel/.ssh/config
debug1: /Users/daniel/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug1: Connecting to bitbucket.org port 22.
debug1: Connection established.
debug1: identity file /Users/daniel/.ssh/id_rsa type 0
debug1: identity file /Users/daniel/.ssh/id_rsa-cert type -1
debug1: identity file /Users/daniel/.ssh/id_dsa type -1
debug1: identity file /Users/daniel/.ssh/id_dsa-cert type -1
debug1: identity file /Users/daniel/.ssh/id_ecdsa type -1
debug1: identity file /Users/daniel/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/daniel/.ssh/id_ed25519 type -1
debug1: identity file /Users/daniel/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/daniel/.ssh/id_xmss type -1
debug1: identity file /Users/daniel/.ssh/id_xmss-cert type -1
kex_exchange_identification: write: Broken pipe
The strange thing is, when I try the exact same steps on a different Macbook, also running Big Sur, it actually works and I see 'authenticated via ssh key' when running the above command.
Anyone have any idea what might be causing the failure to connect?
my colleague has the same problem, strange thing is that it works when putting the mac in safe mode.
I am trying to clone from a Gitlab server from my Macbook. When I clone, I get the following error:
manzanita-226-109:icarus homeuser$ git clone elm:dummy/dummy.git
Cloning into 'dummy'...
ssh_exchange_identification: read: Connection reset by peer
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
When I try to ssh into the gitlab server, I get the following:
OpenSSH_7.6p1, LibreSSL 2.6.2
debug1: Reading configuration data /Users/homeuser/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Connecting to elm.ndc.nasa.gov port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /Users/homeuser/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/homeuser/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/homeuser/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/homeuser/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/homeuser/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/homeuser/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/homeuser/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/homeuser/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6
ssh_exchange_identification: read: Connection reset by peer
I can get on the gitlab server using Google Chrome with no issues. I also tried cloning and ssh'ing from a different server with no issues. I do not have admin privileges on this gitlab server, but I do not believe there are any banning/blacklisting softwares on there.
Can anyone advise?
ssh_exchange_identification: read: Connection reset by peer
This basically means the TCP connection was "reset" immediately after being accepted by the server. Common reasons for this are:
The remote SSH server software is malfunctioning (e.g. it crashed).
The remote SSH server software is configured to drop your connections for some reason.
Some router or other networking device between you and the server is interfering with the TCP connection.
There's no way to tell exactly what is wrong from the client debugging messages. You need to troubleshoot this on the server. The remote SSH server program might have a log file you can look at, for example.
On my server (Dockerized GitLab) the problem was that I had given the wrong permissions to sshd's keys in /etc/gitlab which could be seen by inspecting the logs in /var/log/gitlab/sshd.
I solved the problem by changing the permissions on the server with this command:
chmod -R 700 /etc/gitlab
I had a similar issue and I found out that the /var/empty folder had the wrong owner. I ran " sudo chown root /var/empty " and it resolved the issue.
I just changed url from ssh to http and it fixed everything...
git remote set-url origin https://username#gitclient.com/reposetory_address
I had this same error. Maybe it is generic, but my issue was that the server had some uncommitted changes that needed to be added and committed before I could push changes from my computer. Hope this saves someone some time, since it wasted a few hours. Thanks!
Add my scenario. In my case, github server is private, previously the github repo server ip is fixed, and I add it in /etc/hosts file. The server ip was updated after maintainance but the hosts file is not updated. I removed the fixed item in /etc/hosts file and the error is gone.
Just for reference in case anyone hit the same issue.
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.
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.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm trying to set-up SSH connections without password to many servers, using RSA key. It works well for most of them but one is giving me some trouble.
The most common issue I've found in the past is permissions problems on .ssh or authorized_keys on the remote host, but here they seem correct, like this:
drwx------ ~/.ssh
-rw-r--r-- ~/.ssh/authorized_keys
Here is output of ssh -v command to this server (I just changed hostname and IP):
Sun_SSH_1.1.3, SSH protocols 1.5/2.0, OpenSSL 0x0090704f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to myhost.mydomain.com [123.123.123.123] port 22.
debug1: Connection established.
debug1: identity file /export/home/webdev1/.ssh/identity type -1
debug1: identity file /export/home/webdev1/.ssh/id_rsa type 1
debug1: identity file /export/home/webdev1/.ssh/id_dsa type -1
debug1: Remote protocol version 1.5, remote software version 1.2.31
debug1: match: 1.2.31 pat 1.2.1*,1.2.2*,1.2.3*
debug1: Local version string SSH-1.5-Sun_SSH_1.1.3
debug1: Waiting for server public key.
debug1: Received server public key (768 bits) and host key (1024 bits).
debug1: Host 'myhost.mydomain.com' is known and matches the RSA1 host key.
debug1: Found key in /export/home/webdev1/.ssh/known_hosts:6
debug1: Encryption type: 3des
debug1: Sent encrypted session key.
debug1: cipher_init: set keylen (16 -> 32)
debug1: cipher_init: set keylen (16 -> 32)
debug1: Installing crc compensation attack detector.
debug1: Received encrypted confirmation.
debug1: Doing password authentication.
I suspect it could be due to the SSH version. Another server which works gives me the following output (remote protocol version 2.0 instead of 1.5):
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1.3
debug1: match: Sun_SSH_1.1.3 pat Sun_SSH_1.1.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.1.3
Any clue?
Thanks for your help.
chmod 744 ~/.ssh/authorized_keys
works for me.
Make sure your home directory(/export/home/webdev1) too has 700 permission.
The server may be configured to refuse public-key-based, password-less authentication. I do not know about Sun_SSH, but in OpenSSH (the most prevalent SSH implementation on Linux/*BSD systems) this is a matter of changing some settings in /etc/ssh/sshd_config (options RSAAuthentication for v1 protocol, PubkeyAuthentication for v2).
try just
chmod -R 600 ~/.ssh/
Maybe the group/global read permission is causing an issue.
Maybe your user was locked on the unix box. If you usually login with your own account and then "be" the functional user, if that user has "password login" functionalities enabled but you are not using it, it may be locked (password expired for example).
Howerver, even if it is locket it will not prevent you from sudo it with the "be" command, but it will definitly prevent any ssh login even if the keys are trusted.