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?

Sftp not able to connect in magento2.2.5?

I am not able to connect to Sftp in magento2.2.5

Here is my code:

public function execute()     {         $  connection = $  this->sftp->open(                     array(                         'host' => 'myhostname',                         'username' => 'myusername',                         'password' => 'mypassword',                         'port' =>22,                         'passive' => true                     )                 );         if($  connection){         echo "true";          }else{             echo "false";         }                 //print_r($  connection);         die; 

But it is returning false.

I don’t know what is the problem.

Any help would be appreciated.

SFTP Net Drive Batch File

I am currently using the following software to map my FTP servers to windows. I have multiple profiles which i would like to start, when windows starts.

I have created my pofiles and then a simple batach file like this:

start " " C:\Program Files (x86)\SFTP Net Drive 2017>SftpNetDrive.exe start /profile:"FTPserver1" start " " C:\Program Files (x86)\SFTP Net Drive 2017>SftpNetDrive.exe start /profile:"FTPserver2" exit 

When i run the batch file, i get an error saying windows cannot find the program.

If i copy the above command directly into CMD it works.

Any ideas what the issue could be?

Thanks

Logging SFTP File Transfers in Docker container

I want to log SFTP file transfers. My sshd_conf is:

Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_ed25519_key  PermitRootLogin yes  AuthorizedKeysFile      .ssh/authorized_keys  PasswordAuthentication yes  UsePAM yes  AllowTcpForwarding no X11Forwarding no UseDNS no  Subsystem sftp /usr/libexec/openssh/sftp-server -l INFO -f AUTH 

Host keys generated like this:

$   ssh-keygen -N "" -t rsa -f ssh_host_rsa_key $   ssh-keygen -N "" -t ed25519 -f ssh_host_ed25519_key 

SFTP server runs in Docker container created by this Dockerfile:

FROM centos:7  RUN yum install -y openssh-server  RUN echo 'root:123456' | chpasswd  COPY ssh_host_rsa_key /etc/ssh/ssh_host_rsa_key COPY ssh_host_ed25519_key /etc/ssh/ssh_host_ed25519_key COPY sshd_config /etc/ssh/sshd_config  RUN chmod 400 /etc/ssh/*  EXPOSE 22  CMD ["/usr/sbin/sshd", "-D", "-e"] 

And the only output I have after successful login and file uploading:

$   docker run --rm --name sftp-server -p "2222:22" test/sftp Server listening on 0.0.0.0 port 22. Server listening on :: port 22. Accepted keyboard-interactive/pam for root from 172.17.0.1 port 58556 ssh2 

However, I would expect output as described in OpenSSH wiki:

Oct 22 11:59:50 server internal-sftp[4929]: open "/home/fred/foo" flags WRITE,CREATE,TRUNCATE mode 0664 Oct 22 11:59:50 server internal-sftp[4929]: close "/home/fred/foo" bytes read 0 written 928 

What might be a problem with my setup?

How to secure SFTP against symlink attack?

I’ve configured SFTP on my virtual machine, because I wanted to test how can I use symlink in order to access files outside from user home directory.

I’ve created user:

test:x:1003:1001::/var/www/test/public:/bin/false 

Ownership and premissions:

drwxr-xr-x  root root test  drwxr-xr-x test sftpusers public 

Here is my sshd_config:

Subsystem sftp internal-sftp  #UsePAM no  Match group sftpusers ChrootDirectory /var/www/%u AuthorizedKeysFile /var/www/%u/.ssh/authorized_keys X11Forwarding no AllowTcpForwarding no ForceCommand internal-sftp 

After that I had to login into my SFTP account and from there I did:

sftp> symlink / /public/root 

I think most of the servers which use SFTP are configured in a similar way.

So, what can be done in order to prevent symlink attack?