Booting kernel from Legacy Image at 02000000 ...

Loading init Ramdisk from multi component Legacy Image at 02000000 ...

Flattened Device Tree from multi component Image at 02000000

How to Set Up a Solana Validator

Terminology: What is a Solana Validator?

• Connect to a Solana cluster, and sync the current cluster state
• Produce, receive, and share snapshots and other cluster data to stay up-to-date
• Vote to verify new blocks as part of the cluster consensus
• Process incoming transactions and produce new blocks
• Expose RPC and event-driven APIs to allow the cluster data to be queried and new transactions to be submitted

Starting Off: Get the Server Hardware

Install the Solana CLI Locally

$ solana config set --url https://api.testnet.solana.com

$ solana config set --url https://api.mainnet-beta.solana.com

$ solana config set --url https://mainnet.helius-rpc.com/?api-key=

$ mkdir -p ~/.config/solana
$ solana-keygen new --outfile ~/.config/solana/id.json
$ solana airdrop 1 ~/.config/solana/id.json

Set up Vote Account

• Identity Keypair - The validator uses this key pair to identify itself to the network and submit transactions such as votes. The private key will need to live on the server, so the best security is to not keep any more SOL in it than is needed for voting transactions (roughly 1 SOL/day).
• Vote Account Keypair - This key pair refers to the vote account itself, and is used to look up the vote account and delegate stake against it. The create-vote-account command only needs the private key to prove that you own the requisite key. After the vote account is created, only the public key is ever needed. This cannot be changed.
• Withdraw Keypair - This key pair acts as a master key for the vote account, and is used to withdraw rewards, change the identity or withdraw key, and other account operations. This key is by far the most sensitive of the three and should not be generated on or copied to your server. For mainnet, consider using a paper wallet, a hardware wallet, or a multi-sig for this key.

Create the Keypairs

$ solana-keygen new -o identity.json
$ solana-keygen new -o vote.json
$ solana-keygen new -o withdraw.json

Optional: Use a Paper Wallet for the Withdraw Key

$ solana-keygen new --no-outfile

$ solana-keygen verify ASK

Optional: Grind for a Vanity Key for Vote Account

$ solana-keygen grind --starts-with PREF1X:1

Create the Vote Account from the Keypairs

$ solana create-vote-account --fee-payer ~/.config/solana/id.json vote_account.json identity.json withdrawal.json

$ solana create-vote-account --fee-payer ~/.config/solana/id.json vote_account.json identity.json ASK

$ solana vote-account

Optional: Set the Commission

$ solana vote-update-commission --fee-payer ~/.config/solana/id.json 8 ASK

Optional: Add a Multi-sig

1. Set up your browser with a supported Solana wallet plugin, such as Backpack
2. Navigate to the Squads dApp
3. Configure a squad with the desired people and parameters you’d like for your validator
4. Navigate to Developers > Validators, and go through the flow to add the validator
5. You will be asked to paste in the withdrawal private key, this will be used to change the existing withdrawal key over to the squad’s shared withdrawal key
6. Verify the updated withdrawal pubkey using solana vote-account

Configure your Machine as a Validator Server

• Ubuntu’s latest LTS version, installed and up-to-date
  • Other Linux distributions (i.e., Debian-based) may work as well, but all examples here assume Ubuntu; the further you go from Ubuntu, the more you will have to modify the commands
• User-level SSH access configured
• sol service user set up
• System tuning and hard disks set up

System and User Setup

$ sudo apt update
$ sudo apt upgrade
$ sudo adduser sol

$ sudo adduser sol sudo

System Tuning

Hard Drive Configuration

$ sudo su sol
$ mkdir -p /home/sol/accounts
$ mkdir -p /home/sol/ledger
$ mkdir -p /home/sol/snapshots
$ mkdir -p /home/sol/logs

Install the Solana CLI on the Validator Server

Optional: Install the Jito Validator Client

• Collecting and managing MEV tips
• Latency from the Jito block engine
• Possibly running a Jito relayer

