I'm seeing the following error messages when trying to sftp from a windows client to my redhat server:
Client:
C:\Users\Administrator\.ssh>sftp -P 7822 -v user#x.x.x.x
.
.
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:FczboY8BDSWtdA87euFDWSDrwBNRMbYzHUR3VmMpbk
C:\\Users\\Administrator/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Trying private key: C:\\Users\\Administrator/.ssh/id_dsa
debug1: Trying private key: C:\\Users\\Administrator/.ssh/id_ecdsa
debug1: Trying private key: C:\\Users\\Administrator/.ssh/id_ed25519
debug1: Trying private key: C:\\Users\\Administrator/.ssh/id_xmss
debug1: No more authentication methods to try.
user#x.x.x.x Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
Server:
Aug 4 23:27:09 3oy1jxwr1k81l.xxx.io sshd[16064]: Connection reset by x.x.x.x port 65256 [preauth]
Aug 4 23:27:14 3oy1jxwr1k81l.xxx.io sshd[16117]: Did not receive identification string from x.x.x.x port 12593
Aug 4 23:27:24 3oy1jxwr1k81l.xxx.io sshd[16259]: Did not receive identification string from x.x.x.x port 48329
Aug 4 23:27:34 3oy1jxwr1k81l.xxx.io sshd[16394]: Did not receive identification string from x.x.x.x port 2040
I'm positive that all ports open in firewall, and authorized_keys are setup up correctly.
So i stop the sshd service, and run from cmd line with -ddd hoping to get more information.
However when running in debug mode, the connection succeeds !?!?
/user/sbin/sshd -D -ddd
Client:
C:\Users\Administrator\.ssh>sftp -P 7822 user#x.x.x.x
Connected to user#x.x.x.x.
sftp> exit
Any ideas what could be happening? (Note this is 100% reproducible, fails every time when sshd is run normally, and succeeds always when run with -ddd)
So looks like the problem was due to a missing .bash_profile in the user home dir on the server.
After adding the user profile back, it seems to resolve the issue.
Why sshd didn't care it was missing when run in debug mode seems like a bug in sshd.
I was also getting the Connection reset by [ip] port x [preauth] message.
For me, however, it was a firewall issue on the client side. The IT department had blocked SSH outside the network. After updating the firewall, the connection worked.
Related
I face following issues when trying to connect from my PS using either PowerShell or Cygwin to AWS on which my Wordpress site is hosted (Bitnami).
(I simply what to log in to the server either this way or using Putty as described here (LINK Putty is throwing an error "using username bitnami. Server refused our key. No supported authentication methods available. server sent publickey")
What I tried so far:
I execute either or both of the following commands...
chmod 600 <key-pair-from-aws>.pem
chmod 400 <key-pair-from-aws>.pem
(When I logged in to ec2 instance, under Key Pairs section I saw an entry, but I could not download it. That's why I generated a new key pair and that is the file I am using in the commands below.)
Then I enter the following command...
ssh bitnami#<public-ip-address> -i <key-pair-from-aws>.pem
... I get the following error:
Permissions for '(key-pair-from-aws).pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key ".pem": bad permissions
bitnami#(public-ip-address): Permission denied (publickey).
Now, if I select the file on the PC "Properties -> Security -> Advanced -> disable inheritance", and then remove every user except my user, and then execute the same command ...
ssh bitnami#<public-ip-address> -i <key-pair-from-aws>.pem
... I get the following error:
bitnami#<public-ip-address>: Permission denied (publickey).
here I am stuck because I do not have any idea how to proceed further.
Searching on Stackoverflow and google I could not find anything to help me solve this issue.
can anyone please help with concrete, step-by-step instructions?
Thank you!
Update: here is the result of the command
$ ssh -v -i "pem-file-name.pem" bitnami#
> OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
debug1: Connecting to <public-ip-address> [<public-ip-address>] port 22.
debug1: Connection established.
debug1: identity file kljuc_par_ime.pem type -1
debug1: identity file kljuc_par_ime.pem-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_8.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.4p1 Debian-
5+deb11u1
debug1: match: OpenSSH_8.4p1 Debian-5+deb11u1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to <public-ip-address>:22 as 'bitnami'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305#openssh.com MAC: <implicit>
compression: none
debug1: kex: client->server cipher: chacha20-poly1305#openssh.com MAC: <implicit>
compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: <deleted for sec purposes> SHA256:<deleted for security purposes>
debug1: Host '<public-ip-address>' is known and matches the ECDSA host key.
debug1: Found key in C:\\Users\\My-User/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory
debug1: Will attempt key: kljuc_par_ime.pem explicit
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519#openssh.co
m,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp38
4,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256#openssh.com,webauthn-sk-ecdsa-sha2-ni
stp256#openssh.com>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: kljuc_par_ime.pem
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
bitnami#<public-ip-address>: Permission denied (publickey)
To use a keypair with an Amazon EC2 instance, you should specify the keypair when launching the instance. It is not possible to SSH into an instance using a keypair generated after the instance is launched.
Also, Bitnami AMIs generate a random password for Wordpress, which can be extracted from the System Log after the instance boots.
See: Bitnami: Find application credentials
I recently switched the ssh listen port on my server running Dropbear from 22 to a random one to prevent the system log from being flooded by someone brute-forcing.
Everything is fine and I am able to connect to the server from the wan side using termux(an
Android terminal emulator that you can install packages).
Until when I try using my MacBook to ssh into the server(under the same network with my phone, was previously able to ssh into the server when dropbear was listening on 22). The connection immediately drops and ssh throws this at me:
kex_exchange_identification: write: Broken pipe
The verbose output does not really show anything helpful(and cut really abruptly may I add):
OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/my_username/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug1: Connecting to remote.yhaoquan.top port 2123.
debug1: Connection established.
debug1: identity file /Users/my_username/.ssh/id_rsa type 0
debug1: identity file /Users/my_username/.ssh/id_rsa-cert type -1
debug1: identity file /Users/my_username/.ssh/id_dsa type -1
debug1: identity file /Users/my_username/.ssh/id_dsa-cert type -1
debug1: identity file /Users/my_username/.ssh/id_ecdsa type -1
debug1: identity file /Users/my_username/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/my_username/.ssh/id_ed25519 type -1
debug1: identity file /Users/my_username/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/my_username/.ssh/id_xmss type -1
debug1: identity file /Users/my_username/.ssh/id_xmss-cert type -1
kex_exchange_identification: write: Broken pipe
Telnetting to port 2123 shows that I actually successfully made the connection to the server:
>telnet {hostname} 2123
Trying {host IP address}...
Connected to {hostname}
Escape character is '^]'.
SSH-2.0-dropbear
|
��]J044��d����curve25519-sha256,curve25519-sha256#libssh.org,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,kexguess2#matt.ucc.asn.aursa-sha2-256,ssh-rsa3chacha20-poly1305#openssh.com,aes128-ctr,aes256-ctr3chacha20-poly1305#openssh.com,aes128-ctr,aes256-ctrhmac-sha1,hmac-sha2-256hmac-sha1,hmac-sha2-256nonenoneM�'�Rf
When I change the port back to 22 on my server, everything works again.
Does anyone know where the problem might be or what way should I go about diagnosing the problem?
Thanks in advance :)
EDIT 1:
For those of you who are experiencing the same issue, a temporary solution would be using OpenSSH. The easiest way (that makes this a drop-in solution) to do this is by using Homebrew:
brew install openssh
This command will change the ssh client you use from /usr/bin/ssh to an alias placed at /usr/local/bin/ssh points to the OpenSSH you just installed using brew, which the symptom doesn't seem to appear on.
This does not solve the problem that this post is about. I am still looking for a solution for it.
I had the same issue: ssh returns "kex_exchange_identification: write: Broken pipe" without network activity.
In my case the guilty party was AdGuard.
I added the port I use for ssh in the advanced configuration, network.extension.exclude.ports and it works now.
network.extension.exclude.domains may be a better choice for you depending on your configuration.
This solved my issue with /usr/bin/ssh.
Background:
ssh to a named host would fail with kex_exchange_identification: write: Broken pipe.
ssh to an IP address would work.
Installing a new version of SSH (using Homebrew) worked (from the terminal, using /usr/local/bin/ssh).
Mac Mail was still broken (it uses SSH to connect to my IMAP accounts).
I found this post where someone (yesterday) was experiencing the exact same symptoms as me from a piece of Broadcom antivirus software (WSS Agent) which I do not use:
https://community.broadcom.com/symantecenterprise/communities/community-home/digestviewer/viewthread?GroupId=2593&MessageKey=57c16f08-06e4-4c1d-adc7-bd3f51cc4516&CommunityKey=84278e0f-9c57-4f93-8cff-4530b03e3c07&tab=digestviewer&ReturnUrl=%2Fbrowse%2Fallrecentposts
That reminded me that Sophos (Antivirus) had recently (maybe yesterday, maybe the day before) installed a "SophosWebNetworkExtentsion". They posted this video (of how to accept the install) on 2021 Jan 19th (two days ago):
https://www.youtube.com/watch?v=z-qWdv1ynMs
The Fix:
I logged into Sophos, and under "Web Protection" disabled Web Protection.
I needed to reboot for the change to affect SSH. After rebooting, usr/bin/ssh started working again and Mac Mail started working again.
Before the fix:
$ /usr/bin/ssh s0-backend -v
OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/eric/.ssh/config
debug1: /Users/eric/.ssh/config line 62: Applying options for s0-backend
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug1: Connecting to s0-backend port 61917.
debug1: Connection established.
debug1: identity file /Users/eric/.ssh/id_rsa type 0
debug1: identity file /Users/eric/.ssh/id_rsa-cert type -1
debug1: identity file /Users/eric/.ssh/id_dsa type -1
debug1: identity file /Users/eric/.ssh/id_dsa-cert type -1
debug1: identity file /Users/eric/.ssh/id_ecdsa type -1
debug1: identity file /Users/eric/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/eric/.ssh/id_ed25519 type -1
debug1: identity file /Users/eric/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/eric/.ssh/id_xmss type -1
debug1: identity file /Users/eric/.ssh/id_xmss-cert type -1
kex_exchange_identification: write: Broken pipe
$
After the fix (successful SSH login):
usr/bin/ssh s0-backend -v
OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/eric/.ssh/config
debug1: /Users/eric/.ssh/config line 62: Applying options for s0-backend
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug1: Connecting to s0-backend port {redacted}.
debug1: Connection established.
debug1: identity file /Users/eric/.ssh/id_rsa type 0
debug1: identity file /Users/eric/.ssh/id_rsa-cert type -1
debug1: identity file /Users/eric/.ssh/id_dsa type -1
debug1: identity file /Users/eric/.ssh/id_dsa-cert type -1
debug1: identity file /Users/eric/.ssh/id_ecdsa type -1
debug1: identity file /Users/eric/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/eric/.ssh/id_ed25519 type -1
debug1: identity file /Users/eric/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/eric/.ssh/id_xmss type -1
debug1: identity file /Users/eric/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2p1 Ubuntu-4ubuntu0.1
debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to s0-backend:61917 as '{redacted}'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305#openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305#openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-ed25519 SHA256: {redacted}
debug1: Host '[s0-backend]:{redacted}' is known and matches the ED25519 host key.
debug1: Found key in /Users/eric/.ssh/known_hosts:40
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
...
{redacted}
...
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending env LC_TERMINAL = iTerm2
debug1: Sending env LC_TERMINAL_VERSION = 3.4.3
Welcome to Ubuntu 20.04.1 LTS (GNU/Linux 5.4.0-62-generic x86_64)
...
{redacted}
...
$
Is there your server with port 22 in .ssh/known_hosts?
If so, maybe you can remove this line and try to log again with the new port.
According to your log, built in ssh command loads configuration from /Users/my_username/.ssh/config
debug1: Reading configuration data /Users/my_username/.ssh/config
Check inside this file, there should be some configuration preventing the default client using any other port than 22. Since OpenSSH client doesn't use this configuration file, it has no issue connecting to port 2123.
Here is a similar issue
https://github.com/hashicorp/vagrant/issues/410#issuecomment-207278540
I want to SSH to a machine (call it A). It's sshd config file looks like below:
AllowGroups wheel
AllowTcpForwarding no
AuthorizedKeysFile .ssh/authorized_keys
Banner /etc/issue
ChallengeResponseAuthentication no
Ciphers aes256-ctr,aes128-ctr
Compression delayed
GatewayPorts no
MACs hmac-sha1
MaxSessions 1
PasswordAuthentication yes
PermitRootLogin yes
PermitTunnel no
PermitUserEnvironment no
Protocol 2
RhostsRSAAuthentication no
StrictModes yes
Subsystem sftp /usr/lib64/ssh/sftp-server
UsePAM yes
UsePrivilegeSeparation yes
X11Forwarding no
I have another machine (call it B - ssh client)
Now, if I try to ssh to machineA as below, it works perfect:
ssh root#machineA
and then interactively provide password. Works perfect!
Now, I try passing password via a script using sshpass utility as below:
sshpass -p PASSWORD ssh -vvv -o=StrictHostKeyChecking=no root#machineA
This fails.
Last few lines from debug of -vvv gives below:
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
debug3: packet_send2: adding 64 (len 51 padlen 13 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
/var/log/auth.log on machine A says below:
Connection from machineB port 44408
Failed password for root from machineB port 44408 ssh2
Connection closed by machineB port 44408 [preauth]
lastb command gives below:
root ssh:notty machineB Sun Jul 3 04:20 - 04:20 (00:00)
root ssh:notty machineB Sun Jul 3 04:19 - 04:19 (00:00)
I have been reading around for it. But, not something that I can stop at. Do you have any pointers? What could be the problem?
Anything related to sshpass or something?
I would try to narrow the problem:
Try with a simpler password, without special characters.
Try with a user different than root.
Try using certificates instead of password.
That is explained here: https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Your-SSH-Public-Key , https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2 etc.
Have a look at the server logs as well, check /var/log/secure or alike.
I have 2 Pi on 2 separate networks, running raspbian, one is a web server, the other is used to backup (let's say pi-server and pi-backup), and I would like pi-server to ssh to pi-backup in order to backup data. I manage to do that typing this on pi-server :
ssh -p 4444 userBackup#pibackup.fr
userBackup#pibackup.fr's password :
I type my password and then I am prompted on pi-backup and all is great (pi-backup's ssh listen on 22 but I redirect 4444 to 22 with my router, heard it was more secured)
As I would like to script the connexion to be able to cron it everyday, I can't authentify by password, so I tried keys : I generated a key on pi-server using
ssh-keygen
Then I copy/pasted id_rsa_pub in /home/userBackup/.ssh/authorized_keys... But I am still asked for a password when I try to connect.
What I find surprising, is that I already connect to pi-backup with a key (of course different) from my main PC, which is on the same local network than pi-backup. So I have two lines in authorized_keys.
Do you have any idea what could be going wrong ? Not being on the same local network shouldn't be a problem, should it ?
[edit] When I try
ssh -v -i ~/.ssh/id_rsa -p 4444 userBackup#pibackup.fr
here is what I get :
OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to pibackup.fr [90.10.1.1] port 4444.
debug1: Connection established.
debug1: identity file /home/userServer/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/userServer/.ssh/id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Raspbian-5
debug1: match: OpenSSH_6.7p1 Raspbian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 6b:5f:aa:aa:aa0c:aa:33:97:aa:56:aa:39:00:6f:79
debug1: Host '[pibackup.fr]:4444' is known and matches the ECDSA host key.
debug1: Found key in /home/userBackup/.ssh/known_hosts:2
Warning: Permanently added the ECDSA host key for IP address '[90.10.1.1]:4444' to the list of known hosts.
debug1: ssh_ecdsa_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: /home/userServer/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
userBackup#piBackup.fr's password:
I have noted that in the last lines, he says "Offering RSA public key: /home/userServer/.ssh/id_rsa" so I tried with my public key instead, but nothing changed.
You must specify your key generated with ssh-keygen in your ssh line. You can do it like this:
ssh -i ~/.ssh/blah.key -p 4444 userBackup#pibackup.fr it will load your key.
I hope it will help you.
I finally found the problem : on serverBackup, userBackup wasn't the owner of authorized_keys... that's all ;). I still don't understand why it was working when I connected from my lan PC, but now all is great ! Ankirama, thansk for your time and advices.
I'm trying to get some chrooting in place for PCI compliance. I'd like a few users to only be able to connect via sftp and not ftp (which I can easily restrict). However I need the sftp users to be chrooted so they can traverse up the dir tree and see everything.
I added this to my openssh ssd_config file to test on one user first:
Match User dbl
ChrootDirectory %h
AllowTCPForwarding no
X11Forwarding no
ForceCommand internal-sftp
When I try to connect I get this output:
$ sftp -v dbl#hostname
OpenSSH_5.9p1, OpenSSL 0.9.8x 10 May 2012
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: Connecting to hostname [x.x.x.x] port 22.
debug1: Connection established.
debug1: identity file /Users/me/.ssh/id_rsa type 1
debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
debug1: identity file /Users/me/.ssh/id_dsa type -1
debug1: identity file /Users/me/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2p2-hpn13v14 FreeBSD-openssh-portable-6.2.p2_2,1
debug1: match: OpenSSH_6.2p2-hpn13v14 FreeBSD-openssh-portable-6.2.p2_2,1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
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: Server host key: RSA 54:8b:66:39:15:d4:6f:ed:82:d4:c2:82:b0:a3:45:03
debug1: Host 'hostname' is known and matches the RSA host key.
debug1: Found key in /Users/me/.ssh/known_hosts:35
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/me/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /Users/me/.ssh/id_dsa
debug1: Next authentication method: password
dbl#hostname's password:
debug1: Authentication succeeded (password).
Authenticated to hostname ([x.x.x.x]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions#openssh.com
debug1: Entering interactive session.
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
Connection to hostname closed by remote host.
Transferred: sent 1920, received 2560 bytes, in 0.0 seconds
Bytes per second: sent 1111840.9, received 1482454.5
debug1: Exit status -1
Connection closed
As you can see, right after I type in the password it lets me in then immediately closes the connection. It doesn't even bring up the sftp prompt like it should. I've tried a few other posts on here that seem related but haven't gotten anywhere.
Each user has /bin/sh as their shell.
I've seen a bunch of similar issues people have had with SFTP in the past and most of the time it was solved by adding the top line that's missing to your sshd_config
Subsystem sftp internal-sftp
Match Group sftponly
ChrootDirectory /home/%u
ForceCommand internal-sftp
AllowTcpForwarding no
Also if you plan to add a few more users it'd probably wise to set up an sftp group like my config below.
I put a blog post up a bit back, it's for openssh-5 however. Also contains a dirty but effective interactive script to set up a new user in seconds.. use it all the time for work when a new client comes on board.
http://264nmtechblog.wordpress.com/2013/10/
Hope this is some help - if not maybe post your /var/log/secure which might give you a better heads up if your problem is permission based.