Uprade instructions

[za3ter2p]

Instructions here should be assumed I2P and SSH Server/Client already installed on user host and server, here will cover hardening ssh/sshd(server) and connect them to I2P.

Note: Instruction here is for most common free software used distro which is GNU/Linux Debian.

• Openssh-Client (SSH)

First lets start connecting using Keys (not passwords) and hardening SSH client before linking it to I2P:

Now generate new keys based on the best choice:

ssh-keygen -o -a 75 -t ed25519

• o produces a key that is compatible with OpenSSH instead of the older style .pem.
• a refers to the number of rounds of KDF (key derivation function). This strengthens the key against a brute force attack to break the passphrase if the (private) key were to be stolen. A value of 75 to 100 is more than adequate. Remember that the more rounds that are specified, the longer it takes to authenticate (sign in). This depends on your CPU, your workload at the time of sign in, the amount of cores, and available memory among other factors.
• t specifies what type of key to generate. The choices are: rsa, ecdsa and ed25519. RSA and ECDSA are older keys, and OpenSSH recommends ed25519 as the best choice.

It will ask you to enter passphrase , its better security to add it and to generate good one use KeePassXC. (you can leave it empty if you dont want to set it, just press enter)

Now copy the new generated public key to your server with the IP xxx.xxx.xxx.xxx (sometimes it will be name of the host , same thing replace the IP with the hostname)

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@xxx.xxx.xxx.xxx

It will ask you for the password , login normally and then your public key will be copied to your server.

Note: This is security practice to always use key authentication instead of using passwords which can be hammered by hackers.

Now logout from your server and lets harden your ssh client:

Erase ssh client default configurations: (you can copy/backup old configurations in case you want something or go back to it but mostly wont be needed)

echo "" | sudo tee /etc/ssh/ssh_config

Go to /etc/ssh/ssh_config (you can use any text editor here we gonna use nano)

sudo nano /etc/ssh/ssh_config

Copy/paste the following:

Host *

## ipv4
AddressFamily inet

IdentityFile ~/.ssh/id_ed25519

Port 22
Protocol 2
ForwardX11 no
PubkeyAuthentication yes
StrictHostKeyChecking ask
VisualHostKey yes
HashKnownHosts yes
User user
Host host
SendEnv LANG LC_*

## Strongest ciphers:
Ciphers chacha20-poly1305@openssh.com

## Most secure MACs:
MACs hmac-sha2-512-etm@openssh.com

## Secure Kex algos:
KexAlgorithms curve25519-sha256

Tunnel no
#TunnelDevice any:any
#PermitLocalCommand no
#ProxyCommand ssh -q -W %h:%p gateway.example.com

Ctrl+x then y then Enter to save and exit.

Now you can login to your server without the need to enter your password:

ssh user@xxx.xxx.xxx.xxx

(If it will ask you for a password , no problem we gonna configure sshd anyway)

• Openssh-server (sshd) Hardening:

Warnings before configuration

• Changing the sshd configuration (if went wrong) can prevent future successful SSH connections to your servers.
• It is probably best to only set this up for new servers or if you do not mind re-installing the server in case you lock yourself out.
• Better as well to backup the sshd server and know how to restore it if anything go wrong. (search that yourself on how to do that)

Configure sshd (openssh-server) to use the latest security:

Erase sshd default configurations:

echo "" | sudo tee /etc/ssh/sshd_config

Then go to /etc/ssh/sshd_config using nano text editor:

sudo nano /etc/ssh/sshd_config

Copy/paste:

## Protocol 1 is dangerously outdated!
Protocol 2

## 22 is standard, you can make it anything.
## On commandline, when connecting as client,
## use the “-p” option if not port 22;
## example of port 3243: ssh user@host -p 3243
Port 22

## means only ipv4, no v6 allowed
AddressFamily inet

## For an I2P server, you listen on 127.0.0.1
# ListenAddress 0.0.0.0
ListenAddress 127.0.0.1

## comment out if ipv6 is disabled via sysctl or iptables or both
## comment in if ipv6 should be enabled 
#ListenAddress ::

## location of server private key
HostKey /etc/ssh/ssh_host_ed25519_key

## Strongest ciphers:
Ciphers chacha20-poly1305@openssh.com

## Most secure MACs:
MACs hmac-sha2-512-etm@openssh.com

## Secure Kex algos:
KexAlgorithms curve25519-sha256

## Logging - optional - okay to leave commented out
#SyslogFacility AUTH

# unless you need logging, leave commented out
#LogLevel INFO

# how long does the prompt stay if client has a passphrase to enter
LoginGraceTime 2m

# With keypairs, the "prohibit-password" option accomplishes the same thing so root is denied
PermitRootLogin prohibit-password

# Safer to deny root obviously
#PermitRootLogin no

## Specifies whether password authentication is allowed. The default is yes.
## use public keys ed25519 so no password authentication.
## A passphrase is optional for the key, but that is not part of this option.
## This option refers to old style password-only authentication (not secure)
PasswordAuthentication no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

## number of allowed login attempts, if there is a passphrase associated with the key
MaxAuthTries 3