Create Validator Run Scripts

Create validator.sh Shell Script

$ scp identity.json [remoteuser@your.validator.host](mailto:remoteuser@your.validator.host):/home/sol

$ sudo su sol
$ cat >/home/sol/validator.sh < #!/bin/bash
PATH=/home/sol/.local/share/solana/install/active_release/bin:$PATH
exec solana-validator \
--identity /home/sol/identity.json \
--vote-account \
--known-validator 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on \
--known-validator 7XSY3MrYnK8vq693Rju17bbPkCN3Z7KvvfvJx4kdrsSY \
--known-validator Ft5fbkqNa76vnsjYNwjDZUXoTWpP7VYm3mtsaQckQADN \
--known-validator 9QxCLckBiJc783jnMvXZubK4wH86Eqqvashtrwvcsgkv \
--only-known-rpc \
--log /home/sol/logs/solana-validator.log \
--accounts /home/sol/accounts \
--snapshots /home/sol/snapshots \
--ledger /home/sol/ledger \
--rpc-port 8899 \
--dynamic-port-range 8000-8020 \
--entrypoint entrypoint.testnet.solana.com:8001 \
--entrypoint entrypoint2.testnet.solana.com:8001 \
--entrypoint entrypoint3.testnet.solana.com:8001 \
--expected-genesis-hash 4uhcVJyU9pJkvQyS88uRDiswHXSCkY3zQawwpjk2NsNY \
--wal-recovery-mode skip_any_corrupted_record \
--limit-ledger-size
EOF
$ chmod +x /home/sol/validator.sh

$ ./validator.sh

Verify the Validator is Running Correctly

$ solana catchup

$ solana-validator --ledger /home/sol/ledger monitor

Set Up Validator as a Daemon Process)

$ sudo cat >/etc/systemd/system/sol.service < [Unit]
Description=Solana Validator
After=network.target
StartLimitIntervalSec=0
[Service]
Type=simple
Restart=always
RestartSec=1
User=sol
LimitNOFILE=1000000
LogRateLimitIntervalSec=0
ExecStart=/home/sol/validator.sh
[Install]
WantedBy=multi-user.target
EOF

$ sudo systemctl daemon-reload
$ sudo systemctl enable --now sol

Set Up Monitoring and Security

Disable Password-based Authentication

...
PasswordAuthentication no
ChallengeResponseAuthentication no
...

$ sudo systemctl reload sshd

Add fail2ban and ufw

$ sudo apt install fail2ban

$ sudo ufw allow 22/tcp
$ sudo ufw allow 8000:10000/tcp
$ sudo ufw allow 8000:10000/udp
$ sudo ufw enable

Validator Identity Keypair

Set Up Monitoring with Watchtower

$ cat >watchtower.sh < #!/bin/bash
PATH=/home/solana/.local/share/solana/install/active_release/bin:/ussbin:/usbin:/sbin:/bin:/snap/bin
exec >>watchtower.log \\
env PAGERDUTY_INTEGRATION_KEY= \\
solana-watchtower \\
--validator-identity \\
--monitor-active-stake \\
--interval 20 \\
--minimum-validator-identity-balance 3 \\
--url https://api.testnet.solana.com
EOF

Optional: Community-based Monitoring

Optional: Custom Monitoring via getHealth RPC Method

Optional: Third Party Monitoring Solutions

Add Stake to the Validator

1. Create 3 keypairs using solana-keygen new
2. Create a stake account from the keypairs using solana create-stake-account
3. Transfer some SOL into the stake account (can be done with solana aidrop for testnet)
4. Delegate the deposited stake to a validator using solana delegate-stake
5. Await the next epoch for the stake to activate, and check with solana stake-account

Create Keypairs and Stake Account

