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 generate a ssh key pair on my mac and add the public key to my ubuntu server(in fact, it is a virtual machine on my mac),but when I try to login the ubuntu server,it says:
###########################################################
# WARNING: UNPROTECTED PRIVATE KEY FILE! #
###########################################################
Permissions 0644 for '/Users/tudouya/.ssh/vm/vm_id_rsa.pub' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /Users/tudouya/.ssh/vm/vm_id_rsa.pub
Permission denied (publickey,password).
I have tried many ways to solve this, change the key file mode, change the folder mode,as some answer on stackoverflow,but it doesn't work.
the key file permission:
vm dir:
drwxr-xr-x 4 tudouya staff 136 4 29 10:37 vm
key file:
-rw------- 1 tudouya staff 1679 4 29 10:30 vm_id_rsa
-rw-r--r-- 1 tudouya staff 391 4 29 10:30 vm_id_rsa.pub
please give me some idea...
=========================================
I write the host infomation to ssh_config:
Host ubuntuvm
Hostname 10.211.55.17
PreferredAuthentications publickey
IdentityFile /Users/tudouya/.ssh/vm/vm_id_rsa.pub
I run command "ssh -v ubuntuvm",it displays:
ssh -v ubuntuvm
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 103: Applying options for *
debug1: /etc/ssh_config line 175: Applying options for ubuntuvm
debug1: Connecting to 10.211.55.17 [10.211.55.17] port 22.
debug1: Connection established.
debug1: identity file /Users/tudouya/.ssh/vm/vm_id_rsa.pub type 1
debug1: identity file /Users/tudouya/.ssh/vm/vm_id_rsa.pub-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-8
debug1: match: OpenSSH_6.6.1p1 Ubuntu-8 pat OpenSSH*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5-etm#openssh.com none
debug1: kex: client->server aes128-ctr hmac-md5-etm#openssh.com 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: Server host key: RSA 55:6d:4f:0f:23:51:ac:8e:70:01:ec:0e:62:9e:1c:10
debug1: Host '10.211.55.17' is known and matches the RSA host key.
debug1: Found key in /Users/tudouya/.ssh/known_hosts:54
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,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/tudouya/.ssh/vm/vm_id_rsa.pub
debug1: Server accepts key: pkalg ssh-rsa blen 279
###########################################################
# WARNING: UNPROTECTED PRIVATE KEY FILE! #
###########################################################
Permissions 0644 for '/Users/tudouya/.ssh/vm/vm_id_rsa.pub' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /Users/tudouya/.ssh/vm/vm_id_rsa.pub
debug1: No more authentication methods to try.
Permission denied (publickey,password).
I suggest you to do:
chmod 400 ~/.ssh/id_rsa
It works fine for me.
debug1: identity file /Users/tudouya/.ssh/vm/vm_id_rsa.pub type 1
It appears that you're trying to use the wrong key file. The file with the ".pub" extension contains the public portion of the key. The corresponding file without the ".pub" extension contains the private part of the key. When you run an ssh client to connect to a remote server, you have to provide the private key file to the ssh client.
You probably have a line in the your .ssh/config file (or /etc/ssh_config) which looks like this:
IdentityFile .../.ssh/vm/vm_id_rsa.pub
You need to remove the ".pub" extension from the filename:
IdentityFile .../.ssh/vm/vm_id_rsa
Key should be readable by the logged in user.
Try this:
chmod 400 ~/.ssh/Key file
chmod 400 ~/.ssh/vm_id_rsa.pub
chmod 400 path/to/filename
This work for me. When I did this file I am able to connect to my EC2 instance
change your KEY permission to
chmod 400 your_key.pem
It should work !
After running below command it works for me
sudo chmod 600 /path/to/my/key.pem
In my case, it was a .pem file. Turns out holds good for that too. Changed permissions of the file and it worked.
chmod 400 ~/.ssh/dev-shared.pem
Thanks for all of those who helped above.
SSH keys are meant to be private so a 644 permission is too open.
Binary references to set Permissions
r(read) = 4
w(write) = 2
x(execute) = 1
So by adding these numbers and by passing the summed digit to chmod command,We set the permission of file/directory.
The first digit sets permission for the owner, second digit for group and the third one for all other users on the system who have no right to the file.
A permission of 644 means
(4+2) = read/write permission for the owner
(4) = read permission for the group
(4) = read permission for all other users
By changing the the permission of the file to 400 using
chmod 400 <filename>
solves the issue. As it makes the key read-only accessible to the owner.
Ref: https://www.linux.com/training-tutorials/understanding-linux-file-permissions/
Lot's of similar answers but no explanations...
The error is thrown because the private key file permissions are too open. It is a security risk.
Change the permissions on the private key file to be minimal (read only by owner)
Change owner chown <unix-name> <private-key-file>
Set minimal permissions (read only to file owner) chmod 400 <private-key-file>
If the keys are in the ~/.ssh directory , use
chmod 400 ~/.ssh/id_rsa
If the keys are in different directory, use
chmod 400 directory_path/id_rsa
This worked for me.
chmod 600 id_rsa
Run above command from path where key is stored in vm ex: cd /home/opc/.ssh
I have similar issue and solved it by changing the permission of the respective files and folder worked for me.
This is the solution which is worked for me:
$ chmod 0600 ~/.ssh/id_rsa.pub
$ chmod 0600 ~/.ssh/authorized_keys
$ chmod 0600 ~/.ssh/id_rsa
$ chmod 0700 ~/.ssh
You have to run the command bellow
chmod 400 /path/to/my/key.pem
As for me, the default mode of id_rsa is 600, which means readable and writable.
After I push this file to a git repo and pull it from another pc, sometimes the mode of the private key file becomes -rw-r--r--.
When I pull the repo with ssh after specify the private key file, it failed and prompted warnings the same with you. Following is my script.
ssh-agent bash -c "ssh-add $PATH_OF_RSA/id_rsa; \
git pull git#gitee.com:someone/somerepo.git "
I fix this problem just by changing the mode to 600.
chmod 600 $PATH_TO_RSA/id_rsa
giving permision 400 makes the key private and not accessible by someone unknown. It makes the key as a protected one.
chmod 400 /Users/tudouya/.ssh/vm/vm_id_rsa.pub
Just run below to your pem's
sudo chmod 600 /path/to/my/key.pem
If youre using a .ssh/config file try to
chmod 0400 .ssh/config
then:
chmod 0400 .ssh/<<KEYFILE_PATH>>
This should do the trick:
chmod 600 id_rsa
chmod 400 /etc/ssh/* works for me.
Those who suggested chmod 400 id_rsa.pub did not sound right at all. It was quite possible that op used pub key instead of private key to ssh.
So it might be as simple as ssh -i /Users/tudouya/.ssh/vm/vm_id_rsa (the private key) user#host to fix it.
--- update ---
Check this article https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2 for how to set up ssh key
I had this issue with a macbook m1, I later realized that i was missing sudo from the connection script
sudo ssh -i "key.pem" ubuntu#IP_Address
Ensure you are not missing the sudo in your connection script if you are using a macbook.
This problem had a quick and easy fix. You just had to change the permissions on the pem file using the following command.
chmod 400 /Users/yourUserName/pathOfYourFile/fileName.pem
This command will make the file read only and remove all other permissions on the file
There has been a lot of great explanation above, so I recommend reading and understanding.
Here is my simple step by step solution:
On your terminal, run:
open ~/.ssh/config
In your file, you will see something similar to this (in my personal case):
Host *
IgnoreUnknown UseKeychain
AddKeysToAgent yes
IdentityFile ~/.ssh/id_ed25519.pub
or like this (as per the example in this question).
Hostname 10.211.55.17
PreferredAuthentications publickey
IdentityFile /Users/tudouya/.ssh/vm/vm_id_rsa.pub
Remove the ".pub" extention from the last line, which should look like:
Hostname 10.211.55.17
PreferredAuthentications publickey
IdentityFile /Users/tudouya/.ssh/vm/vm_id_rsa
or in my case:
Host *
IgnoreUnknown UseKeychain
AddKeysToAgent yes
IdentityFile ~/.ssh/id_ed25519
Save the file and test your ssh connection.
i had similar issues and this was what i did and it worked.
sudo ssh -i webhost.pem ubuntu#ipaddress
I removed the .pub file, and it worked.
Why find .ssh/iddsa file. there is no such a file. just id_rsa.
So the issue is that I can login to my server just fine using:
ssh root#SERVER_IP_ADRESS
But when I try to login with a user I created from root:
ssh USERNAME#SERVER_IP_ADRESS5
I get:
Permission denied (publickey).
The steps I went through before this.
SSH generated a key
Created an Ubuntu 16.04 droplet with given SSH key.
SSH into server with root
$ adduser username
usermod -aG sudo username
`$ ssh -vvv root#serverip
OpenSSH7.6p1, LibreSSL 2.6.2
debug1: Reading configuration data /etc/ssh/sshconfig
debug1: /etc/ssh/sshconfig line 48: Applying options for *
debug2: sshconnectdirect: needpriv 0
debug1: Connecting to cleanproject port 22.
debug1: Connection established.
debug1: identity file /Users/happy/.ssh/idrsa type 0
....
...
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/happy/.ssh/id_dsa
debug3: no such identity: /Users/happy/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /Users/happy/.ssh/id_ecdsa
debug3: no such identity: /Users/happy/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /Users/happy/.ssh/id_ed25519
debug3: no such identity: /Users/happy/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
root#server: Permission denied (publickey).`
Below steps should help to create and authenticate the new user on the instance.
Ssh into your instance using public key.
Create a new user: $ sudo adduser test123
Change the shell session: $ sudo su test123
Create .ssh folder: $mkdir .ssh
Change the permission: $ chmod 700 .ssh
Confirm $pwd is /home/test123
In .ssh folder, execute these
$ touch authorized_keys
$ chmod 600 authorized_keys
paste your public key here from your local system, id_rsa.pub is the default name if not edited while saving. make sure no extra spaces are copied.
It should work!.
$ssh test123#ip-address
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).
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.