Limited user with SFTP access

I have created a user with nologin permission but when in sshd_config file i add Match group with new created group i.e sftp and restart the sshd_service it shows me error of “Match group” clause .I am using RHEL 5.7 and no luck in finding any relavant answer.PFB sshd configuration.

This is the sshd server system-wide configuration file. See

sshd_config(5) for more information.

This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin

The strategy used for options in the default sshd_config shipped with

OpenSSH is to specify options with their default value where

possible, but leave them commented. Uncommented options change a

default value.

Port 22

Protocol 2,1

Protocol 2

AddressFamily any

ListenAddress 0.0.0.0

ListenAddress ::

HostKey for protocol version 1

HostKey /etc/ssh/ssh_host_key

HostKeys for protocol version 2

HostKey /etc/ssh/ssh_host_rsa_key

HostKey /etc/ssh/ssh_host_dsa_key

Lifetime and size of ephemeral version 1 server key

KeyRegenerationInterval 1h

ServerKeyBits 768

Logging

obsoletes QuietMode and FascistLogging

SyslogFacility AUTH

SyslogFacility AUTHPRIV
LogLevel INFO

Authentication:

LoginGraceTime 2m

PermitRootLogin yes

StrictModes yes

MaxAuthTries 6

RSAAuthentication yes

PubkeyAuthentication yes

AuthorizedKeysFile .ssh/authorized_keys

For this to work you will also need host keys in /etc/ssh/ssh_known_hosts

RhostsRSAAuthentication no

similar for protocol version 2

HostbasedAuthentication no

Change to yes if you don’t trust ~/.ssh/known_hosts for

RhostsRSAAuthentication and HostbasedAuthentication

IgnoreUserKnownHosts no

Don’t read the user’s ~/.rhosts and ~/.shosts files

IgnoreRhosts yes

To disable tunneled clear text passwords, change to no here!

PasswordAuthentication yes

PermitEmptyPasswords no

PasswordAuthentication yes

Change to no to disable s/key passwords

ChallengeResponseAuthentication yes

ChallengeResponseAuthentication no

Kerberos options

KerberosAuthentication no

KerberosOrLocalPasswd yes

KerberosTicketCleanup yes

KerberosGetAFSToken no

GSSAPI options

GSSAPIAuthentication no

GSSAPIAuthentication yes

GSSAPICleanupCredentials yes

GSSAPICleanupCredentials yes

Set this to ‘yes’ to enable PAM authentication, account processing,

and session processing. If this is enabled, PAM authentication will

be allowed through the ChallengeResponseAuthentication mechanism.

Depending on your PAM configuration, this may bypass the setting of

PasswordAuthentication, PermitEmptyPasswords, and

“PermitRootLogin without-password”. If you just want the PAM account and

session checks to run without PAM authentication, then enable this but set

ChallengeResponseAuthentication=no

UsePAM no

UsePAM yes

Accept locale-related environment variables

AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL

AllowTcpForwarding yes

GatewayPorts no

X11Forwarding no

X11Forwarding yes

X11DisplayOffset 10

X11UseLocalhost yes

PrintMotd yes

PrintLastLog yes

TCPKeepAlive yes

UseLogin no

UsePrivilegeSeparation yes

PermitUserEnvironment no

Compression delayed

ClientAliveInterval 0

ClientAliveCountMax 3

ShowPatchLevel no

UseDNS yes

PidFile /var/run/sshd.pid

MaxStartups 10

PermitTunnel no

ChrootDirectory none

no default banner path

Banner /some/path

override default of no subsystems

Subsystem sftp /usr/libexec/openssh/sftp-server

Subsystem sftp internal-sftp
Match group sftp
ChrootDirectory /sftp/
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp

Dolphin on SFTP “Communication with the local password server failed”

Apparently every once in a while I get this weird “Communication with the local password server failed” error when trying to access SFTP via dolphin, while Terminal access still works.

While a reboot can temporarily fix that is there a way to fix it permanently or without reboot, like restarting that “Password Server” thing?

Security risks of file shares vs ssh or sftp, in “backward” direction?

I work for a municipal government, using mostly Windows servers. In recent days several similar governments in our geographic area have been attacked, some successfully, by ransomware. So our security folks are alarmed, and have decreed (among other things) no more using SMB file-sharing to upload files from the “internal” network to the DMZ. I have a PowerShell script that does just that, to migrate databases; plus we have many other cases to use file shares such as uploading web sites.