• Stake Authority Keypair - allows operational tasks on the stake account such as delegating, undelegating, splitting, merging
• Stake Account Keypair - the public key identifying the stake account itself (the private key is not needed after the stake account is created)
• Withdrawal Keypair - the master keypair for withdrawing stake and resetting authority keypairs on the stake account. Treat with care and consider a hardware wallet, paper wallet, or multi-sig

$ solana-keygen new -o stake_auth.json
$ solana-keygen new -o stake_acct_1.json
$ solana-keygen new -o stake_withdrawal_auth.json
$ solana airdrop 1 ~/.config/solana/id.json
$ solana create-stake-account --from ~/.config/solana/id.json stake_acct_1.json 1 --stake-authority stake_auth.json --withdraw-authority stake_withdraw_auth.json --fee-payer ~/.config/solana/id.json
$ solana delegate-stake --stake-authority stake_auth.json --fee-payer ~/.config/solana/id.json

$ solana stake-account

Publish the Validator’s Information

$ solana validator-info publish "My Awesome Validator" \
--website "https://awesome-validator.xyz/" \
--icon-url "https://awesome-validator.xyz/icon360x360.png" \
--keypair validator_identity.json \
--details "The best validator in the world!"

Congrats!

Additional Resources

• Solana Validators Overview
• Solana Validator Documentation
• Solana Foundation Delegation Program
• Solana Foundation - Stake Pools

1. Install Ubuntu (while I have some linux experience I chose to use the GUI version to help with troubleshooting)
2. Install portainer
3. Install docker and docker compose
4. install UFW
5. Install Fail2Ban
6. Install Wireguard
7. Install Nginx Proxy Manager (docker)
8. Configure NPM with UFW
9. Configure wireguard
10. Configure Fail2Ban
11. Open ssh port
12. Generate ssh keys with desktop and laptop ( the two places I will need to ssh into my server from)

• after keygen disable password authenticated ssh

1. Forward necessary ports for NPM and wg ( I am not sure if I am meant to forward 80/443 from my router for NPM or if it handles the forwarding itself, this is where I could use some more detailed help)
   
2. Purchase domain name
   
3. Forward domain name to NPM (I would like to avoid clourdflare as I've heard they aren't happy with users forwarding traffic to Plex/Jellyfin, but I am wrong then please let me know!)
   
4. Install Nextcloud (docker)
   
5. Install wordpress (docker)
   
6. Install browser game (A dark room for example)
   
7. How can I authenticate user logins for Nextcloud and whichever browser games I host?
   

ersoul@myhost ~ $ uname -srvmpio Linux 5.15.33-sunxi64 #trunk SMP PREEMPT Mon Apr 11 13:39:00 PDT 2022 aarch64 unknown unknown GNU/Linux 

