I manage a Debian (Bookworm) host. The sshd config is set to disallow login as root. I've tested that one cannot login as root, as expected. However, I see hundreds of login attempts daily as root in /var/log/auth.log. Even though I have what I think is adequate reason to believe they can't succeed, the constant brute-force attacks make me uneasy. I am considering adding a ufw rule in /etc/ufw/before.rules to block any attempt to connect with ssh as root. Is there any value in adding the proposed rule or something like it? Or would that be redundant and/or potentially cause problems?

I am trying to ssh to remote machine, the attempt fails: $ ssh -vvv admin@192.168.100.14 OpenSSH_7.7p1, OpenSSL 1.0.2o 27 Mar 2018 ..... debug2: ciphers ctos: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc debug2: ciphers stoc: aes128-cbc,3des-cbc,aes192-cbc,aes256-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: rsa-sha2-512 Unable to negotiate with 192.168.100.14 port 22: no matching cipher found. Their offer: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc As far as I understand the last string of the log, the server offers to use one of the following 4 cipher algorithms: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc. Looks like my ssh client doesn't support any of them, so the server and client are unable to negotiate further. But my client does support all the suggested algorithms: $ ssh -Q cipher 3des-cbc aes128-cbc aes192-cbc aes256-cbc rijndael-cbc@lysator.liu.se aes128-ctr ... and there are several more. And if I explicitly specify the algorithm like this: ssh -vvv -c aes256-cbc admin@192.168.100.14 I can successfully login to the server. My ~/.ssh/config doesn't contain any cipher-related directives (actually I removed it completely, but the problem remains). So, why client and server can't decide which cipher to use without my explicit instructions? The client understands that server supports aes256-cbc, client understands that he can use it himself, why not just use it? Some additional notes: - There was no such problem some time (about a month) ago. I've not changed any ssh configuration files since then. I did update installed packages though. - There is a question which describes very similar-looking problem, but there is no answer my question: https://unix.stackexchange.com/questions/402746 UPDATE: problem solved As telcoM explained the problem is with server: it suggests only the obsolete cipher algorithms. I was sure that both client and server are not outdated. I have logged into server (by the way, it's Synology, updated to latest available version), and examined the /etc/ssh/sshd_config. The very first (!) line of this file was: Ciphers aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc This is very strange (the fact that line is very first in the file), I am sure I've never touched the file before. However I've changed the line to: Ciphers aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc restarted the server (did not figure out how to restart the sshd service only), and now the problem is gone: I can ssh to server as usual.

I want to allow moving files to a specific directory on my server using rsync + ssh. However, I don't want to fully trust the users using that SSH user. One solution I found is to set the shell of the user to rssh which can be configured to only allow sftp, rsync etc. However, in this case, the user would still be able to pull any readable files from the server, such as configurations in /etc which I don't want. I'm currently hesitating to go over my full directory structure and revoking the access for "others". Is there a way to allow a user to use rsync via ssh but only from / to a specific directory? I've seen that it seems possible to jail the SFTP access of openssh:

Match Group sftponly
  ChrootDirectory %h
  ForceCommand internal-sftp
  AllowTcpForwarding no
  X11Forwarding no
  PasswordAuthentication no

However, I would prefer rsync, as this account is used to upload bigger data and the internet connections are somewhat unstable (rural area with bad internet). rsync has proven very effective with all its features of continuing cancelled uploads.

I am trying to forward all requests from local port 8888 to port 8888 to my remote Amazon EC2 instance. The only difference is that my EC2 instance is running ssh on custom port 56129. I can successfully ping my ec2 instance from the local system but when I try to forward requests from a local port to a port on ec2 instance, I am getting: >channel 2: open failed: administratively prohibited: open failed I am using the following command: ssh -i -NfL 8888:localhost:8888 @ -p 56129 Then it asks for a password. There are no messages when it accepts the password. But as soon as I open localhost:8888 in my browser, I get the error message: >channel 2: open failed: administratively prohibited: open failed Some observations - - Running ssh -i @ -p 56129 with a password is successful. - I am running Jupyter Notebook at port 8888 in EC2 instance. curl localhost:8888 returns nothing when done after ssh-ing into the instance