They are saying we need to convert to using SSH or SFTP to transfer files. OK, this would be possible, but it would need setup work on every DMZ server, and changing all our current processes, and for what? (We don’t have enough people to do that plus everything else, although we’ve tried to get more warm bodies budgeted.) Anyway I don’t see how that’s more secure. If DMZ server D is listening on a share, and the firewall prevents access from anywhere but authorized internal workstations or servers A, B, and C, then how can that be any more a security risk (specifically, the risk of malware on server D going back the other way and compromising A, B, or C) than server D listening on an SFTP port or an SSH port, with the same firewall restrictions?

If the issue is something like “the file share is open all the time, but SSH isn’t,” then that would be somewhat understandable, and we might deal with that by mapping and unmapping to the shares when needed. But I don’t think this is their reasoning; I think it’s something else. Actually I get the impression it’s kind of a vague “feeling” on their part, that file shares are inherently and materially less secure, in the “backward” direction, even if firewall-protected as described above. If this is actually so, then why? I just don’t see it. Actually I don’t see why any of those protocols would pose a risk in the “backward” direction.

Mounted SFTP with Dolphin, how to access from command line?

I have mounted an SFTP share using Dolphin, which all works perfectly. However, I would also like to browse these files from the command line.

Pressing F4 in Dolphin to bring up a terminal window just gives me my home directory, and not the remote one. I cannot see the remote mount when running mount.

Is there a way to cd to the SFTP after mounting it in Dolphin, like I could if I had mounted it with sshfs?

What speaks against using a PowerShell PSDrive for SFTP?

