ss is used to dump socket statistics. It allows showing information similar to netstat. It can display more TCP and state information than other tools. We will use grep function to only get the list of active SSH sessions on our local host
From the above example we know that there are three hosts which are currently connected to our node3. We have active SSH connections from 10.0.2.31, 10.0.2.30 and 10.0.2.2
2. Using last command
last searches back through the file /var/log/wtmp (or the file designated by the -f flag) and displays a list of all users logged in (and out) since that file was created. Names of users and tty’s can be given, in which case last will show only those entries matching the arguments.
Using this command you can also get the information about the user using which the SSH connection was created between server and client. So below we know the connection from 10.0.2.31 is done using ‘deepak‘ user, while for other two hosts, ‘root‘ user was used for connecting to node3.
[[email protected] ~]# last -a | grep -i still
deepak pts/1 Fri May 31 16:58 still logged in 10.0.2.31
root pts/2 Fri May 31 16:50 still logged in 10.0.2.30
root pts/0 Fri May 31 09:17 still logged in 10.0.2.2
Here I am grepping for a string “still” to get all the patterns with “still logged in“. So now we know we have three active SSH connections from 10.0.2.31, 10.0.2.30 and 10.0.2.2
3. Using who command
who is used to show who is logged on on your Linux host. This tool can also give this information
Using this command we also get similar information as from last command. Now you get the user details used for connecting to node3 from source host, also we have terminal information on which the session is still active.
w displays information about the users currently on the machine, and their processes. This gives more information than who and last command and also serves our purpose to get the list of active SSH connections. Additionally it also gives us the information of the running process on those sessions.
Using w command you will also get the idle time details, i.e. for how long the session is idle. If the SSH session is idle for long period then it is a security breach and it is recommended that such idle SSH session must be killed, you can configure your Linux host to automatically kill such idle SSH session.
[[email protected] ~]# w
17:01:41 up 7:44, 3 users, load average: 0.00, 0.01, 0.05
USER TTY FROM [email protected] IDLE JCPU PCPU WHAT
root pts/0 10.0.2.2 09:17 9:41 0.31s 0.00s less -s
deepak pts/1 10.0.2.31 16:58 3:06 0.03s 0.03s -bash
root pts/2 10.0.2.30 16:50 5.00s 0.07s 0.02s w
5. Using netstat command
Similar to ss we have netstat command to show active ssh sessions. Actually we can also say that ss is the new version of netstat. Here we can see all the ESTABLISHED SSH sessions from remote hosts to our localhost node3. it is also possible that one or some of these active ssh connections are in hung state so you can configure your host to automatically disconnect or kill these hung or unresponsive ssh sessions in Linux.
Now to show active ssh sessions, ps command may not give you accurate results like other commands we discussed in this article but it can give you some more additional information i.e. PID of the SSHD process which are currently active and connected.
To get the ssh connection history you can always check your SSHD logs for more information on connected or disconnected SSH session. Now the sshd log file may vary from distribution to distribution. On my RHEL 7.4 my sshd logs are stored inside /var/log/sshd
Lastly I hope the steps from the article to check active SSH connections and ssh connection history in Linux was helpful. So, let me know your suggestions and feedback using the comment section.
Setting up HTTPS for Spring Boot requires two steps:
Getting an SSL certificate;
Configuring SSL in Spring Boot.
We can generate an SSL certificate ourselves (self-signed certificate). Its use is intended just for development and testing purposes. In production, we should use a certificate issued by a trusted Certificate Authority (CA).
In either case, we’re going to see how to enable HTTPS in a Spring Boot application. Examples will be shown both for Spring Boot 1 and Spring Boot 2.
In this tutorial, we’re going to:
Get an SSL certificate
Generate a self-signed SSL certificate
Use an existing SSL certificate
Enable HTTPS in Spring Boot
Redirect HTTP requests to HTTPS
Distribute the SSL certificate to clients.
If you don’t already have a certificate, follow the step 1a. If you have already got an SSL certificate, you can follow the step 1b.
Throughout this tutorial, I’ll use the following technologies and tools:
Java JDK 8
Spring Boot 2.2.2 and Spring Boot 1.5.22
Keytool is a certificate management utility provided together with the JDK, so if you have the JDK installed, you should already have keytool available. To check it, try running the command keytool --help from your Terminal prompt. Note that if you are on Windows, you might need to launch it from the \bin folder. For more information about this utility, you can read the official documentation.
On GitHub, you can find the source code for the application we are building in this tutorial.
1a. Generate a self-signed SSL certificate
First of all, we need to generate a pair of cryptographic keys, use them to produce an SSL certificate and store it in a keystore. The keytool documentation defines a keystore as a database of “cryptographic keys, X.509 certificate chains, and trusted certificates”.
To enable HTTPS, we’ll provide a Spring Boot application with this keystore containing the SSL certificate.
The two most common formats used for keystores are JKS, a proprietary format specific for Java, and PKCS12, an industry-standard format. JKS used to be the default choice, but now Oracle recommends to adopt the PKCS12 format. We’re going to see how to use both.
Generate an SSL certificate in a keystore
Let’s open our Terminal prompt and write the following command to create a JKS keystore:
Let’s have a closer look at the command we just run:
genkeypair: generates a key pair;
alias: the alias name for the item we are generating;
keyalg: the cryptographic algorithm to generate the key pair;
keysize: the size of the key. We have used 2048 bits, but 4096 would be a better choice for production;
storetype: the type of keystore;
keystore: the name of the keystore;
validity: validity number of days;
storepass: a password for the keystore.
When running the previous command, we will be asked to input some information, but we are free to skip all of it (just press Return to skip an option). When asked if the information is correct, we should type yes. Finally, we hit return to use the keystore password as key password as well.
What is your first and last name?
What is the name of your organizational unit?
What is the name of your organization?
What is the name of your City or Locality?
What is the name of your State or Province?
What is the two-letter country code for this unit?
Is CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct?
Enter key password for<tomcat>(RETURN if same as keystore password):
At the end of this operation, we’ll get a keystore containing a brand new SSL certificate.
Verify the keystore content
To check the content of the keystore following the JKS format, we can use keytool again:
keytool -list -v -keystore keystore.jks
To test the content of a keystore following the PKCS12 format:
To get more information about the keystore and its format, please refer to the previous section.
2. Enable HTTPS in Spring Boot
Whether our keystore contains a self-signed certificate or one issued by a trusted Certificate Authority, we can now set up Spring Boot to accept requests over HTTPS instead of HTTP by using that certificate.
The first thing to do is placing the keystore file inside the Spring Boot project. We want to put it in the resources folder or the root folder.
Then, we configure the server to use our brand new keystore and enable https. Let’s go through the steps both for Spring Boot 1 and Spring Boot 2.
Enable HTTPS in Spring Boot 1
Let’s open our application.properties file (or application.yml) and define the following properties:
Enable HTTPS in Spring Boot 2
To enable HTTPS for our Spring Boot 2 application, let’s open our application.yml file (or application.properties) and define the following properties:
Configuring SSL in Spring Boot
Let’s have a closer look at the SSL configuration we have just defined in our Spring Boot application properties.
server.port: the port on which the server is listening. We have used 8443 rather than the default 8080 port.
server.ssl.key-store: the path to the key store that contains the SSL certificate. In our example, we want Spring Boot to look for it in the classpath.
server.ssl.key-store-password: the password used to access the key store.
server.ssl.key-store-type: the type of the key store (JKS or PKCS12).
server.ssl.key-alias: the alias that identifies the key in the key store.
server.ssl.key-password: the password used to access the key in the key store.
Configure Spring Security to require HTTPS requests
When using Spring Security, we can configure it to require automatically block any request coming from a non-secure HTTP channel.
In a Spring Boot 1 application, we can achieve that by setting the security.require-ssl property to true, without explicitly touching our Spring Security configuration class.
To achieve the same result in a Spring Boot 2 application, we need to extend the WebSecurityConfigurerAdapter class, since the security.require-ssl property has been deprecated.
For more information about how to configure SSL in Spring Boot, you can have a look at the Reference Guide. If you want to find out which properties are available to configure SSL, you can refer to the definition in the code-base.
Congratulations! You have successfully enabled HTTPS in your Spring Boot application! Give it a try: run the application, open your browser and check if everything works as it should.
3. Redirect HTTP requests to HTTPS
Now that we have enabled HTTPS in our Spring Boot application and blocked any HTTP request, we want to redirect all traffic to HTTPS.
Spring allows defining just one network connector in application.properties (or application.yml). Since we have used it for HTTPS, we have to set the HTTP connector programmatically for our Tomcat web server.
The implementations for Spring Boot 1 and Spring Boot 2 are almost the same. The only difference is that some classes for server configuration have been renamed in Spring Boot 2.
Configuring Tomcat for Spring Boot 1
Configuring Tomcat for Spring Boot 2
4. Distribute the SSL certificate to clients
When using a self-signed SSL certificate, our browser won’t trust our application and will warn the user that it’s not secure. And that’ll be the same with any other client.
It’s possible to make a client trust our application by providing it with our certificate.
Extract an SSL certificate from a keystore
We have stored our certificate inside a keystore, so we need to extract it. Again, keytool supports us very well:
The keystore can be in JKS or PKCS12 format. During the execution of this command, keytool will ask us for the keystore password that we set at the beginning of this tutorial (the extremely secure password).
Now we can import our certificate into our client. Later, we’ll see how to import the certificate into the JRE in case we need it to trust our application.
Make a browser trust an SSL certificate
When using a keystore in the industry-standard PKCS12 format, we should be able to use it directly without extracting the certificate.
I suggest you check the official guide on how to import a PKCS12 file into your specific client. On macOS, for example, we can directly import a certificate into the Keychain Access (which browsers like Safari, Chrome and Opera rely on to manage certificates).
If deploying the application on localhost, we may need to do a further step from our browser: enabling insecure connections with localhost.
In Firefox, we are shown an alert message. To access the application, we need to explicitly define an exception for it and make Firefox trust the certificate.
In Chrome, we can write the following URL in the search bar: chrome://flags/#allow-insecure-localhost and activate the relative option.
Import an SSL certificate inside the JRE keystore
To make the JRE trust our certificate, we need to import it inside cacerts: the JRE trust store in charge of holding all certificates that can be trusted.
First, we need to know the path to our JDK home. A quick way to find it, if we are using Eclipse or STS as our IDE, is by going to Preferences > Java > Installed JREs. If using IntelliJ IDEA, we can access this information by going to Project Structure > SDKs and look at the value of the JDK home path field.
On macOS, it could be something like /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home. In the following, we’ll refer to this location by using the placeholder $JDK_HOME.
Then, from our Terminal prompt, let’s insert the following command (we might need to run it with administrator privileges by prefixing it with sudo):
We’ll be asked to input the JRE keystore password. If you have never changed it, it should be the default one: changeit or changeme, depending on the operating system. Finally, keytool will ask if you want to trust this certificate: let’s say yes.
If everything went right, we’d see the message Certificate was added to keystore. Great!
In this tutorial, we have seen how to generate a self-signed SSL certificate, how to import an existing certificate into a keystore, how to use it to enable HTTPS inside a Spring Boot application, how to redirect HTTP to HTTPS and how to extract and distribute the certificate to clients.
On GitHub, you can find the source code for the application we have built in this tutorial.
If you want to protect the access to some resources of your application, consider using Keycloak for the authentication and authorization of the users visiting your Spring Boot or Spring Security application.
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.