With the following Dockerfile: FROM nexylan/php-dev:7.1-alpine COPY entrypoint.sh / RUN chmod u+x /entrypoint.sh ENTRYPOINT ["/entrypoint.sh"] WORKDIR /code CMD ["tail", "-f", "/dev/null"] (The entrypoint does nothing related to the issue). The definition on docker-compose: version: '2' services: data: image: alpine volumes: - .:/code console: build: docker/php-console volumes_from: - data env_file: - .env And the following commands on Gitlab CI commands: image: docker services: - docker:dind before_script: - docker info - apk add --update bash python py-pip python-dev - pip install docker-compose - docker-compose up -d - docker-compose ps - docker-compose exec -T console make install stages: - test test: stage: test tags: [docker-privileged] script: - echo ${SSH_PRIVATE_KEY} > tests/fixtures/ssh/key - echo ${SSH_PUBLIC_KEY} > tests/fixtures/ssh/key.pub - chmod 600 tests/fixtures/ssh/* - docker-compose exec -T console ls -l tests/fixtures/ssh/ - docker-compose exec -T console chmod 777 /dev/tty - docker exec -t flintci_console_1 ssh -o StrictHostKeyChecking=no -i tests/fixtures/ssh/key -T -vvv git@github.com The SSH command is always prompting for a passphrase with the following log: OpenSSH_7.2p2-hpn14v4, OpenSSL 1.0.2k 26 Jan 2017 debug1: Reading configuration data /etc/ssh/ssh_config debug2: resolving "github.com" port 22 debug2: ssh_connect_direct: needpriv 0 debug1: Connecting to github.com [192.30.253.112] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file tests/fixtures/ssh/key type 1 debug1: key_load_public: No such file or directory debug1: identity file tests/fixtures/ssh/key-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.2p2-hpn14v4 debug1: Remote protocol version 2.0, remote software version libssh_0.7.0 debug1: no match: libssh_0.7.0 debug2: fd 3 setting O_NONBLOCK debug1: Authenticating to github.com:22 as 'git' 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@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,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,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,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,aes128-cbc,aes192-cbc,aes256-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,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,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@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: host key algorithms: ssh-dss,ssh-rsa debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc debug2: MACs ctos: hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: compression ctos: none,zlib,zlib@openssh.com debug2: compression stoc: none,zlib,zlib@openssh.com debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug1: kex: algorithm: curve25519-sha256@libssh.org debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: compression: none debug3: send packet: type 30 debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug3: receive packet: type 31 debug1: Server host key: ssh-rsa SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8 Warning: Permanently added 'github.com,192.30.253.112' (RSA) to the list of known hosts. debug3: send packet: type 21 debug2: set_newkeys: mode 1 debug1: rekey after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug3: receive packet: type 21 debug2: set_newkeys: mode 0 debug1: rekey after 134217728 blocks debug1: SSH2_MSG_NEWKEYS received debug2: key: tests/fixtures/ssh/key (0x55b4bd4e81a0), explicit debug3: send packet: type 5 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 debug3: start over, passed a different list publickey 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: Offering RSA public key: tests/fixtures/ssh/key debug3: send_pubkey_test debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 60 debug1: Server accepts key: pkalg ssh-rsa blen 279 debug2: input_userauth_pk_ok: fp SHA256:3aoR/R1oBDYb0QucuGCJfBgIWW4DE2P4DjuWwgtQg/k debug3: sign_and_send_pubkey: RSA SHA256:3aoR/R1oBDYb0QucuGCJfBgIWW4DE2P4DjuWwgtQg/k Enter passphrase for key 'tests/fixtures/ssh/key': The key has no passphrase, and the same docker command works well on my local laptop, not on GitLab CI. What I'm missing?

I'm setting up a crontab server to run several jobs to copy files from prod servers to lower environment servers. I need the cron server job to copy files from one server to another. Here is what I have. the ip's have been modified ssh -v -R localhost:50000:1.0.0.2:22 -i host1key.pem ec2-user@1.0.0.1 'rsync -e "ssh -i /home/ec2-user/host2key.pem -p 50000" -vuar /home/ec2-user/test.txt ec2-user@localhost:/home/ec2-user/test.txt' I'm using two different pem keys and users. I would think this command would work but I get this error in the debug log. Here is more to it and only show the portion that is erroring. It connects to ec2-user@1.0.0.1 successfully. But errors on the 1.0.0.2:

debug1: connect_next: host 1.0.0.2 ([1.0.0.2]:22) in progress, fd=7
debug1: channel 1: new [127.0.0.1]
debug1: confirm forwarded-tcpip
debug1: channel 1: connected to 1.0.0.2 port 22
Host key verification failed.
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]
debug1: channel 0: free: client-session, nchannels 2
debug1: channel 1: free: 127.0.0.1, nchannels 1
Transferred: sent 5296, received 4736 bytes, in 0.9 seconds
Bytes per second: sent 5901.2, received 5277.2
debug1: Exit status 12

I am trying to disable Keyboard-Interactive login, as I only want key login, but it won't disable with the below sshd_config. I also have attached an edited ssh -v login to the server. I have been trying to follow here , here , and the documentation here sshd_config:

MaxAuthTries 3
PubkeyAuthentication yes

AuthorizedKeysFile      .ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords no

ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
UsePAM no



Subsystem       sftp    /usr/libexec/sftp-server

Edited ssh -v output:

OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d  10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to *.*.*.* [*.*.*.*] port **.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: identity file /home/user/.ssh/id_xmss type -1
debug1: identity file /home/user/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u2
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9 FreeBSD-20200214
debug1: match: OpenSSH_7.9 FreeBSD-20200214 pat OpenSSH* compat 0x04000000
debug1: Authenticating to *.*.*.*:** as 'user'
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:  compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC:  compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:qDEr5lkrjAHt0jMrLosrpQEPP5s0BdC0+7CHyRl3+oY
debug1: Host '*.*.*.*' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:2
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: Will attempt key: /home/user/.ssh/id_rsa
debug1: Will attempt key: /home/user/.ssh/id_dsa
debug1: Will attempt key: /home/user/.ssh/id_ecdsa
debug1: Will attempt key: /home/user/.ssh/id_ed25519
debug1: Will attempt key: /home/user/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Trying private key: /home/user/.ssh/id_dsa
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug1: Trying private key: /home/user/.ssh/id_xmss
debug1: Next authentication method: keyboard-interactive
Password for user@server:
debug1: Authentications that can continue: publickey,keyboard-interactive
Password for user@server:
debug1: Authentications that can continue: publickey,keyboard-interactive
Password for user@server:
Received disconnect from *.*.*.* port *:2: Too many authentication failures
Disconnected from *.*.*.* port **

ssh clients (by default, at least in Ubuntu 18.04 and FreeBSD 12) always check if server's key fingerprint is in the known_hosts file. I have a host in the LAN which has dual boot; both the OSs use the same static IP. I would like to connect through ssh to **both** of them, without encountering errors. This obviously violates the checks performed on known_hosts: if I accept one fingerprint, it will be related to the host IP; when OS is switched, the fingerprint changes, while the IP is the same, and I need to manually delete it in known_hosts before being able to connect again. I would like that one fingerprint, **or** the other, is accepted when considering that IP. Is there a **client side** solution to overcome this issue? I am using OpenSSH_7.8p1, OpenSSL 1.1.1a-freebsd 20 Nov 2018 and OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017. **Note**: I do not want "no check" over the server's fingerprint. I am just wondering if it is possible to relate two alternative fingerprints (not just one) to server's IP address.

I am on a Windows machine VPN'ed into an internal network, then RDP'd into my Kubuntu work machine. I can copy+paste into a terminal just fine using Ctrl+Shift C and Ctrl+Shift V. However, when I SSH into a Centos server, both stop working. Not only that, but right clicking the window and clicking "Copy" also doesn't work. Ideas?

A SOCKS5 proxy is between my source and target servers. The source server can be accessed only from my local server. I tried connecting through proxy option and SSH tunneling option in Winscp but the problem is as below: The SOCKS5 proxy is used only for my source server(tunneled one) instead, I would like to use it for my target server. Please let me know how I can achieve this. Flow: Local system -> Source server -> SOCKS5 proxy -> Target server

So, this is my setup: I have computer A and a computer B, both with Ubuntu 20.01. Each computer has openssh-server working just fine. Yesterday, I used rsync to copy a large file from A to B, and it didn't seem to have any issue (it was the first time rsync was used). Today, I tried to connect via SSH from B to A and I had a "No route to host" error. Then I tried to connect via SSH from A to B and "No route to host" happened again. Then, on each computer I did a: ssh user@127.0.0.1 and none gave me any issue. Then, I did a: ssh -T git@github.com on both computers and both were successful. Then, I did an: nmap -Pn -p22 192.168.xx.yy on both computers trying to connect to the other, the results are: PORT STATE SERVICE nmap tested in A with IP of A: 22/tcp filtered ssh nmap tested in A with IP of B: 22/tcp open ssh nmap tested in B with IP of A: 22/tcp filtered ssh nmap tested in B with IP of B: 22/tcp open ssh What really bugs me out is that yesterday, before using rsync, the ssh connection was working just fine. The file was copied successfully, and both computers have been restarted since, so I don't know if there's some file that was corrupted or something like that. I'm not even sure if the rsync is what caused the issue. Just to be sure, in computer A, I did a: sudo lsof -i -P -n | grep 192.168 And the only IP address that I see is the one from A. Not sure if this might help, but I only used one rsync command, and is the one that follows: rsync -rvz -e 'ssh -p XXXX' --progress /PATH/TO/SOURCE/FILE user@192.168.xx.yy:/PATH/TO/DESTINATION/FILE EDIT: I don't think the path is the issue, since I ran rsync from a dicerctory in /home/user, but for disclosure, the actual rsnc command was: rsync -rvz -e 'ssh -p 2222' --progress ./someDB.sql user@192.168.0.70:/home/user/DBs And as for the absolute path of where I ran the command, it was: /home/user/DB/

ssh connection closed immediately after I enter password

ssh -v hoogw@xx.238.125.xxx
OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug1: Connecting to 104.238.125.233 [104.238.125.233] port 22.
debug1: Connection established.
debug1: identity file /Users/nicole/.ssh/id_rsa type -1
debug1: identity file /Users/nicole/.ssh/id_rsa-cert type -1
debug1: identity file /Users/nicole/.ssh/id_dsa type -1
debug1: identity file /Users/nicole/.ssh/id_dsa-cert type -1
debug1: identity file /Users/nicole/.ssh/id_ecdsa type -1
debug1: identity file /Users/nicole/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/nicole/.ssh/id_ed25519 type -1
debug1: identity file /Users/nicole/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/nicole/.ssh/id_xmss type -1
debug1: identity file /Users/nicole/.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_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000002
debug1: Authenticating to 104.238.125.233:22 as 'hoogw'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: umac-64@openssh.com compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: umac-64@openssh.com compression: none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<3072<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-rsa SHA256:z9djZdxvUnzM6SLpcFo6INz6ixj3YFIF+dM/h3+JHh4
debug1: Host '104.238.125.233' is known and matches the RSA host key.
debug1: Found key in /Users/nicole/.ssh/known_hosts:1
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 4294967296 blocks
debug1: Will attempt key: /Users/nicole/.ssh/id_rsa 
debug1: Will attempt key: /Users/nicole/.ssh/id_dsa 
debug1: Will attempt key: /Users/nicole/.ssh/id_ecdsa 
debug1: Will attempt key: /Users/nicole/.ssh/id_ed25519 
debug1: Will attempt key: /Users/nicole/.ssh/id_xmss 
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/nicole/.ssh/id_rsa
debug1: Trying private key: /Users/nicole/.ssh/id_dsa
debug1: Trying private key: /Users/nicole/.ssh/id_ecdsa
debug1: Trying private key: /Users/nicole/.ssh/id_ed25519
debug1: Trying private key: /Users/nicole/.ssh/id_xmss
debug1: Next authentication method: password
hoogw@104.238.125.233's password: 
debug1: Authentication succeeded (password).
Authenticated to 104.238.125.233 ([104.238.125.233]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Last login: Fri Apr 24 14:10:52 2020 from 097-090-197-218.res.spectrum.com
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
Connection to 104.238.125.233 closed.
Transferred: sent 2600, received 2656 bytes, in 0.1 seconds
Bytes per second: sent 19405.6, received 19823.6
debug1: Exit status 0
nicole@nicoles-iMac ~ %

I'm backing ip my server via rsync over ssh but /var/log/lastlog file is 1.2G (it takes only 24K on the hdd). On a local machine cp can copy it for no time (a few ms) but rsync requires reading the whole file which takes hours. I also tried to mount server's /var/log with sshfs to my local pc but my local pc detects the file as 1.2T (so sshfs doesn't appear to detect sparse files). Is there some program that detects sparse files over ssh and can copy them the same way cp (without reading the empty blocks from the file) does? EDIT: rsync's -S/--sparse option still wants to read the whole source file (with all the empty bytes) which takes hours for 1.2T file. After rsync reads the whole file it creates small destination file (proper sparse file) but the problem is that it reads the source file with all the empty bytes (without skipping them). cp copies the file in a few ms while rsync takes hours. You can try it (on Linux) by creating 20G sparse file with truncate -s 20G sparse_file1 and copy it with rsync -S sparse_file1 sparse_file2 (takes long time) and then try to copy it with cp sparse_file1 sparse_file3 (takes a few ms).

I regularly ssh on several different servers, some of which don't have fish installed, but many do. I'd like to get fish as shell if available (changing midway is always tedious, and you lose the history of what you already typed), but changing the default shell is not a good idea, as: - there are many different machines that I would need to change; - on many other I'm logged in through LDAP, and changing my shell as stored on LDAP would break on machines where fish is not available; - in general, as fish is not POSIX-sh compatible putting it as default shell may break commands executed by scripts through ssh; - finally, there are a few machines where the user is shared with other people (or, where I have to login another user), so changing the default shell is not a good idea. So, ideally I'd like to have a command like ssh that automagically starts fish if available, or just leave whatever default shell is provided otherwise.

I have a dedicated server. There's a VNC Server and I can connect to VNC Server with a VNC Client with port 5901 so it takes me to display :1 when I connect there with a VNC Client. I've read pretty many documents about ssh -L and ssh -R command-line commands, but it's pretty weird, because they have servers and such on their own machines and on their remote machines so I get confused about that where are they even trying to connect and what etc. 1. I have dedicated server with VNC Server, Web Server, Game Server and Firewall. 2. VNC Server is running and TCP/UDP connection has been enabled only to ports of Web Server, SSH, Game Server. 3. I want connect to my VNC Server with my VNC Client (from my own pc), but using a tunneled connection, because people are trying my password too many times or something, because sometimes it says "Too many authentication failures" what a tards they are, because they will never guess the password. Anyways. I have tried similar: ssh root@DEDICATEDIP -L 5901:DEDICATEDIP:5901 ssh root@DEDICATEDIP -R 5901:DEDICATEDIP:5901 I also tried this one (found from this site): ssh -L 5901:localhost:5901 -p 22 root@DEDICATEDIP If I write "su" in SSH and I write my root password I can get in with root account, but when it asks my root password on ssh after trying to fill any of these tunneling commands it says the password is wrong and permission denied? **Edit:** - My PC: PuTTy (SSH Client), VNC Viewer (VNC Client) - Dedibox: VNC Server, GameServer, Web Server, SSH Server ufw status - 22 - ALLOW - Anywhere - 22 - ALLOW OUT - Anywhere VNC Server is running and I can confirm that. If I add 5901 to ALLOW and ALLOW OUT I can simply connect there without a tunneling. 1. (My PC) Open PuTTY 2. (My PC) PuTTY Configuration -> Connection -> SSH -> Tunnels - Source port - Destination [163.xxx.xxx.xxx:5901] - [ADD] 3. Now PuTTY shows "Forwarded ports: " -> "L5902 163.xxx.xxx.xxx:5901" 4. I connect to server with SSH including the Tunnel settings I've configured now. 5. I type "su" and I submit my root password. 6. root@MyBox: /home/sysadmin# (sysadmin is normal user for my box) 7. I type: "ssh root@IP_OF_DEDI -L 127.0.0.1:5902:127.0.0.1:5901" 8. VNC Client keeps connecting for a while. Like (15 seconds) and says: "The connection was refused by the computer"

I am trying to SSH onto my server with the command

-i key.pem ec2-user@ip_address

as I did with no issues last week but this week it is giving me an error of only

-user@ip_address:Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

which I got before that led me to connecting to wrong server / having key in wrong file but I fixed that so I know that isn't the problem. This is the error message I am receiving when trying to connect.

-vvv -i key1.pem ec2-user@34.255.97.122
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "34.255.97.122" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 34.255.97.122 [34.255.97.122] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file key1.pem type -1
debug1: key_load_public: No such file or directory
debug1: identity file key1.pem-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 34.255.97.122:22 as 'ec2-user'
debug3: hostkeys_foreach: reading file "/home/ubuntu/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/ubuntu/.ssh/known_hosts:7
debug3: load_hostkeys: loaded 1 keys from 34.255.97.122
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-group-exchange-sha1,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,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:  compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC:  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:KcJCcNrItmtT7CwXIEndRD42wLyphxOtQR540TzFbSk
debug3: hostkeys_foreach: reading file "/home/ubuntu/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/ubuntu/.ssh/known_hosts:7
debug3: load_hostkeys: loaded 1 keys from 34.255.97.130
debug1: Host '34.255.97.130' is known and matches the ECDSA host key.
debug1: Found key in /home/ubuntu/.ssh/known_hosts:7
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey 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 after 134217728 blocks
debug2: key: key1.pem ((nil)), explicit
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=
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 gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1000)

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1000)

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: key1.pem
debug3: sign_and_send_pubkey: RSA SHA256:ROAQ4zFxWIgz+DlQwSwqivDbjdPsFEh1LCmRYMc/iss
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
ec2-user@34.255.97.130: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Any help would be appreciated as my only solution is from more experienced people.

Could anyone please suggest me a LiveCD (Linux Based) with SSH & FTP Services. Basically I don't want to install anything on my laptop so I just want to boot LiveCD with FTP/SSH services so I can connect from other clients to it and do a FTP/SCP to/from it. Thanks

I am getting a Permission denied error when using the Remote SSH plugin in VSCode to install VSCode server. Below is the version information: Version: 1.102.1 (Universal) Commit: 7adae6a56e34cb64d08899664b814cf620465925 Date: 2025-07-15T16:41:17.147Z (1 wk ago) Electron: 35.6.0 ElectronBuildId: 11847422 Chromium: 134.0.6998.205 Node.js: 22.15.1 V8: 13.4.114.21-electron.0 OS: Darwin arm64 24.5.0 Remote - SSH plugin version: 0.120.0 I get this on problem_server, but it works fine on working_server. Specifically, on problem_server, I get the following errors in the VSCode log for Remote SSH (as does another colleague): > Starting VS Code CLI... [20:30:34.589] > Spawned remote CLI: 1155275 [20:30:34.593] > Exec server process not found [20:30:34.593] stderr> main: line 421: kill: (1155275) - No such process [20:30:34.593] > main: line 404: /home/my-user-id/.vscode-server/code-7adae6a56e34cb64d08899664b814cf620465925: Permission denied [20:30:34.599] > dd278e5bb8e8: start Rather, on the working server, not only do I end up with shell prompt, but I see this in the log: Listening on 127.0.0.1:34491 [2025-07-23 14:12:13] info Disposed of connection to running server. [2025-07-23 14:12:13] info Checking /home/my-user-id/.vscode-server/cli/servers/Stable-7adae6a56e34cb64d08899664b814cf620465925/log.txt and /home/bcmy-user-id/.vscode-server/cli/servers/Stable-7adae6a56e34cb64d08899664b814cf620465925/pid.txt for a running server... [2025-07-23 14:12:16] info Downloading Visual Studio Code server -> /tmp/.tmpDMMA26/stable [2025-07-23 14:13:26] info Starting server... [2025-07-23 14:13:26] info Server started [2025-07-23 15:38:01] info Disposed of connection to running server. So, it seems to me it's something that executable file that it doesn't like on problem_server. I compare the file information on problem_server (error) with working_server (works in VSCode). Even though the binary is the same (same permissions, md5sum, file type, etc.), but yet, running the code in the shell yields different results. Note that on the working server, while it gives an error that it can't find an installation of VSCode, that's to be expected, as I'm simply running the binary and not going through the entire installation. Most importantly, it does not give Permission denied, and actually executes and gives a message, as opposed to giving Permission Denied. In other words, it's progressing further than on the problem server; I'm trying to figure out why. [my-user-id@problem_server .vscode-server]$ md5sum code-7adae6a56e34cb64d08899664b814cf620465925 ff8674c3b154525ee6a90aaa607b4b20 code-7adae6a56e34cb64d08899664b814cf620465925 [my-user-id@problem_server .vscode-server]$ ./code-7adae6a56e34cb64d08899664b814cf620465925 -bash: ./code-7adae6a56e34cb64d08899664b814cf620465925: Permission denied [my-user-id@problem_server .vscode-server]$ file code-7adae6a56e34cb64d08899664b814cf620465925 code-7adae6a56e34cb64d08899664b814cf620465925: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), static-pie linked, BuildID[sha1]=1867cb6f8a643033d4a1ad6fb23976852117df3a, stripped [my-user-id@problem_server .vscode-server]$ ls -l code-7adae6a56e34cb64d08899664b814cf620465925 -rwx------. 1 my-user-id my-user-id 24580920 Jul 15 12:44 code-7adae6a56e34cb64d08899664b814cf620465925 [my-user-id@problem_server .vscode-server]$ pwd /home/my-user-id/.vscode-server [my-user-id@problem_server .vscode-server]$ sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: permissive Mode from config file: permissive Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 33 [my-user-id@problem_server .vscode-server]$ stat code-7adae6a56e34cb64d08899664b814cf620465925 File: code-7adae6a56e34cb64d08899664b814cf620465925 Size: 24580920 Blocks: 48016 IO Block: 4096 regular file Device: fc09h/64521d Inode: 11337 Links: 1 Access: (0700/-rwx------) Uid: (my-user-id/ bcmy-user-id) Gid: (my-user-id/ bcmy-user-id) Context: unconfined_u:object_r:user_home_t:s0 Access: 2025-07-23 23:38:46.624510881 -0400 Modify: 2025-07-15 12:44:04.000000000 -0400 Change: 2025-07-23 23:35:03.606497062 -0400 Birth: 2025-07-23 23:28:56.563182723 -0400 [my-user-id@working_server .vscode-server]$ md5sum code-7adae6a56e34cb64d08899664b814cf620465925 ff8674c3b154525ee6a90aaa607b4b20 code-7adae6a56e34cb64d08899664b814cf620465925 [my-user-id@working_server .vscode-server]$ ./code-7adae6a56e34cb64d08899664b814cf620465925 No installation of Visual Studio Code stable was found. Install it from your system's package manager or https://code.visualstudio.com , restart your shell, and try again. If you already installed Visual Studio Code and we didn't detect it, run code version use stable --install-dir /path/to/installation [my-user-id@working_server .vscode-server]$ file code-7adae6a56e34cb64d08899664b814cf620465925 code-7adae6a56e34cb64d08899664b814cf620465925: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), static-pie linked, BuildID[sha1]=1867cb6f8a643033d4a1ad6fb23976852117df3a, stripped [my-user-id@working_server .vscode-server]$ ls -l code-7adae6a56e34cb64d08899664b814cf620465925 -rwx------. 1 my-user-id my-user-id 24580920 Jul 15 09:44 code-7adae6a56e34cb64d08899664b814cf620465925 [my-user-id@working_server .vscode-server]$ pwd /home/my-user-id/.vscode-server [my-user-id@working_server .vscode-server]$ sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: permissive Mode from config file: permissive Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 33 [my-user-id@working_server .vscode-server]$ stat code-7adae6a56e34cb64d08899664b814cf620465925 File: code-7adae6a56e34cb64d08899664b814cf620465925 Size: 24580920 Blocks: 48016 IO Block: 4194304 regular file Device: c26ac9c8h/3261778376d Inode: 162132235103771773 Links: 1 Access: (0700/-rwx------) Uid: (my-user-id/ bcmy-user-id) Gid: (my-user-id/ bcmy-user-id) Context: unconfined_u:object_r:user_home_t:s0 Access: 2025-07-23 20:39:30.000000000 -0700 Modify: 2025-07-15 09:44:04.000000000 -0700 Change: 2025-07-23 14:12:13.000000000 -0700 Birth: 2025-07-23 14:12:13.000000000 -0700 [my-user-id@working_server .vscode-server]$ This problem only seems to happen where VSCode is running on a Mac (Sequoia 15.5), and in connecting to problem_server. Other people using VScode on Windows connecting to problem_server don't have this problem. I have tried: 1. Comparing the prerequisite packages, which are the same on both the problem_server and working_server 2. Deleting the .vscode-server directory, downgrading the version of Remote SSH, and recreating the problem. I did this for the previous two recent plugin versions, and got the same thing. As I compare the logs of the successful and failed attempts, it seems to me on the problem_server, it tries to spawn the remote CLI process, which hangs or has some kind of issue and VSCode tries to kill it and doesn't find it before trying to run the binary and get Permission Denied. If so, why would the remote CLI process crash, hang or have an issue? Any thoughts as to why this is?

I installed Puppet Agent on a CentOS 7 server. I installed Puppet Master on a different CentOS 7 server. I'm using the free version of Puppet on both servers. The Puppet Agent server requested a certificate. I signed it on the Puppet Master server. There is no software firewall on either server. There is no firewall between the servers. I temporarily enabled port 8140 with SSHD. I used SSH to verify port 8140 was open. I then reverted SSHD to only listen on port 22. Port 8140 wasn't blocked. nslookup on the IP addresses and ping against the domain names shows that both servers have correct networking information about the other server. These are new servers. Puppet has never worked on them before. I created a simple manifest. I applied it to the Puppet Master server locally. It worked without errors. I then tried to apply it to the Puppet Agent server. It didn't work. From the Puppet Master server, I ran this:

puppet agent neat.pp --server hostNameOfPuppetAgentServer --verbose

There were no errors on the Puppet Master server after I pressed enter. There was no output at all. This produced no logs on the Puppet Agent server. There was no evidence it worked on the Puppet Agent server. I checked, and the effects were not performed. On the Puppet Master server I ran this:

puppet agent --server hostNameOfPuppetAgentServer --test

The results included Connection refused -- connect (2). What is wrong? I expect the manifest to work on a Puppet Agent node.

Iam trying out linux on Ipad through the iSH app, however, i cant seem to find my username it always returns 'root' when i do whoami. So now iam confused how I can ssh into another computer or even how to ssh into my ipad, as Ive tried multiple commands to find my ip on the ipad however it just doesnt work. e.g I try ifconfig -a but its shows /proc/net/dev: No such file or directory. curl ifconfig.me works for the public ip, but i need the host ip for ssh which doesnt show me. Another example :

Mathewss-iPad:~# hostname -I

hostname: unrecognized option: I
BusyBox v1.31.1 () multi-call binary.

Usage: hostname [OPTIONS] [HOSTNAME | -F FILE]

Get or set hostname or DNS domain name

        -s      Short
        -i      Addresses for the hostname
        -d      DNS domain name
        -f      Fully qualified domain name
        -F FILE Use FILE's content as hostname

issues: Can't SSH into our out to any devices because: 1. Cant find hostname just 'root' 2. Cant retrieve host ip address 3. But everything works as normal in linux apk installing packages, making folders, changing directories etc.