When searching for SFTP in PowerShell I find Posh-SSH and WinSCP (see https://stackoverflow.com/questions/38732025/upload-file-to-sftp-using-powershell). Surely working solutions. But when I started looking for SFTP in PowerShell I expected to find a PSDrive. Is the concept of PSDrives not fitting or what might be the reason there is no SFPT-PSDrive? There must be a reason why WinSCP and Posh-SSH took an other approach.

What version of Nautilus fixed the SFTP always asking for password bug?

I’m running Ubuntu, and I was wondering if anyone knows what release this bug was fixed in Nautilus?

The bug is Nautilus, no matter what setting you use for storing the password: “Remember Forever, Until I sign out” would ask for it every time.

I’m only asking for the version number of the package I need to obtain (whether it be nautilus or some library it uses).

SFTP client connects, but stops at OpenSSH version

I have a weird situation which I have been unable to determine the root cause for. I have a service I need to connect via SFTP to on the internet. When connecting via SFTP this is what I see when running it in debug mode:

[user1@localhost-live ~]$   sftp -oIdentityFile=~/.ssh/privatekey -oPort=4321 -vvv user1@1.2.3.4 OpenSSH_7.9p1, OpenSSL 1.1.1b FIPS  26 Feb 2019 debug1: Reading configuration data /etc/ssh/ssh_config debug3: /etc/ssh/ssh_config line 52: Including file /etc/ssh/ssh_config.d/05-redhat.conf depth 0 debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf debug2: checking match for 'final all' host 1.2.3.4 originally 1.2.3.4 debug3: /etc/ssh/ssh_config.d/05-redhat.conf line 3: not matched 'final' debug2: match not found debug3: /etc/ssh/ssh_config.d/05-redhat.conf line 5: Including file /etc/crypto-policies/back-ends/openssh.config depth 1 (parse only) debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config debug3: gss kex names ok: [gss-gex-sha1-,gss-group14-sha1-,gss-group1-sha1-] debug3: kex names ok: [curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1] debug1: configuration requests final Match pass debug2: resolve_canonicalize: hostname 1.2.3.4 is address debug1: re-parsing configuration debug1: Reading configuration data /etc/ssh/ssh_config debug3: /etc/ssh/ssh_config line 52: Including file /etc/ssh/ssh_config.d/05-redhat.conf depth 0 debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf debug2: checking match for 'final all' host 1.2.3.4 originally 1.2.3.4 debug3: /etc/ssh/ssh_config.d/05-redhat.conf line 3: matched 'final' debug2: match found debug3: /etc/ssh/ssh_config.d/05-redhat.conf line 5: Including file /etc/crypto-policies/back-ends/openssh.config depth 1 debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config debug3: gss kex names ok: [gss-gex-sha1-,gss-group14-sha1-,gss-group1-sha1-] debug3: kex names ok: [curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1] debug2: ssh_connect_direct debug1: Connecting to 1.2.3.4 [1.2.3.4] port 4321. debug1: Connection established. debug1: identity file /home/user1/.ssh/privatekey type -1 debug1: identity file /home/user1/.ssh/privatekey-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_7.9 

As you can see the connection is established and my system provides the private key, but after the entry “Local version string SSH-2.0-OpenSSH_7.9”, the client and server just stop communicating. The server doesn’t drop the connection, or continues. It’s just stuck.

I thought the issue could be related to the version of OpenSSH and or OpenSSL. Neither one seems to be the case. I’m running on the client side OpenSSH 7.9p1 and OpenSSL 1.1.1b. The server on the other end is running with the following settings:

 # override default of no subsystems  Subsystem sftp internal-sftp  # sftp only on port 4321 (it's exposed to internet)  Match LocalPort 4321  ForceCommand internal-sftp  X11Forwarding no  AllowTCPForwarding no  ChrootDirectory /mnt/efs/sftp/%u 

And this is OpenSSH_7.4p1, OpenSSL 1.0.2k-fips running on Red Hat 7.4.

What is weird is that the client that I was using in the above instance is a Fedora 30 version and its pretty close to bleeding edge.

I run locally on my machine Manjaro Linux and when I try to connect to the same system, the result is different. The versions I’m running there are OpenSSH_8.0p1 and OpenSSL 1.1.1b. I’m able to connect without issue. Below is the output;

 [user1@user1-m380 ~]$   sftp -oIdentityFile=~/.ssh/privatekey -oPort=4321 -vvv user1@1.2.3.4  OpenSSH_8.0p1, OpenSSL 1.1.1b  26 Feb 2019  debug1: Reading configuration data /home/user1/.ssh/config  debug1: /home/user1/.ssh/config line 1: Applying options for *  debug1: Reading configuration data /etc/ssh/ssh_config  debug2: resolve_canonicalize: hostname 1.2.3.4 is address  debug2: ssh_connect_direct  debug1: Connecting to 1.2.3.4 [1.2.3.4] port 4321.  debug1: Connection established.  debug1: identity file /home/user1/.ssh/privatekey type -1  debug1: identity file /home/user1/.ssh/privatekey-cert type -1  debug1: Local version string SSH-2.0-OpenSSH_8.0  debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4  debug1: match: OpenSSH_7.4 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002  debug2: fd 3 setting O_NONBLOCK  debug1: Authenticating to 1.2.3.4:4321 as 'user1'  debug3: put_host_port: [1.2.3.4]:4321  debug3: hostkeys_foreach: reading file "/home/user1/.ssh/known_hosts"  debug3: record_hostkey: found key type ECDSA in file /home/user1/.ssh/known_hosts:1177  debug3: load_hostkeys: loaded 1 keys from [1.2.3.4]:4321  debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521  debug3: send packet: type 20  debug1: SSH2_MSG_KEXINIT sent  debug3: receive packet: type 20  debug1: SSH2_MSG_KEXINIT received  debug2: local client KEXINIT proposal  debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c  debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa  debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com  debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com  debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1  debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1  debug2: compression ctos: none,zlib@openssh.com,zlib  debug2: compression stoc: none,zlib@openssh.com,zlib  debug2: languages ctos:   debug2: languages stoc:   debug2: first_kex_follows 0   debug2: reserved 0   debug2: peer server KEXINIT proposal  debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1  debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519  debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,cast128-cbc,3des-cbc  debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,cast128-cbc,3des-cbc  debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1  debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1  debug2: compression ctos: none,zlib@openssh.com  debug2: compression stoc: none,zlib@openssh.com  debug2: languages ctos:   debug2: languages stoc:   debug2: first_kex_follows 0   debug2: reserved 0   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  debug3: send packet: type 30  debug1: expecting SSH2_MSG_KEX_ECDH_REPLY  debug3: receive packet: type 31  debug1: Server host key: ecdsa-sha2-nistp256 SHA256:IUUTqOtpUjNSRAOgze0OiVsUoLhm8sgvhTcOtNgFTfe  debug3: put_host_port: [1.2.3.4]:4321  debug3: put_host_port: [1.2.3.4]:4321  debug3: hostkeys_foreach: reading file "/home/user1/.ssh/known_hosts"  debug3: record_hostkey: found key type ECDSA in file /home/user1/.ssh/known_hosts:1177  debug3: load_hostkeys: loaded 1 keys from [1.2.3.4]:4321  debug3: hostkeys_foreach: reading file "/home/user1/.ssh/known_hosts"  debug3: record_hostkey: found key type ECDSA in file /home/user1/.ssh/known_hosts:1177  debug3: load_hostkeys: loaded 1 keys from [1.2.3.4]:4321  debug1: Host '[1.2.3.4]:4321' is known and matches the ECDSA host key.  debug1: Found key in /home/user1/.ssh/known_hosts:1177  debug3: send packet: type 21  debug2: set_newkeys: mode 1  debug1: rekey out after 134217728 blocks  debug1: SSH2_MSG_NEWKEYS sent  debug1: expecting SSH2_MSG_NEWKEYS  debug3: receive packet: type 21  debug1: SSH2_MSG_NEWKEYS received  debug2: set_newkeys: mode 0  debug1: rekey in after 134217728 blocks  debug1: Will attempt key: /home/user1/.ssh/privatekey  explicit  debug2: pubkey_prepare: done  debug3: send packet: type 5  debug3: receive packet: type 7  debug1: SSH2_MSG_EXT_INFO received  debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>  debug3: receive packet: type 6  debug2: service_accept: ssh-userauth  debug1: SSH2_MSG_SERVICE_ACCEPT received  debug3: send packet: type 50  debug3: receive packet: type 51  debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic  debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic  debug3: preferred publickey,keyboard-interactive,password  debug3: authmethod_lookup publickey  debug3: remaining preferred: keyboard-interactive,password  debug3: authmethod_is_enabled publickey  debug1: Next authentication method: publickey  debug1: Trying private key: /home/user1/.ssh/privatekey  Enter passphrase for key '/home/user1/.ssh/privatekey':   debug3: sign_and_send_pubkey: RSA SHA256:y1HxyI+tlh1DfEuWDjLHLOSUGXo44YzNnrBSrxFh7vG  debug3: sign_and_send_pubkey: signing using rsa-sha2-512  debug3: send packet: type 50  debug2: we sent a publickey packet, wait for reply  debug3: receive packet: type 52  debug1: Authentication succeeded (publickey).  Authenticated to 1.2.3.4 ([1.2.3.4]:4321).  debug2: fd 4 setting O_NONBLOCK  debug3: fd 5 is O_NONBLOCK  debug1: channel 0: new [client-session]  debug3: ssh_session2_open: channel_new: 0  debug2: channel 0: send open  debug3: send packet: type 90  debug1: Requesting no-more-sessions@openssh.com  debug3: send packet: type 80  debug1: Entering interactive session.  debug1: pledge: network  debug3: receive packet: type 80  debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0  debug3: receive packet: type 91  debug2: channel_input_open_confirmation: channel 0: callback start  debug2: fd 3 setting TCP_NODELAY  debug3: ssh_packet_set_tos: set IP_TOS 0x20  debug2: client_session2_setup: id 0  debug1: Sending subsystem: sftp  debug2: channel 0: request subsystem confirm 1  debug3: send packet: type 98  debug2: channel_input_open_confirmation: channel 0: callback done  debug2: channel 0: open confirm rwindow 0 rmax 32768  debug2: channel 0: rcvd adjust 2097152  debug3: receive packet: type 99  debug2: channel_input_status_confirm: type 99 id 0  debug2: subsystem request accepted on channel 0  debug2: Remote version: 3  debug2: Server supports extension "posix-rename@openssh.com" revision 1  debug2: Server supports extension "statvfs@openssh.com" revision 2  debug2: Server supports extension "fstatvfs@openssh.com" revision 2  debug2: Server supports extension "hardlink@openssh.com" revision 1  debug2: Server supports extension "fsync@openssh.com" revision 1  Connected to user1@1.2.3.4.  debug3: Sent message fd 3 T:16 I:1  debug3: SSH_FXP_REALPATH . -> / size 0  sftp> 

Unlike the previous connection, we are able to obtain the version of OpenSSH that’s running on the target system and we are off to the races.

From this information provided can anyone let me know what I may be doing wrong here? Am I missing the configuration piece on the client side that would not let me connect? Could the issue be on the target system?