## number of allowed sessions with the same client
#MaxSessions 4

## Specifies whether public key authentication is allowed. The default is yes.
## always use public keys, not passwords
#PubkeyAuthentication yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
# The default is no.
UsePAM no

## circumstance specific.
## This refers to the ssh-agent.
## Useful when running a local instance and client/server exist on same machine
AllowAgentForwarding no

## Be careful with this. Avoid forwarding if you can.
## If you do not forward tcp, leave this commented out.
## Default is yes.
AllowTcpForwarding no

## dependent on connection and network.
## Sometimes useful, sometimes not.
## And okay default is to say “no” and if it turns out you need it, then do “yes.”
TCPKeepAlive yes

## Forwarding X11 is not a good idea
X11Forwarding no

PrintMotd no

## this prints the "Last login: Mon Dec 5 08:21:15 2019 from 192.33.4444" message
#PrintLastLog yes

#UseLogin no

#PermitUserEnvironment no

## second amount to keep connection alive
#ClientAliveInterval 0

UseDNS no

## this is a white space separated list of allowed user login names. Only user names on this list will be allowed to login
AllowUsers user

#Banner /etc/issue.net

AcceptEnv LANG LC_*

# Hiding Debian banner

DebianBanner no

#Subsystem sftp /usr/lib/openssh/sftp-server

#PermitTunnel no

#ChrootDirectory none

Ctrl+x then y then Enter to save and exit.

Restart sshd:

sudo systemctl restart sshd

The ssh connection wont be interrupted and dont close it, Open another terminal (tab) and try to SSH to the server.

• If it works, the process is completed successfully.
• If it does not connect, use the opened terminal to check for configuration errors before trying again.

---

Connecting ssh/sshd To I2P:

• Server

Using java i2p's web interface, navigate to the (Links to your Router Console) Hidden Services Manager under "Global Tunnel Control" section press on "Tunnel Wizard"

Since you are setting up this tunnel for the SSH server, you need to select the "Server" tunnel.

You should fine-tune it later, but the Standard tunnel type is easiest to start with.

Give it a good description:

And tell it where the SSH server will be available.

(!) Choose any Port you prefer but it should be above 1024, in my instructions i used default 22.

Look over the results, and save your settings.

Advanced Settings

1- This is essential in case the server or the router restarted the tunnel shall start itself automatically 2- If you aren't that concerned about your anonymity, then you could reduce the number of hops you take. If you have trouble with speed, a higher tunnel count might help. A few backup tunnels are probably a good idea. You might have to dial-it-in a bit. 3- can be left as "Disable" which is the default or can be changed to "Blinded with look up password" 4- Make sure you are using the latest secure signature 5- Make sure you are using only the best secure encryption type 6- Optional!! (Leave it on Disable if you don't know how to use it) 7- Set it up for interactive connections instead of bulk connections. 8- If you choose to run a high number of tunnels then tick "Reduce on Idle" which will reduce the number of tunnels that run when the serve has experienced extended inactivity.

• Client

Same Thing: Using java i2p's web interface, navigate to the (Links to your Router Console) Hidden Services Manager under "Global Tunnel Control" section press on "Tunnel Wizard"

Since you are setting up this tunnel for the SSH client, you need to select the "client" tunnel.

Next, select the standard tunnel type. You will fine-tune this configuration later.

Give it a good description.

This is the only slightly tricky part. Go to the hidden services manager of the i2p router console and find the base64 "local destination" of the SSH server tunnel (not on the host/client but on the server side). You'll need to find a way to copy this information into the next step. I generally Tox it to myself, any off-the-record should be sufficient for most people.

Once you've found the base64 destination you want to connect to transmitted to your client device, then paste it into the client destination field.

Lastly, set a local port to connect your ssh client to. This will local port will be connected to the base64 destination and thus the SSH server.

Advanced:

1- Same thing explained for ssh server above 2- Same thing explained for ssh server above 3- This means once you want to connect to the SSH server over I2P a tunnel will be opened for that otherwise is off 4- Same thing explained for ssh server above 5- This will give always new keys for your identity (If you dont want that then dont enable it, but enable instead "Generate key to enable persistent client tunnel identity" under "Persistent private key", this is useful for ssh server whitelisting explain above in number 6) 6- Same thing explained for ssh server above

HowTo Whitelist only the client tunnel:

This is more-or-less optional, but it's pretty cool and will prevent anyone who happens to come across your destination from being able to tell you are hosting an SSH service.

First, retrieve the persistent client tunnel destination and transmit it to the server.

Add the client's base64 destination to the server's destination whitelist. Now you'll only be able to connect to the server tunnel from that specific client tunnel and no one else will be able to connect to that destination.

Mutual authentication FTW.

[eyedeekay]

Oh wow. This got buried in my inbox and I'm literally not seeing it until just now. I'm going to find a way to add this SSH hardening stuff in, even though it's sort of a topic in-and-of-itself and other guides might consider it out of scope. Thanks very much for collating it. I'll make some time to review it as soon as possible and check it in.