ersoul@rie ~ $ nc -z my.public.ip.addr 62523 Connection to my.public.ip.addr 62523 port [tcp/*] succeeded! ersoul@rie ~ $ nc -z my.public.ip.addr 62524 Connection to my.public.ip.addr 62524 port [tcp/*] succeeded! 

RunAsDaemon 0 # We don't need an open SOCKS port. SocksPort 0 BridgeRelay 1 ExitRelay 0 Nickname nodenickname Log notice stdout ServerTransportPlugin obfs4 exec /usbin/obfs4proxy ExtORPort auto DataDirectory /valib/tor # The variable "OR_PORT" is replaced with the OR port. ORPort 62523 IPv4Only # The variable "PT_PORT" is replaced with the obfs4 port. ServerTransportListenAddr obfs4 0.0.0.0:62524 # The variable "EMAIL" is replaced with the operator's email address. ContactInfo xyz@xyz.org # For nyx ControlPort 9051 CookieAuthentication 1 # Additional properties from processed 'OBFS4V_' environment variables Address my.public.ip.addr 

(Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:36321 0.0.0.0:* LISTEN 1/tor tcp 0 0 0.0.0.0:62523 0.0.0.0:* LISTEN 1/tor tcp 0 0 0.0.0.0:62524 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:9051 0.0.0.0:* LISTEN 1/tor 

ersoul@myhost ~/obfs4-tor $ netstat -ptln egrep "6252462523" (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) tcp 0 0 0.0.0.0:62524 0.0.0.0:* LISTEN 7076/containers-roo tcp 0 0 0.0.0.0:62523 0.0.0.0:* LISTEN 7076/containers-roo 

Using NICKNAME=nodenickname, OR_PORT=62523, PT_PORT=62524, and EMAIL=xyz@xyz.org. Additional properties from 'OBFS4V_' environment variables processing enabled Overriding 'Address' with value 'my.public.ip.addr' Starting tor. Apr 06 14:09:00.130 [notice] Tor 0.4.8.10 running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.11, Zlib 1.2.13, Liblzma 5.4.1, Libzstd 1.5.4 and Glibc 2.36 as libc. Apr 06 14:09:00.130 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/ Apr 06 14:09:00.131 [notice] Read configuration file "/etc/totorrc". Apr 06 14:09:00.135 [notice] Based on detected system memory, MaxMemInQueues is set to 1488 MB. You can override this by setting MaxMemInQueues by hand. Apr 06 14:09:00.135 [warn] BridgeRelay is 1, but ExitRelay is 1 or an ExitPolicy is configured. Tor will start, but it will not function as an exit relay. Apr 06 14:09:00.138 [notice] Opening Control listener on 127.0.0.1:9051 Apr 06 14:09:00.138 [notice] Opened Control listener connection (ready) on 127.0.0.1:9051 Apr 06 14:09:00.138 [notice] Opening OR listener on 0.0.0.0:62523 Apr 06 14:09:00.138 [notice] Opened OR listener connection (ready) on 0.0.0.0:62523 Apr 06 14:09:00.138 [notice] Opening Extended OR listener on 127.0.0.1:0 Apr 06 14:09:00.138 [notice] Extended OR listener listening on port 36321. Apr 06 14:09:00.138 [notice] Opened Extended OR listener connection (ready) on 127.0.0.1:36321 Apr 06 14:09:00.000 [notice] Parsing GEOIP IPv4 file /usshare/togeoip. Apr 06 14:09:00.000 [notice] Parsing GEOIP IPv6 file /usshare/togeoip6. Apr 06 14:09:00.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Apr 06 14:09:01.000 [notice] You are running a new relay. Thanks for helping the Tor network! If you wish to know what will happen in the upcoming weeks regarding its usage, have a look at https://blog.torproject.org/lifecycle-of-a-new-relay Apr 06 14:09:01.000 [notice] It looks like I need to generate and sign a new medium-term signing key, because I don't have one. To do that, I need to load (or create) the permanent master identity key. If the master identity key was not moved or encrypted with a passphrase, this will be done automatically and no further action is required. Otherwise, provide the necessary data using 'tor --keygen' to do it manually. Apr 06 14:09:03.000 [notice] Your Tor server's identity key fingerprint is 'nodenickname C95F4B105DEE8893B8E4AC78A3AB5F4095F1B7C6' Apr 06 14:09:03.000 [notice] Your Tor bridge's hashed identity key fingerprint is 'nodenickname E4D45756D001F797A48C04E5C76EAA84ACF2FE2C' Apr 06 14:09:03.000 [notice] Your Tor server's identity key ed25519 fingerprint is 'nodenickname bF//QTxSz2TeMs1CmC4ifyOKKjSzeoi6Zf5S1oyrFIg' Apr 06 14:09:03.000 [notice] You can check the status of your bridge relay at https://bridges.torproject.org/status?id=E4D45756D001F797A48C04E5C76EAA84ACF2FE2C Apr 06 14:09:03.000 [notice] Bootstrapped 0% (starting): Starting Apr 06 14:09:03.000 [notice] Starting with guard context "default" Apr 06 14:09:03.000 [notice] Registered server transport 'obfs4' at '0.0.0.0:62524' Apr 06 14:09:04.000 [notice] Bootstrapped 5% (conn): Connecting to a relay Apr 06 14:09:04.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay Apr 06 14:09:05.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay Apr 06 14:09:05.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done Apr 06 14:09:05.000 [notice] Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection Apr 06 14:09:06.000 [notice] Bootstrapped 25% (requesting_status): Asking for networkstatus consensus Apr 06 14:09:06.000 [notice] Bootstrapped 30% (loading_status): Loading networkstatus consensus Apr 06 14:09:09.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus. Apr 06 14:09:11.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus. Apr 06 14:09:12.000 [notice] Bootstrapped 50% (loading_descriptors): Loading relay descriptors Apr 06 14:09:18.000 [notice] The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services. Apr 06 14:09:19.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/7717, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.) Apr 06 14:09:27.000 [notice] The current consensus contains exit nodes. Tor can build exit and internal paths. Apr 06 14:09:40.000 [notice] Bootstrapped 56% (loading_descriptors): Loading relay descriptors Apr 06 14:09:40.000 [notice] Bootstrapped 62% (loading_descriptors): Loading relay descriptors Apr 06 14:09:41.000 [notice] Bootstrapped 70% (loading_descriptors): Loading relay descriptors Apr 06 14:09:41.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits Apr 06 14:09:42.000 [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits Apr 06 14:09:42.000 [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit Apr 06 14:09:43.000 [notice] Bootstrapped 100% (done): Done Apr 06 14:09:43.000 [notice] Now checking whether IPv4 ORPort my.public.ip.addr:62523 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) Apr 06 14:17:58.000 [notice] New control connection opened from 127.0.0.1. Apr 06 14:22:26.000 [notice] New control connection opened from 127.0.0.1. Apr 06 14:29:04.000 [warn] Your server has not managed to confirm reachability for its ORPort(s) at my.public.ip.addr:62523. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Apr 06 14:49:04.000 [warn] Your server has not managed to confirm reachability for its ORPort(s) at my.public.ip.addr:62523. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. 

Cloning into 'test'... Received disconnect from [ip] port 2222:2: Too many authentication failures Disconnected from [ip] port 2222 fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. 

version: "3.8" services: server: image: gitea/gitea:1.21.7 container_name: gitea environment: - USER_UID=1000 - USER_GID=1000 - GITEA__database__DB_TYPE=postgres - GITEA__database__HOST=db:5432 - GITEA__database__NAME=gitea - GITEA__database__USER=gitea - GITEA__database__PASSWD=gitea restart: always volumes: - ./gitea:/data - /home/git/.ssh/:/data/git/.ssh - /etc/timezone:/etc/timezone:ro - /etc/localtime:/etc/localtime:ro ports: - "3000:3000" - "2222:22" depends_on: - db db: image: postgres:14 restart: always environment: - POSTGRES_USER=gitea - POSTGRES_PASSWORD=gitea - POSTGRES_DB=gitea volumes: - ./postgres:/valib/postgresql/data 

sudo -u git ssh-keygen -t rsa -b 4096 -C "Gitea Host Key" sudo -u git cat /home/git/.ssh/id_rsa.pub sudo -u git tee -a /home/git/.ssh/authorized_keys sudo -u git chmod 600 /home/git/.ssh/authorized_keys 

cat <<"EOF" sudo tee /uslocal/bin/gitea !/bin/sh ssh -p 2222 -o StrictHostKeyChecking=no "SSH_ORIGINAL_COMMAND=\"$SSH_ORIGINAL_COMMAND\" $0 $@" EOF sudo chmod +x /uslocal/bin/giteagit@127.0.0.1 

[server] DOMAIN = gitea.[url] SSH_DOMAIN = gitea.[url] ROOT_URL = https://gitea.[url] START_SSH_SERVER = true SSH_PORT = 2222 SSH_LISTEN_PORT = 2222 [service] DISABLE_REGISTRATION = true 

Cloning into 'test'... Received disconnect from [ip] port 2222:2: Too many authentication failures Disconnected from [ip] port 2222 fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. 

sudo -u git ssh-keygen -t rsa -b 4096 -C "Gitea Host Key" sudo -u git cat /home/git/.ssh/id_rsa.pub sudo -u git tee -a /home/git/.ssh/authorized_keys sudo -u git chmod 600 /home/git/.ssh/authorized_keys 

cat <<"EOF" sudo tee /uslocal/bin/gitea !/bin/sh ssh -p 2222 -o StrictHostKeyChecking=no "SSH_ORIGINAL_COMMAND=\"$SSH_ORIGINAL_COMMAND\" $0 $@" EOF sudo chmod +x /uslocal/bin/giteagit@127.0.0.1 

[server] DOMAIN = gitea.[url] SSH_DOMAIN = gitea.[url] ROOT_URL = https://gitea.[url] START_SSH_SERVER = true SSH_PORT = 2222 SSH_LISTEN_PORT = 2222 [service] DISABLE_REGISTRATION = true 

• Raspberry Pi - I suggest using a Raspberry Pi Zero 2 W, but you should be able to use Raspberry Pi Zero W or full-size models like Raspberry Pi 3/4/5.
• Raspberry Pi case - Keeps the dust away and makes sure you don’t accidentally short components on the PCB.
• A microSD card - I suggest getting a flash card from a reputable brand like SanDisk, Samsung, or Kingston and skipping the cheapest models. To keep it within a reasonable budget, 32GBs or 16GBs of storage will be more than enough.
• A power adapter:
  • For R Pi Zero 2 W, Zero W, and RPi 3/3B you will need a MicroUSB cable and a power supply capable of providing 5V/2.5A.
  • For R Pi 4/4B, you will need a USB-C cable and a power supply capable of providing 5V/3A
  • For R PI 5, you will need a USB-C cable and a power supply capable of 5V/5A, but you can also use 5V/3A, which limits the peripheral current to 600mA
• SD Card reader if your computer doesn’t come with one.

• Raspberry Pi - I use rpilocator to find retailers that have Raspberry Pi in stock
• Micro SD card - SanDisk Endurance 32GB
• Power supply
  • MicroUSB 12.5W
  • USB-C 15W
• Case
  • Raspberry Pi Zero 2 W/W
  • Raspberry Pi 4B

• Raspberry Pi Imager - a quick and easy way to install Raspberry Pi OS and other operating systems to a microSD card, ready to use with your Raspberry Pi.
• Terminal to remote into your Raspberry Pi - This should be installed on your computer by default

Instructions

• Hostname - the name of your Raspberry Pi device.
• User name and password - You will use this to log in and set up your Raspberry Pi, so make sure you remember those settings and create a strong and secure password.
• Wireless LAN
  • SSID - Name of the WiFi network you want to be able to connect and access remotely with Meshnet
  • Password - Password of the same WiFi network you will connect to.
  • Note: Make sure there are no typos in either of those settings, as otherwise, you will need to reinstall the OS to access your Raspberry Pi.
  • Wireless LAN country - Make sure to set it up according to your location
• Set locale settings - Make sure that the Time Zone and Keyboard layout match your location.

1. ssh-keygen -t ed25519 -C ["your_email@example.com](mailto:"your_email@example.com)"
2. eval "$(ssh-agent -s)"
3. ssh-add ~/.ssh/id_ed25519
4. Add the SSH public key to your account on GitHub .

ssh @ -p  

mkdir ~/.ssh chmod 700 ~/.ssh 

mkdir ~/.ssh chmod 700 ~/.ssh cd ~/.ssh ssh-keygen -t rsa -b 4096 eval `ssh-agent` ssh-add --apple-use-keychain ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub ssh @ -p  'cat >> /volume1/homes//.ssh/id_rsa.pub' 

ssh @ -p  cd ~/.ssh cp id_rsa.pub authorized_keys chmod 0644 authorized_keys sudo vi /etc/ssh/sshd_config 

mkdir ~/.ssh chmod 700 ~/.ssh cd ~/.ssh chmod 600 id_rsa 

cd ~/.ssh touch config 

Host whatever HostName  User  Port  IdentityFile /Users//.ssh/id_rsa AddKeysToAgent yes UseKeychain yes PermitLocalCommand yes LocalCommand clear Host * LogLevel DEBUG 

ssh whatever 

ssh @ -p  cd /volume1/git/ git --bare init .git chown -R :users .git cd .git git update-server-info 

cd ~/Documents/ git clone ssh://@:/volume1/git/.git git config --global user.email “@
” git config --global user.name “Tyler Durden” 

ssh @ -p  cd /volume1/web/ git clone ssh://@:/volume1/git/.git 

ssh @ -p  cd /volume1/web/ git clone /volume1/git/.git 

ssh @ -p  cd /volume1/web/ git pull 

#!/usbin/env bash TARGET="/volume1/web/" GIT_DIR="/volume1/git/.git" BRANCH="master" while read oldrev newrev ref do # only checking out the master (or whatever branch you would like to deploy) if [[ $ref = refs/heads/$BRANCH ]]; then echo "Ref $ref received. Deploying ${BRANCH} branch to production..." git --work-tree=$TARGET --git-dir=$GIT_DIR checkout -f else echo "Ref $ref received. Doing nothing: only the ${BRANCH} branch may be deployed on this server." fi echo " is now on web/” done 

#!/usbin/env bash TARGET="/volume1/web/dev" GIT_DIR="/volume1/git/dev.git" BRANCH="master" cd $TARGET && git --git-dir=$TARGET/.git pull 

ssh @ -p  cd /volume1/git/.git/hooks chmod +x post-receive 

SSH@brocadeICX6450(config)#ip ssh interactive-authentication no SSH@brocadeICX6450(config)#ip ssh password-authentication no SSH@brocadeICX6450(config)#ip ssh key-authentication yes SSH@brocadeICX6450(config)#ip ssh permit-empty-passwd no 

ssh -v -o KexAlgorithms=diffie-hellman-group1-sha1 -i ~/homelab-keyfile root@10.0.1.0 OpenSSH_8.2p1 Ubuntu-4ubuntu0.5, OpenSSL 1.1.1f 31 Mar 2020 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files debug1: /etc/ssh/ssh_config line 21: Applying options for * debug1: Connecting to 10.0.1.0 [10.0.1.0] port 22. debug1: Connection established. debug1: identity file /home/aschneidehomelab-keyfile type -1 debug1: identity file /home/aschneidehomelab-keyfile-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5 debug1: Remote protocol version 2.0, remote software version RomSShell_5.40 debug1: no match: RomSShell_5.40 debug1: Authenticating to 10.0.1.0:22 as 'root' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: diffie-hellman-group1-sha1 debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha1 compression: none debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha1 compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ssh-rsa SHA256:DeaZE45ETlkNvKrjorf9A6dGMUiCnzNjszrEORR0sfQ debug1: Host '10.0.1.0' is known and matches the RSA host key. debug1: Found key in /home/aschneide.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: /home/aschneidehomelab-keyfile explicit debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/aschneidehomelab-keyfile debug1: Authentications that can continue: publickey debug1: No more authentication methods to try. root@10.0.1.0: Permission denied (publickey). 

ssh -v -o KexAlgorithms=diffie-hellman-group1-sha1 root@10.0.1.0 OpenSSH_8.2p1 Ubuntu-4ubuntu0.5, OpenSSL 1.1.1f 31 Mar 2020 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files debug1: /etc/ssh/ssh_config line 21: Applying options for * debug1: Connecting to 10.0.1.0 [10.0.1.0] port 22. debug1: Connection established. debug1: identity file /home/aschneide.ssh/id_rsa type -1 debug1: identity file /home/aschneide.ssh/id_rsa-cert type -1 debug1: identity file /home/aschneide.ssh/id_dsa type -1 debug1: identity file /home/aschneide.ssh/id_dsa-cert type -1 debug1: identity file /home/aschneide.ssh/id_ecdsa type -1 debug1: identity file /home/aschneide.ssh/id_ecdsa-cert type -1 debug1: identity file /home/aschneide.ssh/id_ecdsa_sk type -1 debug1: identity file /home/aschneide.ssh/id_ecdsa_sk-cert type -1 debug1: identity file /home/aschneide.ssh/id_ed25519 type -1 debug1: identity file /home/aschneide.ssh/id_ed25519-cert type -1 debug1: identity file /home/aschneide.ssh/id_ed25519_sk type -1 debug1: identity file /home/aschneide.ssh/id_ed25519_sk-cert type -1 debug1: identity file /home/aschneide.ssh/id_xmss type -1 debug1: identity file /home/aschneide.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5 debug1: Remote protocol version 2.0, remote software version RomSShell_5.40 debug1: no match: RomSShell_5.40 debug1: Authenticating to 10.0.1.0:22 as 'root' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: diffie-hellman-group1-sha1 debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha1 compression: none debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha1 compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ssh-rsa SHA256:DeaZE45ETlkNvKrjorf9A6dGMUiCnzNjszrEORR0sfQ debug1: Host '10.0.1.0' is known and matches the RSA host key. debug1: Found key in /home/aschneide.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: /home/aschneide.ssh/id_rsa debug1: Will attempt key: /home/aschneide.ssh/id_dsa debug1: Will attempt key: /home/aschneide.ssh/id_ecdsa debug1: Will attempt key: /home/aschneide.ssh/id_ecdsa_sk debug1: Will attempt key: /home/aschneide.ssh/id_ed25519 debug1: Will attempt key: /home/aschneide.ssh/id_ed25519_sk debug1: Will attempt key: /home/aschneide.ssh/id_xmss debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentication succeeded (none). Authenticated to 10.0.1.0 ([10.0.1.0]:22). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: pledge: network debug1: Sending environment. debug1: Sending env LANG = C.UTF-8 SSH@brocadeICX6450> 

SSH@brocadeICX6450(config)#show ip ssh config SSH server : Enabled SSH port : tcp\22 Host Key : RSA 2048 Encryption : aes256-cbc, aes192-cbc, aes128-cbc, aes256-ctr, aes192-ctr, aes128-ctr, 3des-cbc Permit empty password : Yes Authentication methods : Public-key Authentication retries : 3 Login timeout (seconds) : 120 Idle timeout (minutes) : 0 SCP : Enabled SSH IPv4 clients : All SSH IPv6 clients : All SSH IPv4 access-group : SSH IPv6 access-group : SSH Client Keys : 

• Our server farm uses public key auth. I have a secure SSH key and certificate generated internally for my username.
• I can SSH into the hosts using my username and key, but MobaXterm throws a fit when trying SCP, leaving me locked out of file access on the left panel

• WinSCP happily connects and lets me manage files, but it prompts for both the openssh key and certificate. Apparently, SCP/SFTP might need the certificate for authentication.
• This led me to discover WinSCP's magic option that merges key and certificate, and bam! SCP works in MobaXterm with this combined ppk file.
  My SOS questions:
  

1. Creating the combined_ppk without WinSCP GUI: WinSCP's keygen only converts the key, not including the certificate. Are there other tools or methods?
2. Convincing MobaXterm to use the certificate: Any way to configure MobaXterm to utilize the separate key and certificate files directly, ditching the combined file?

• Any security considerations about using the combined_ppk approach?

FATAL ERROR: No supported authentication methods available (server sent: publickey,gssapi-keyex,gssapi-with-mic) Error: Could not connect to server 

Status: Using username "root". Status: Access denied Error: Authentication failed. Error: Critical error: Could not connect to server 

Trace: Pageant is running. Requesting keys. Trace: Pageant has 0 SSH-2 keys